[GRASS-user] Multiple `r.proj` requests on the same raster map(s)
Nikos Alexandris
nik at nikosalexandris.net
Sun Feb 25 09:34:50 PST 2018
Thanks a lot Markus.
I didn't mean to "hide" details. It's the lack of time for my bad
example. I posted the "pseudo-example" to get more or less, a
verification, about the "logic" of it.
My intention was/is to share scripts after polishing and corrections.
Attached is only 1 out of many. They live in a private gitlab
repository. I have to wait before I can share.
I could adjust and bring my custom functions to do exactly the
"trick"/logic you explain(ed), with a unique temporary Mapset.
Finally, I think the `.gislock` files I find, are liekely and mostly due
to previous failed attempts. My current solution for them is to simply
re-run my final processes after cleaning these files (either simply
entering and exiting in the corresponding Mapsets, or forcing grass via
-f).
I think that filling-in the unique mapset logic, will do away with 99%
of the troubles.
Nikos
Mixed authors:
--%<---
>> Just a pseudo-example: it would suffice then to,
>>
>> save current region
>does not work, you should be still outside GRASS
>
>> for loop over something
>> ...
>>
>> CURRENT_MAPSET=$(g.mapset -p)
>
>does not work, you should be still outside GRASS
>
>>
>> # a temporary Mapset
>> RANDOM_STRING=$(mktemp --dry-run |cut -d"." -f2)
>
>now you start GRASS ...
>> grass -c $RANDOM_STRING
>
>missing is --exec
>
>... and are out of GRASS again
>
>put this in a script to be called with grass -c ... --exec myscript.sh
>-->
>>
>> # do something
>> r.mask vector=VectorMap where="Attribute='Here'" &&
>> g.region zoom=MASK &&
>> r.zonal.stats cover=covermap base=basemap method=average
>output=outputmap
>>
>> # back to "valid" Mapset
>> g.mapset $CURRENT_MAPSET
>>
>> g.copy raster=outputmap@${RANDOM_STRING},outputmap
>> r.stats -acp in=outputmap out=report
>> r.mask -r
><--
>
>> restore region
>
>does not work, you should be again outside GRASS
>
>All outside GRASS, try to
>
>1. create a script with commands and parameters to be executed, e.g. myscript.sh
>2. create a unique name of a temporary mapset (full path), store it in an env var, e.g. TMPMAPSET
>3. run grass -c $TMPMAPSET --exec myscript.sh
>4. remove the temporary mapset simply with rm -fr $TMPMAPSET
>>>> Alternatively/additionally, don't use the script grassXY to start a GRASS
>>>> session, instead define the GRASS environment with custom scripts (one for
>>>> the GRASS version to use, one for the database/location/mapset to use). This
>>>> avoids race conditions on a HPC system. A unique temporary mapset for each
>>>> process helps to avoid all sorts of concurrent access problems.
>>
>> It mostly works for me with --exec. Mostly. That is, there are missing
>> or empty WIND files, here and there, and .gislock related issues.
--->%---
-------------- next part --------------
A non-text attachment was scrubbed...
Name: i.landsat8.swlst.helper_functions.sh
Type: application/x-sh
Size: 6770 bytes
Desc: not available
URL: <http://lists.osgeo.org/pipermail/grass-user/attachments/20180225/b7530507/attachment-0001.sh>
-------------- 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-user/attachments/20180225/b7530507/attachment-0001.sig>
More information about the grass-user
mailing list