We are working on an internet application which uses grass for interpolation (idw).
The user can select the kind of point data to send to grass. Now a shellscript will be executet to get
back a .tif + .tfw viewd by the umn mapserver.
what happens when two users start one grass location with the same mapset at the same time.
is it possible to start idw two times with different mapsets but the same location and how can i create
a new mapset/location in batchmode.
thanks,
michaela
--
Institut fuer Geographie und Regionalforschung
Universitaet Wien
Kartografie und Geoinformation
Departement of Geography and Regional Research
University of Vienna
Cartography and GIS
We are working on an internet application which uses grass for interpolation (idw).
The user can select the kind of point data to send to grass. Now a shellscript will be executet to get
back a .tif + .tfw viewd by the umn mapserver.
what happens when two users start one grass location with the same mapset at the same time.
is it possible to start idw two times with different mapsets but the same location and how can i create
a new mapset/location in batchmode.
Normally, on a single system, GRASS can only be used by one user at the same time. You can disable this by commenting out a few lines in grass5/etc/Init.sh, but this is dangerous. The working mapset and region are stored on disk, so the mapset of the second concurrent user will become automatically that of the first one, and every change of region will apply to all users. If both remain the same, it should be possible to use GRASS simultaneously. I think that is the case with r.surf.idw.
I have been struggling with this problem in the same situation as you: using GRASS as a backend for web-based MapServer applications. This hack works for me, but it would be nice if GRASS could be really used in parallel. I am not sure how difficult this would be to implement however.
BTW: MapServer can read GRASS datasets directly. This is slightly slower than reading tiff files, but certainly faster than converting GRASS datasets to tiff and using those. MapServer has to be compiled with Gdal and Grasslib (not in the standard binaries).
Jan
dr.J. Hartmann
Department of Geography
University of Amsterdam
j.l.h.hartmann@uva.nl
We are working on an internet application which uses grass for
interpolation (idw).
The user can select the kind of point data to send to grass. Now a
shellscript will be executet to get
back a .tif + .tfw viewd by the umn mapserver.
what happens when two users start one grass location with the same
mapset at the same time.
The behaviour is undefined (i.e. it may cause problems). Note that the
supplied GRASS startup script doesn't allow a single user to run
multiple sessions.
Coupled with the fact that you can only select a mapset as the current
mapset (the one in which new maps are created) if you own the
directory, it isn't normally possible to have multiple sessions with
the same current mapset.
is it possible to start idw two times with different mapsets but the
same location
Yes.
and how can i create a new mapset/location in batchmode.
To create a new mapset, simply create a new subdirectory within the
location directory, then create a WIND file in the mapset subdirectory
(e.g. by copying PERMANENT/DEFAULT_WIND).
I've got an application that does exactly what you're doing. But what
I've done is created several 'working' Grass mapsets (apache1, apache2,
apache3, etc.). So when a user makes a particular request, my script
first checks for an available GRASS mapset (checks for a grass
lockfile). If apache1 is in use, it sends the request to apache2. If
apache2 is in use, it goes to apache3, etc. I have it setup to allow for
five simultaneous users which for us is more than adequate because the
mapset is only in use for a few seconds, enough time to do the grid
calculation and export the geotiff to Mapserver for rendering. I use
geotiffs because the GDAL/Grass interface into Mapserver only allows
8-bit rasters and I have floating point grids with thousands of
categories.
-Matt
-----Original Message-----
From: owner-GRASSLIST@baylor.edu [mailto:owner-GRASSLIST@baylor.edu] On
Behalf Of Kinberger Michaela
Sent: Wednesday, April 21, 2004 1:54 AM
To: GRASS Mailing List
Subject: [GRASSLIST:3246] creating new mapset/location in batch-mode
Hi,
We are working on an internet application which uses grass for
interpolation (idw).
The user can select the kind of point data to send to grass. Now a
shellscript will be executet to get
back a .tif + .tfw viewd by the umn mapserver.
what happens when two users start one grass location with the same
mapset at the same time.
is it possible to start idw two times with different mapsets but the
same location and how can i create
a new mapset/location in batchmode.
thanks,
michaela
--
Institut fuer Geographie und Regionalforschung
Universitaet Wien
Kartografie und Geoinformation
Departement of Geography and Regional Research
University of Vienna
Cartography and GIS
>We are working on an internet application which uses grass for
>interpolation (idw).
>The user can select the kind of point data to send to grass. Now a
>shellscript will be executet to get
>back a .tif + .tfw viewd by the umn mapserver.
>
>what happens when two users start one grass location with the same
>mapset at the same time.
>is it possible to start idw two times with different mapsets but the
>same location and how can i create
>a new mapset/location in batchmode.
I think it's best to keep all the base maps in a read-only mapset, and
access them with the "map@mapset" external-mapset referer.
For each process, you can make a new mapset (eg. "wwwtemp.$$") by making
a new directory by that name and copying a region (WIND) file into that
directory. Change to the new mapset with the attached script, have it
do its thing, then remove the entire directory (mapset) before finishing
the process. Maybe a cron-job to clean up any aborted mapsets [*] to
avoid disk space problems.
[*] either stop everything or test against pgrep numbers to avoid
removing a live mapset?
attached: script for changing to a new mapset, "g.nm"
It's well tested here.