Opened 15 years ago
Closed 12 years ago
#726 closed defect (invalid)
MASK GRASS_INFO_WARNING
Reported by: | pvanbosgeo | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | 6.4.0 |
Component: | Raster | Version: | svn-trunk |
Keywords: | MASK, r.mask, startup | Cc: | |
CPU: | x86-64 | Platform: | Unspecified |
Description
When starting GRASS in a mapset (work_ethiopia) that has a MASK I get the following message:
" GRASS 6.4.0svn (latlon):~ > WARNING: 'cell/MASK' was found in more mapsets (also found in
<work_ethiopia>)
WARNING: 'cell/MASK' was found in more mapsets (also found in <LUVC>) WARNING: Using <MASK@livestock> "
It seems though that it still uses the mask in the opened mapset (work_ethiopia). I am getting sometimes similar messages when carrying out a r.mapcalc calculation. Again, it seems the correct MASK is used nonetheless.
When opening GRASS in a mapset (e.g., mapset work_ethiopia, but with MASK previously removed) without MASK, I get the following message:
" GRASS 6.4.0svn (latlon):~ > WARNING: 'cell/MASK' was found in more mapsets (also found in <LUVC>) WARNING: Using <MASK@livestock> "
Maybe related to this, when I want to create a MASK in a mapset that has not yet a MASK, I get the following error message (in the r.mask window this time, previous messages were in the terminal):
--- r.mask input=mask_eth@climate 'cell/MASK' was found in more mapsets (also found in <LUVC>) Using <MASK@livestock> ERROR: MASK already found in current mapset. Delete first or overwrite ---
The only way to still create a MASK in this mapset is by using the 'overwrite' option.
I am running GRASS 6.4 svn r38795 on Ubuntu 0.04
Best wishes
Paulo
Change History (2)
follow-up: 2 comment:1 by , 15 years ago
comment:2 by , 12 years ago
Component: | Default → Raster |
---|---|
Resolution: | → invalid |
Status: | new → closed |
Replying to pvanbosgeo:
I guess therefore that something has gone wrong when copying the mapsets and this is not a general bug. It would be good though to know if and how one can copy mapsets from a backup into the current location.
usually 'cp -rp' should do it; just make sure the location is identical and any SEARCH_PATH in the mapset dir is in sync with the new layout.
Hamish
Update: I tried the same in different mapsets, and the only mapsets that seem to show the above-described behavior are the ones I have copied from a backup into the current location (the original location from which the mapsets were copied matches the current one, it is in fact an earlier backup of the current location). I guess therefore that something has gone wrong when copying the mapsets and this is not a general bug. It would be good though to know if and how one can copy mapsets from a backup into the current location.
Paulo