[GRASS-dev] On post-processing a raster map's mapcalc related history string
nik at nikosalexandris.net
Thu Aug 23 02:40:43 PDT 2018
* Nikos Alexandris <nik at nikosalexandris.net> [2018-08-21 12:55:49 +0200]:
>* Moritz Lennert <mlennert at club.worldonline.be> [2018-08-21 09:53:21 +0200]:
>>On 21/08/18 01:50, Nikos Alexandris wrote:
>>>* Nikos Alexandris <nik at nikosalexandris.net> [2018-08-20 20:11:57 +0200]:
>>>>2) Look back some time, r.cross has had problems with zeroes and NULLs.
>>>At least this one is True!, see also:
>>>and this thread, finally:
>>But this seems to have been solved, now, or ?
>Right, need to revisit this part of the script.
There might be a problem in using `r.cross` in scripting:
"reclass(ifi)ed" maps that derive out of a "cross" map
(in which case, the "cross" is the "base" map)
have to be removed first. This will cost an extra `g.copy`
of the `reclassed` map.
I.e., last step of the following will fail:
a x b = crossmap
r.stats.zonal -r in=crossmap out=reclassed
g.remove raster name=crossmap
The `crossmap` serves only as an intermediate map. It is meant to be removed.
Removal of the `crossmap` will fail because the `reclassed` map
depends on it. Removing the `reclassed` map is not desired, since it is an
An extra `g.copy` will solve this, i.e.
then force removal of both:
g.remove -f -b type=raster name=crossmap
This will still leave, in my system, a trace of the `reclassed` map:
will still print the `reclassed` map as a result, although `r.info
reclassed` will fail.
Is there an elegant alternative?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the grass-dev