[GRASS-dev] On post-processing a raster map's mapcalc related history string
Nikos Alexandris
nik at nikosalexandris.net
Mon Aug 20 16:50:44 PDT 2018
* Nikos Alexandris <nik at nikosalexandris.net> [2018-08-20 20:11:57 +0200]:
>* Moritz Lennert <mlennert at club.worldonline.be> [2018-08-20 18:08:18 +0200]:
>
>>On 20/08/18 17:59, Nikos Alexandris wrote:
>>>A mapcalc expression, involving somewhat long(er) temporary map
>>>names, stored in the output raster map's history, looks like:
>>>```
>>>Comments:
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 1
>>> && tmp.32493.17.recreation_opportunity == 1), 1,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 1
>>> && tmp.32493.17.recreation_opportunity == 2), 2,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 1
>>> && tmp.32493.17.recreation_opportunity == 3), 3,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 2
>>> && tmp.32493.17.recreation_opportunity == 1), 4,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 2
>>> && tmp.32493.17.recreation_opportunity == 2), 5,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 2
>>> && tmp.32493.17.recreation_opportunity == 3), 6,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 3
>>> && tmp.32493.17.recreation_opportunity == 1), 7,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 3
>>> && tmp.32493.17.recreation_opportunity == 2), 8,
>>> if((tmp.32493.16.tmp.32493.11.tmp.32493.6.recreation_potential == 3
>>> && tmp.32493.17.recreation_opportunity == 3), 9)))))))))
>>>```
>>>
>>>Any smart ideas on how to post-process this to get rid of all
>>>'tmp.32493.16.tmp.32493.11.tmp.32493.6.' parts?
>>>
>>>Standard string manipulation utilities?
>>
>>I would guess so.
>>
>>>
>>>Or, rather, build an "fake" expression with the original map names just
>>>for the sake of having a cleaner history?
>>
>>Using r.support ?
>
>The above "history" string is actually passed using `r.support`.
>
>
>>Looking at your expression, I'm mostly wondering why you don't just
>>use r.cross to get the same result ... ;-)
>
>In my in-code comments, ever since I started writing this script:
>
> - Why not use `r.cross`?
>
>1) I just "translated" someone else's code and hade fun using `eval`.
Double that false statement. `eval` is actually not related here.
It comes from another part, of the same script, which counts 3000+
lines. Fatigue...-
>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
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/20180821/7be2cf7f/attachment.sig>
More information about the grass-dev
mailing list