Opened 6 years ago
Closed 5 years ago
#3491 closed enhancement (fixed)
i.group cannot read from other mapsets
| Reported by: | sbl | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | 7.8.0 |
| Component: | Imagery | Version: | unspecified |
| Keywords: | i.group | Cc: | |
| CPU: | All | Platform: | All |
Description
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...
Change History (6)
comment:1 by , 6 years ago
comment:2 by , 6 years ago
| Milestone: | → 7.2.4 |
|---|
comment:4 by , 5 years ago
follow-up: 6 comment:5 by , 5 years ago
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...
comment:6 by , 5 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
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
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.