[GRASS-user] .gislock problem
Hi guys, I am a colleague of Jessica who posted before this: http://www.nabble.com/GRASS-BATCH-JOBS-to17470510.html#a17475609 We 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. In the next step we tested if we can then run two instances of the same script in the same mapset and it worked. 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. 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. Any ideas? Thanks in advance, Christian _ Dipl. Geogr. Christian Braun Tel: +352- 425991-608 Mobil: +49-179-6845896 Mail: [EMAIL PROTECTED] *** www.crte.lu *** Resource Centre for Environmental Technologies, Public Research Centre Henri Tudor, Technoport Schlassgoart, 66 rue de Luxembourg, P.O. BOX 144, L-4002 Esch-sur-Alzette, Luxembourg ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .gislock problem
On Mon, Jul 7, 2008 at 3:13 PM, Christian Braun [EMAIL PROTECTED] wrote: Hi guys, I am a colleague of Jessica who posted before this: http://www.nabble.com/GRASS-BATCH-JOBS-to17470510.html#a17475609 We 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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .gislock problem
Christian Braun wrote: I am a colleague of Jessica who posted before this: http://www.nabble.com/GRASS-BATCH-JOBS-to17470510.html#a17475609 We 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. In the next step we tested if we can then run two instances of the same script in the same mapset and it worked. 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. For a web application, I would suggest bypassing Init.sh altogether, and setting any relevant environment variables yourself. For non-interactive use, it should suffice to set: LD_LIBRARY_PATH PATH GISBASE GISRC GRASS_MESSAGE_FORMAT=silent GRASS_PAGER=cat -- Glynn Clements [EMAIL PROTECTED] ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
