i.group cannot read from other mapsets

[sbl]

Using i.group on imagery groups in other mapsets unfortunately does not work. Seems to be a known limitation as I get the following error message: ERROR: Group must exist in the current mapset

Would however be nice to be able to read groups from other mapsets, if non-modifying operations with i.group (l,s,g-flag) would be allowed...

Tagging it as enhancement as behavior is deliberately as it is at the moment...

[neteler]

The group management has been discussed long time back, see also #70 and

​https://lists.osgeo.org/pipermail/grass-dev/2008-June/038371.html

However, things can certainly be discussed and their technical feasibility be revisited again.

[sbl]

Enhancement tickets should point to 7.8.

[marisn]

There have been some changes in group handling. IMHO this issue has been fixed in r73633 and r74107

Please test with trunk.

[sbl]

Partly fixed I would say:

grass77 ./nc_spm_full_v2alpha/user1/ --exec i.group group=mygroup subgroup=subgroup input=aspect,basin,boundary --o

Starting GRASS GIS...
Cleaning up temporary files...
Executing <i.group group=mygroup subgroup=subgroup input=aspect,basin,boundary --o> ...
Adding raster map <aspect@PERMANENT> to group
Adding raster map <basin@PERMANENT> to group
Adding raster map <boundary@PERMANENT> to group
Adding raster map <aspect@PERMANENT> to subgroup
Adding raster map <basin@PERMANENT> to subgroup
Adding raster map <boundary@PERMANENT> to subgroup
Execution of <i.group group=mygroup subgroup=subgroup input=aspect,basin,boundary --o> finished.
Cleaning up temporary files...


grass77 ./nc_spm_full_v2alpha/stefan --exec i.group group=mygroup@user1 -l

Starting GRASS GIS...
Cleaning up temporary files...
Executing <i.group group=mygroup@user1 -l> ...
group <mygroup> references the following raster maps
-------------
<aspect@PERMANENT>      <basin@PERMANENT>       <boundary@PERMANENT>    
-------------
Execution of <i.group group=mygroup@user1 -l> finished.
Cleaning up default sqlite database ...
Cleaning up temporary files...

However, groups from other mapsets are still not fullly useable e.g. in i.cluster.

grass77 ./nc_spm_full_v2alpha/stefan/ --exec i.cluster group=mygroup@user1 subgroup=subgroup signaturefile=sign classes=3

Starting GRASS GIS...
Cleaning up temporary files...
Executing <i.cluster group=mygroup@user1 subgroup=subgroup signaturefile=sign classes=3> ...
WARNING: Subgroup <subgroup> doesn't have any raster maps
ERROR: Subgroup must have at least 2 raster maps
Execution of <i.cluster group=mygroup@user1 subgroup=subgroup signaturefile=sign classes=3> finished.
Cleaning up default sqlite database ...
Cleaning up temporary files...

In addition, i.cluster seems to try to write to the imagery group directory in the other mapset (the signature file), so further adjustments downstreams seem to be required...

[marisn]

Replying to sbl:

Partly fixed I would say:

No, this issue is completely fixed as it was about i.group.

However, groups from other mapsets are still not fullly useable e.g. in i.cluster. In addition, i.cluster seems to try to write to the imagery group directory in the other mapset (the signature file), so further adjustments downstreams seem to be required...

This is a different issue. Groups are designed to be useable only in the current mapset. I changed i.group behaviour as I have new i. modules just reading from and not writing to groups and thus being fine with current changes. Other i. modules still follow the old design principles.

I am closing this issue as fixed. A discussion on group/subgroup behaviour in context of i. modules writing their files into group should be held and accordingly new issues should be opened per each module not matching expected behaviour. See also: #3525 and ​https://marc.info/?l=grass-dev&m=152474676813985&w=2 and ​https://marc.info/?l=grass-dev&m=152481635118286&w=2