On Mon, Jul 7, 2008 at 3:13 PM, Christian Braun
<christian.braun@tudor.lu> wrote:
Hi guys,
I am a colleague of Jessica who posted before this:
http://www.nabble.com/GRASS-BATCH-JOBS-to17470510.html#a17475609We are using GRASS in an interactive website to calculate on-the-fly maps
which are then presented to the user. It is not really a WebGIS-Client and
it doesn't aim to be one. We tested also pyWPS but the script was there
before and it was to complicated to adept the needs of pyWPS.As we are running GRASS in a "multiuser" web environment we need a
workaround to treat different contemporary users. We decided then to create
a bash workaround to solve this:First we encountered that GRASS in batchmode is not writing the .gislock
file, but it writes in normal interactive mode with the same user used.
See below...
In the next step we tested if we can then run two instances of the same
script in the same mapset and it worked.
you can, but it's risky if you touch resolution and region extent.
We can not find the issue why this is working. Currently we are in the
testing phase and the project will be online soon, so we have to be sure
what GRASS is doing with .gislock and all related staff to avoid problems
with concurrent users.
Best is to run concurrent user sin different mapsets.
Currently we are using Ubuntu 7.04 with packages of Jachym (GRASS 6.2).
These will be updated to Hardy and GRASS 6.3 before release.
If you check the GRASS 6.3.0 announcement:
http://grass.osgeo.org/announces/announce_grass630.html
"Batch mode for launching GRASS for non-interactive processing tasks"
... it's well worth to update. I/we have added much simplification in 6.3.0
since I needed to process MODIS maps in parallel on a cluster. But
these changes weren't backported to 6.2 (too complicated).
Markus