[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