[GRASS-dev] [GRASS GIS] #3857: r.mapcalc unable to rename null and cell files

GRASS GIS trac at osgeo.org
Sun Oct 27 07:27:33 PDT 2019


#3857: r.mapcalc unable to rename null and cell files
----------------------+-------------------------
  Reporter:  Hygsson  |      Owner:  grass-dev@…
      Type:  defect   |     Status:  closed
  Priority:  major    |  Milestone:  7.6.2
 Component:  Raster   |    Version:  unspecified
Resolution:  wontfix  |   Keywords:  r.mapcalc
       CPU:  x86-64   |   Platform:  MSWindows 7
----------------------+-------------------------

Comment (by glynn):

 Replying to [comment:5 Nikos Alexandris]:

 > I read this thread again and I am still not happy with the "it may work
 in some cases" statement. In which cases will it work and in which not?
 Can someone help to dig out the "documented" behavior?

 With that fix, it should work so long as the maps are actual GRASS maps,
 not external files linked via r.external(.out).

 Things which might still be an issue:

 * Overwriting a map doesn't systematically delete files belonging to the
 old map. Look at
 [https://github.com/OSGeo/grass/blob/master/lib/raster/close.c#369
 close_new] to see which files are removed or replaced. This issue isn't
 specific to r.mapcalc, or to overwriting outputs with inputs, but with
 overwriting in general.

 * When copying a map without any intervening calculation (i.e. the entire
 expression on the right-hand side of a top-level assignment is just a map,
 optionally with a neighbourhood modifier, but no category/colour
 modifier), the input map's categories, colours and history are copied to
 the output map. This won't work if the input map and output map are the
 same map, and it won't work reliably if the input map is one of the
 outputs (the result will depend upon the order in which the outputs are
 closed). Closing an output map will replace all of the standard support
 files (see close_new as mentioned above), so copying those files will copy
 the new version if the output map has already been closed. This situation
 doesn't seem particularly likely to occur in practice.

-- 
Ticket URL: <https://trac.osgeo.org/grass/ticket/3857#comment:6>
GRASS GIS <https://grass.osgeo.org>



More information about the grass-dev mailing list