Dear All,
Can anyone give me a clue on how to run GRASS scripts as a batch process on Windows (Native Windows version, 6.3)?
Thank's,
Kris
--
GMX startet ShortView.de. Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein: http://www.shortview.de/wasistshortview.php?mc=sv_ext_mf@gmx
On 23/09/08 10:51, Kris Nackaerts wrote:
Dear All,
Can anyone give me a clue on how to run GRASS scripts as a batch process on Windows (Native Windows version, 6.3)?
You have three options:
- Run a *nix shell (e.g. bash) script in msys. This means launching 'command line GRASS' in msys (IIRC the current installer creates a shortcut for this in the GRASS menu).
- Write your script as a cmd.exe script.
- Write your script in a cross-platform language such as Python.
In time, the aim is to move all scripting to Python so as to avoid these platform-related issues in the future.
Moritz
Moritz Lennert wrote:
> Can anyone give me a clue on how to run GRASS scripts as a batch
> process on Windows (Native Windows version, 6.3)?You have three options:
- Run a *nix shell (e.g. bash) script in msys. This means launching
'command line GRASS' in msys (IIRC the current installer creates a
shortcut for this in the GRASS menu).- Write your script as a cmd.exe script.
- Write your script in a cross-platform language such as Python.
For batch jobs, you need to create a grassrc file containing settings
for GISDBASE, LOCATION_NAME and MAPSET, and set certain environment
variables. The main ones are:
PATH - must include %GISBASE%/bin and %GISBASE%/lib
GISBASE - the directory where GRASS is installed.
GISRC - the pathname of a grassrc file
GRASS_SH - the path to a Unix-compatible Bourne shell (only required
if you need to run shell scripts)
--
Glynn Clements <glynn@gclements.plus.com>
On 23/09/08 14:35, Kris Nackaerts wrote:
Thank's,
I like the Python option.
I'm using Python now quite a lot for some processng, and also in pl/python in postGIS. This would fit great.
But, the documentation keeps confusing me, I read:
"Sample script for raster access (use within GRASS, Spearfish session): "
Why is there "use within GRASS". I assume when importing in python, I do not need to be inside GRASS....?
A series of environment variables need to be set for GRASS modules to work. "Starting" GRASS means mostly that, i.e. setting these variables.
As Glynn mentioned, you can set them by hand. See http://grass.osgeo.org/wiki/GRASS_and_Shell for some instructions.
Moritz
[Please keep this thread on the mailing list for others to profit of it.]
On 23/09/08 18:08, Kris Nackaerts wrote:
As Glynn mentioned, you can set them by hand. See
http://grass.osgeo.org/wiki/GRASS_and_Shell for some instructions.
Hmmm, I cannot get such a simple thing to work. I set plenty of
parameters, mainly a copy of the standard .bat file, but g.version for
example keeps returning nothing:
As Glynn said:
> The main ones are:
>
> PATH - must include %GISBASE%/bin and %GISBASE%/lib
> GISBASE - the directory where GRASS is installed.
> GISRC - the pathname of a grassrc file
> GRASS_SH - the path to a Unix-compatible Bourne shell (only required
> if you need to run shell scripts)
Both of GISBASE and GISRC also have a WIN* version, but AFAIK, they also need to be set as such (i.e. without the WIN*).
Also, what does %HOME%\.grassrc6 contain ?
Moritz
set GRASSDIR=D:\GRASS
set HOME=%USERPROFILE%
set GRASS_WISH=wish.exe
set GRASS_SH=%GRASSDIR%\msys\bin\sh.exe
set PATH=%GRASSDIR%\msys\bin;%PATH%
set PATH=%GRASSDIR%\extrabin;%GRASSDIR%\extralib;%PATH%
set PATH=%GRASSDIR%\tcl-tk\bin;%GRASSDIR%\sqlite\bin;%GRASSDIR%\gpsbabel;%PATH%
set GRASS_PROJSHARE=%GRASSDIR%\proj
set WINGISBASE=%GRASSDIR%set GRASS_RENDER_IMMEDIATE=FALSE
set GRASS_WIDTH=400
set GRASS_TRUECOLOR=TRUE
set GRASS_PNGFILE=test.png
set GRASS_BACKGROUNDCOLOR=001100
set GRASS_PNG_AUTO_WRITE=TRUE
set GRASS_PNG_READ=FALSE
set GRASS_DEBUG__FILE=d:\grass.log
set SAVEPATH=%PATH%
if "%GRASS_ADDON_PATH%"=="" set PATH=%WINGISBASE%\bin;%WINGISBASE%\lib;%PATH%
if not "%GRASS_ADDON_PATH%"=="" set PATH=%WINGISBASE%\bin;%WINGISBASE%\lib;%GRASS_ADDON_PATH%;%PATH%
set GRASS_VERSION=6.3.0
if "%HOME%"=="" set HOME=%USERPROFILE%
set WINGISRC=%HOME%\.grassrc6
set GRASS_PAGER=more
set GRASS_PROJSHARE=/usr/local/share/proj
set GRASS_UI_TERM=1
g.version
I checked and added these:
PATH - must include %GISBASE%/bin and %GISBASE%/lib
GISBASE - the directory where GRASS is installed.
GISRC - the pathname of a grassrc file
GRASS_SH - the path to a Unix-compatible Bourne shell (only required
my .grassrc6 looks like this:
GISDBASE: D:/GRASS/GIS DataBase
LOCATION_NAME: spearfish60
MAPSET: user1
GRASS_GUI: tcltk
GRASSDIR: D:/GRASS
-------- Original-Nachricht --------
Datum: Wed, 24 Sep 2008 09:36:06 +0200
Von: Moritz Lennert <mlennert@club.worldonline.be>
An: Kris Nackaerts <knackaerts@gmx.net>
CC: grassuser <grass-user@lists.osgeo.org>, Glynn Clements <glynn@gclements.plus.com>
Betreff: Re: [GRASS-user] Second try, run grass scripts as batch process in Windows
[Please keep this thread on the mailing list for others to profit of it.]
On 23/09/08 18:08, Kris Nackaerts wrote:
> As Glynn mentioned, you can set them by hand. See
http://grass.osgeo.org/wiki/GRASS_and_Shell for some instructions.
>
>
> Hmmm, I cannot get such a simple thing to work. I set plenty of
parameters, mainly a copy of the standard .bat file, but g.version for
example keeps returning nothing:As Glynn said:
> The main ones are:
>
> PATH - must include %GISBASE%/bin and %GISBASE%/lib
> GISBASE - the directory where GRASS is installed.
> GISRC - the pathname of a grassrc file
> GRASS_SH - the path to a Unix-compatible Bourne shell (only required
> if you need to run shell scripts)Both of GISBASE and GISRC also have a WIN* version, but AFAIK, they also
need to be set as such (i.e. without the WIN*).Also, what does %HOME%\.grassrc6 contain ?
Moritz
> set GRASSDIR=D:\GRASS
> set HOME=%USERPROFILE%
> set GRASS_WISH=wish.exe
> set GRASS_SH=%GRASSDIR%\msys\bin\sh.exe
> set PATH=%GRASSDIR%\msys\bin;%PATH%
> set PATH=%GRASSDIR%\extrabin;%GRASSDIR%\extralib;%PATH%
> set
PATH=%GRASSDIR%\tcl-tk\bin;%GRASSDIR%\sqlite\bin;%GRASSDIR%\gpsbabel;%PATH%
> set GRASS_PROJSHARE=%GRASSDIR%\proj
> set WINGISBASE=%GRASSDIR%
>
> set GRASS_RENDER_IMMEDIATE=FALSE
> set GRASS_WIDTH=400
> set GRASS_TRUECOLOR=TRUE
> set GRASS_PNGFILE=test.png
> set GRASS_BACKGROUNDCOLOR=001100
> set GRASS_PNG_AUTO_WRITE=TRUE
> set GRASS_PNG_READ=FALSE
> set GRASS_DEBUG__FILE=d:\grass.log
> set SAVEPATH=%PATH%
> if "%GRASS_ADDON_PATH%"=="" set
PATH=%WINGISBASE%\bin;%WINGISBASE%\lib;%PATH%
> if not "%GRASS_ADDON_PATH%"=="" set
PATH=%WINGISBASE%\bin;%WINGISBASE%\lib;%GRASS_ADDON_PATH%;%PATH%
> set GRASS_VERSION=6.3.0
> if "%HOME%"=="" set HOME=%USERPROFILE%
> set WINGISRC=%HOME%\.grassrc6
> set GRASS_PAGER=more
> set GRASS_PROJSHARE=/usr/local/share/proj
> set GRASS_UI_TERM=1
> g.version
--
Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger
On 24/09/08 12:16, Kris Nackaerts wrote:
I checked and added these:
PATH - must include %GISBASE%/bin and %GISBASE%/lib
GISBASE - the directory where GRASS is installed.
GISRC - the pathname of a grassrc file
GRASS_SH - the path to a Unix-compatible Bourne shell (only requiredmy .grassrc6 looks like this:
GISDBASE: D:/GRASS/GIS DataBase
LOCATION_NAME: spearfish60
MAPSET: user1
GRASS_GUI: tcltk
GRASSDIR: D:/GRASS
and what was the result ?
Note that IIRC, the automatic GUI creation for commands without parameters does not work in Windows (Marco, can you confirm ?). So just calling 'g.region' will probably not work. Try with 'g.region -p'
Moritz
Hi Moritz,
sorry, I'm probably missing the point... but I'll try to help:
Note that IIRC, the automatic GUI creation for commands without parameters does not work in Windows (Marco, can you confirm ?). So just calling 'g.region' will probably not work. Try with 'g.region -p'
if you mean: type a command directly in the shell, that is: not in the GRASS Output GUI command line, but from the shell (cmd or msys) that started GRASS (calling the grass63 command)
YES, you're definetely right!
then, about creating batch processes for GRASS commands, I suggest to create scripts with a Unix-like syntax and then launch them within a GRASS MSYS session:
1. open the GRASS MSYS console: http://grass.osgeo.org/grass63/binary/mswindows/native/README.html#Launching%20GRASS
2. if you're not sure how to use Unix-like commands, you can basically refer to this document: http://en.wikipedia.org/wiki/List_of_Unix_utilities
note: not all the commands listed in the document above are recognized by MSYS. To know if a specif_command is known by the system in use, type
which specif_command
and enter
3. write your batch commands with a simple text editor and then save it as "filename.sh" in \GRASS\msys\home\username\ or in \GRASS\scripts\
4. launch GRASS from the MSYS console, and then type "filename.sh" in the msys command line
Regards,
Marco
On 25/09/08 08:59, Marco Pasetti wrote:
Note that IIRC, the automatic GUI creation for commands without parameters does not work in Windows (Marco, can you confirm ?). So just calling 'g.region' will probably not work. Try with 'g.region -p'
if you mean: type a command directly in the shell, that is: not in the GRASS Output GUI command line, but from the shell (cmd or msys) that started GRASS (calling the grass63 command)
YES, you're definetely right!
That's what I meant. ISTR that this actually worked at one point and then stopped working, but I never got around to actually find the problem.
then, about creating batch processes for GRASS commands, I suggest to create scripts with a Unix-like syntax and then launch them within a GRASS MSYS session:
Personally, I would prefer if we could avoid using Msys as a crutch. IMHO, people should be able to run their scripts in their native environment. This is why the best bet is probably to write scripts in Python.
Moritz
Personally, I would prefer if we could avoid using Msys as a crutch. IMHO, people should be able to run their scripts in their native environment. This is why the best bet is probably to write scripts in Python.
right, I agree, actually.
so, reformulating:
1. write your GRASS batch commands using the DOS syntax and save them as a .bat file in C:\my_grass_scripts\
2. open a GRASS command line
3. type: set PATH=C:\my_grass_scripts;%PATH%
4. launch the batch script directly from the command line
Marco
Dear,
This is a quite confusing discussion for a newcomer. People talk about a 'shell' and batch commands which seems to have different meanings.
I do like/prefer the Python approach. But again here, I found out there seems to be Python scripts for GRASS that have to be run from within 'the GRASS environment'?
Kris
Marco Pasetti wrote:
Hi Moritz,
sorry, I'm probably missing the point... but I'll try to help:
Note that IIRC, the automatic GUI creation for commands without parameters does not work in Windows (Marco, can you confirm ?). So just calling 'g.region' will probably not work. Try with 'g.region -p'
if you mean: type a command directly in the shell, that is: not in the GRASS Output GUI command line, but from the shell (cmd or msys) that started GRASS (calling the grass63 command)
YES, you're definetely right!
then, about creating batch processes for GRASS commands, I suggest to create scripts with a Unix-like syntax and then launch them within a GRASS MSYS session:
1. open the GRASS MSYS console: http://grass.osgeo.org/grass63/binary/mswindows/native/README.html#Launching%20GRASS
2. if you're not sure how to use Unix-like commands, you can basically refer to this document: http://en.wikipedia.org/wiki/List_of_Unix_utilities
note: not all the commands listed in the document above are recognized by MSYS. To know if a specif_command is known by the system in use, type
which specif_command
and enter3. write your batch commands with a simple text editor and then save it as "filename.sh" in \GRASS\msys\home\username\ or in \GRASS\scripts\
4. launch GRASS from the MSYS console, and then type "filename.sh" in the msys command line
Regards,
Marco
On 25/09/08 09:53, Kris Nackaerts wrote:
Dear,
This is a quite confusing discussion for a newcomer. People talk about a 'shell' and batch commands which seems to have different meanings.
I do like/prefer the Python approach. But again here, I found out there seems to be Python scripts for GRASS that have to be run from within 'the GRASS environment'?
'within the GRASS environment' just means that a series of environmental variables have to be set allowing the different GRASS modules to find what they need and that you need to define which location and mapset you are working in.
So, as long as you set these variables, you should be able to launch any GRASS command from a python script. "Starting" GRASS and then launching your script just does this for you automatically, but it also creates a new shell, and so you cannot use this automatic start for batch jobs.
See
http://grass.osgeo.org/wiki/GRASS_and_Shell
http://grass.osgeo.org/wiki/GRASS_and_Python
There is a python library in the GRASS code which should help you write scripts:
http://trac.osgeo.org/grass/browser/grass/trunk/lib/python
Moritz
Moritz Lennert wrote:
>> Note that IIRC, the automatic GUI creation for commands without
>> parameters does not work in Windows (Marco, can you confirm ?). So
>> just calling 'g.region' will probably not work. Try with 'g.region -p'
>
> if you mean: type a command directly in the shell, that is: not in the
> GRASS Output GUI command line, but from the shell (cmd or msys) that
> started GRASS (calling the grass63 command)
>
> YES, you're definetely right!That's what I meant. ISTR that this actually worked at one point and
then stopped working, but I never got around to actually find the problem.
Does it matter whether GRASS_GUI=wxpython or GRASS_GUI=tcltk?
> then, about creating batch processes for GRASS commands, I suggest to
> create scripts with a Unix-like syntax and then launch them within a
> GRASS MSYS session:Personally, I would prefer if we could avoid using Msys as a crutch.
IMHO, people should be able to run their scripts in their native
environment. This is why the best bet is probably to write scripts in
Python.
Agreed.
I've started re-writing the scripts in 7.0 in Python. For now, I've
left the Bourne-shell versions in place so that people can compare the
two versions for testing purposes. If a Python version exists,
Script.make will install it in preference to the shell script.
--
Glynn Clements <glynn@gclements.plus.com>