[GRASS-dev] On post-processing a raster map's mapcalc related history string

[Nikos Alexandris]

* 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:
>>>
>>>https://trac.osgeo.org/grass/ticket/3080
>>>https://lists.osgeo.org/pipermail/grass-dev/2017-September/086090.html
>>>and this thread, finally:
>>>https://lists.osgeo.org/pipermail/grass-user/2018-February/077931.html
>
>>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
output.


An extra `g.copy` will solve this, i.e.
```
g.copy raster=reclassed,output
```
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:
```
g.list raster
```
will still print the `reclassed` map as a result, although `r.info
reclassed` will fail.

Is there an elegant alternative?

Nikos
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20180823/f5083221/attachment.sig>