* Nikos Alexandris <[email protected]> [2018-08-21 12:55:49 +0200]:
* Moritz Lennert <[email protected]> [2018-08-21 09:53:21 +0200]:On 21/08/18 01:50, Nikos Alexandris wrote:* Nikos Alexandris <[email protected]> [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.htmlBut 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
signature.asc
Description: PGP signature
_______________________________________________ grass-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/grass-dev
