Hi there,
I was wondering if there are any plans to incorporate the python swig
interface into current GRASS cvs (
http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?
Also if any body has had any experience with using python with GRASS,
either using the mentioned swig interface or just as a scripting tool
I'd love to hear their experience/tips.
Cheers,
Joel
--
"Wish not to seem, but to be, the best."
-- Aeschylus
Hallo,
plans are, but no time - could you spare some time? Perl should be
implemented - python should not be much more comlicated.
I'm just calling GRASS's modules over os.system or os.popen in my set of
scripts (comming soon)...
jachym
On Wed, May 17, 2006 at 07:03:01PM +1200, Joel Pitt wrote:
Hi there,
I was wondering if there are any plans to incorporate the python swig
interface into current GRASS cvs (
http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?Also if any body has had any experience with using python with GRASS,
either using the mentioned swig interface or just as a scripting tool
I'd love to hear their experience/tips.Cheers,
Joel--
"Wish not to seem, but to be, the best."
-- Aeschylus_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507
I've used Python extensively with GRASS. As Jachym said, the os module
provides methods for calling external programs and retrieving their
output. I've found that it is easiest to launch your python scripts
from within a grass shell, that simplifies the environment variable
issues (same with Bash scripts).
For simple batch processing I prefer to use Bash and standard UNIX
tools (grep, cut, awk, etc) since your scripts will be more portable
between GRASS installations. However, there are times when you need
more power than bash provides and it is nice to have a full featured
scripting language like Python (or Perl) to do the heavy lifting.
Unfortunately, Python doesn't have a SWIG interface yet to the GRASS
API, so it cannot interface with GRASS at a more atomic level.
Currently, you can only do that with C. I think once, the C API
settles down I will try my hand at creating a SWIG interface to GRASS.
My vision is to have a simplified object model that would allow
non-experts to program cool tools for GRASS.
On 5/17/06, Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:
Hallo,
plans are, but no time - could you spare some time? Perl should be
implemented - python should not be much more comlicated.I'm just calling GRASS's modules over os.system or os.popen in my set of
scripts (comming soon)...jachym
On Wed, May 17, 2006 at 07:03:01PM +1200, Joel Pitt wrote:
> Hi there,
>
> I was wondering if there are any plans to incorporate the python swig
> interface into current GRASS cvs (
> http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?
>
> Also if any body has had any experience with using python with GRASS,
> either using the mentioned swig interface or just as a scripting tool
> I'd love to hear their experience/tips.
>
> Cheers,
> Joel
>
> --
> "Wish not to seem, but to be, the best."
> -- Aeschylus
>
> _______________________________________________
> grassuser mailing list
> grassuser@grass.itc.it
> http://grass.itc.it/mailman/listinfo/grassuser--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)iD8DBQFEa01xyKt0uAjU4I8RAjc4AKCNl+T9yEVfpb4it10dgzuP64ZV5QCdE6ub
zVQq+EfUJ5todIaL7/vlK8w=
=0A6l
-----END PGP SIGNATURE-----_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
David Finlayson
On Wed, May 17, 2006 at 11:05:06AM -0700, David Finlayson wrote:
Unfortunately, Python doesn't have a SWIG interface yet to the GRASS
API, so it cannot interface with GRASS at a more atomic level.
Currently, you can only do that with C. I think once, the C API
settles down I will try my hand at creating a SWIG interface to GRASS.
My vision is to have a simplified object model that would allow
non-experts to program cool tools for GRASS.
I thing, this is the way, how to bring new developers to GRASS. Looking
forward
Jachym
On 5/17/06, Jachym Cepicky <jachym.cepicky@centrum.cz> wrote:
>Hallo,
>plans are, but no time - could you spare some time? Perl should be
>implemented - python should not be much more comlicated.
>
>I'm just calling GRASS's modules over os.system or os.popen in my set of
>scripts (comming soon)...
>
>jachym
>
>On Wed, May 17, 2006 at 07:03:01PM +1200, Joel Pitt wrote:
>> Hi there,
>>
>> I was wondering if there are any plans to incorporate the python swig
>> interface into current GRASS cvs (
>> http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?
>>
>> Also if any body has had any experience with using python with GRASS,
>> either using the mentioned swig interface or just as a scripting tool
>> I'd love to hear their experience/tips.
>>
>> Cheers,
>> Joel
>>
>> --
>> "Wish not to seem, but to be, the best."
>> -- Aeschylus
>>
>> _______________________________________________
>> grassuser mailing list
>> grassuser@grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grassuser
>
>--
>Jachym Cepicky
>e-mail: jachym.cepicky@centrum.cz
>URL: http://les-ejk.cz
>GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
>-----------------------------------------
>OFFICE:
>GDF-Hannover
>Mengendamm 16d
>30177 Hannover
>Germany
>e-mail: cepicky@gdf-hannover.de
>URL: http://gdf-hannover.de
>Tel.: +49 511-39088507
>
>
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.3 (GNU/Linux)
>
>iD8DBQFEa01xyKt0uAjU4I8RAjc4AKCNl+T9yEVfpb4it10dgzuP64ZV5QCdE6ub
>zVQq+EfUJ5todIaL7/vlK8w=
>=0A6l
>-----END PGP SIGNATURE-----
>
>
>_______________________________________________
>grassuser mailing list
>grassuser@grass.itc.it
>http://grass.itc.it/mailman/listinfo/grassuser
>
>
>--
David Finlayson
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507
I think once, the C API settles down I will try my hand at creating a
SWIG interface to GRASS.
FWIW, I'd rate the C API as quite stable currently. It's too big to
change quickly.
Hamish
Thanks to everyone for their response!
I've already been doing os.system and os.popen calls as people suggested.
I'm trying to develop a GUI program to manage my dispersal experiments
so alot of the low level GRASS interaction is already implemented as
seperate C programs. I would like to be able to do some low level
interaction however - but this is basically reading raster rows and
calculating means for binned integer ranges.
My plan is to have a map display within a pyGTK interface and I've
heard of people using the PNG driver to display the monitor in an
appropriate widget. Are there any other methods or already implemented
widgets for GTK (I know there is a qtGRASS project...)?
I could possibly spend time on integrating the swig interface with
GRASS but I'm relatively new to python so I'll wait till I've slightly
more competent
Cheers
Joel
On 5/17/06, Joel Pitt <joel.pitt@gmail.com> wrote:
Hi there,
I was wondering if there are any plans to incorporate the python swig
interface into current GRASS cvs (
http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?Also if any body has had any experience with using python with GRASS,
either using the mentioned swig interface or just as a scripting tool
I'd love to hear their experience/tips.Cheers,
Joel--
"Wish not to seem, but to be, the best."
-- Aeschylus
--
"Wish not to seem, but to be, the best."
-- Aeschylus
Hi
On Thu, May 18, 2006 at 03:36:39PM +1200, Joel Pitt wrote:
Thanks to everyone for their response!
I've already been doing os.system and os.popen calls as people suggested.
I'm trying to develop a GUI program to manage my dispersal experiments
so alot of the low level GRASS interaction is already implemented as
seperate C programs. I would like to be able to do some low level
interaction however - but this is basically reading raster rows and
calculating means for binned integer ranges.My plan is to have a map display within a pyGTK interface and I've
heard of people using the PNG driver to display the monitor in an
appropriate widget. Are there any other methods or already implemented
widgets for GTK (I know there is a qtGRASS project...)?
i had the same idea, month ago, but no time, go Joel, go!
what about reading the raster and vector data via gdal? python interface
to gdal is allready implemented...
jachym
I could possibly spend time on integrating the swig interface with
GRASS but I'm relatively new to python so I'll wait till I've slightly
more competentCheers
JoelOn 5/17/06, Joel Pitt <joel.pitt@gmail.com> wrote:
>Hi there,
>
>I was wondering if there are any plans to incorporate the python swig
>interface into current GRASS cvs (
>http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?
>
>Also if any body has had any experience with using python with GRASS,
>either using the mentioned swig interface or just as a scripting tool
>I'd love to hear their experience/tips.
>
>Cheers,
>Joel
>
>--
>"Wish not to seem, but to be, the best."
> -- Aeschylus
>--
"Wish not to seem, but to be, the best."
-- Aeschylus_______________________________________________
grassuser mailing list
grassuser@grass.itc.it
http://grass.itc.it/mailman/listinfo/grassuser
--
Jachym Cepicky
e-mail: jachym.cepicky@centrum.cz
URL: http://les-ejk.cz
GPG: http://les-ejk.cz/gnupg_public_key/jachym_cepicky-gpg_public_key.asc
-----------------------------------------
OFFICE:
GDF-Hannover
Mengendamm 16d
30177 Hannover
Germany
e-mail: cepicky@gdf-hannover.de
URL: http://gdf-hannover.de
Tel.: +49 511-39088507
Joel,
The main GUI development is focusing on TclTk at the moment. There are a
couple of reasons for this. First, there is considerable investment in TclTk
already in GRASS so there is a lot of code available. Second, it is very
easy and quick to create sophisticated GUI's in TclTk that are portable
across many platorms (i.e., running natively in various Linux flavors, Mac
OS X, and Windows).
That said, there are also reasons that a different platform (e.g, QT or
WxWidgets) might be a better GUI platform in the long run. The ultimate goal
is the development of a new, improved, and better integrated GUI for GRASS.
However, to do that, it is necessary to make existing GRASS modules more
generic with respect to GUI and make it so that they no longer *require* X11
(especially if we want GRASS to run natively in non *nix platforms). But
there needs to be a reasonable alternative to X11--for interaction and
display--to make it worthwhile to begin to rewrite the C-code modules. The
big push now is to create a TclTk system that allows GRASS to run without
X11 so that kind of module updating can proceed. We're very close to that
now. We have a much more sophisticated display system that uses the PNG
driver rather than the Xdriver, and quite a few improved display management
and interface tools to go with it. It is robust enough that we have
switched to this as the default GUI in the current development version of
GRASS--while still maintaining the older X11-based GUI for the modules that
still need it. The next step will be to revisit alternative GUI development
platforms (and possibly even more sophisticated TclTk platforms like tile).
I also see that TclTk has a SWIG module.
One of the great things about GRASS is that its structure permits multiple
user interfaces. However, if you'd like to help with the main GUI project,
you expertise would be welcome.
A different kind of interface project that is just getting started by a
collaboration between my research team and others is to try and develop an
interface (not a GUI) between Java applications (particularly agent modeling
platforms) and GRASS. We hope that it can be built so that it is not
necessary to run GRASS within Java or Java within GRASS, but that both can
operate independently and pass information back and forth (e.g., agents
sending commands to GRASS and receiving the results of querys). You might be
interested in helping on this also.
Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
From: Joel Pitt <joel.pitt@gmail.com>
Reply-To: <joel.pitt@gmail.com>
Date: Thu, 18 May 2006 15:36:39 +1200
To: <grassuser@grass.itc.it>
Subject: [GRASS-user] Re: python interfaceThanks to everyone for their response!
I've already been doing os.system and os.popen calls as people suggested.
I'm trying to develop a GUI program to manage my dispersal experiments
so alot of the low level GRASS interaction is already implemented as
seperate C programs. I would like to be able to do some low level
interaction however - but this is basically reading raster rows and
calculating means for binned integer ranges.My plan is to have a map display within a pyGTK interface and I've
heard of people using the PNG driver to display the monitor in an
appropriate widget. Are there any other methods or already implemented
widgets for GTK (I know there is a qtGRASS project...)?I could possibly spend time on integrating the swig interface with
GRASS but I'm relatively new to python so I'll wait till I've slightly
more competentCheers
JoelOn 5/17/06, Joel Pitt <joel.pitt@gmail.com> wrote:
Hi there,
I was wondering if there are any plans to incorporate the python swig
interface into current GRASS cvs (
http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?Also if any body has had any experience with using python with GRASS,
either using the mentioned swig interface or just as a scripting tool
I'd love to hear their experience/tips.Cheers,
Joel--
"Wish not to seem, but to be, the best."
-- Aeschylus--
"Wish not to seem, but to be, the best."
-- Aeschylus
Hi Michael,
The interface between Java agents and GRASS sounds very interesting.
I've personally developed a system for modelling dispersal of species
and other phenomenom based on a mixture of cellular automata,
dispersal kernels, growth equations and extinction risk maps.
I've made this extremely modular by developing each dynamic as a
seperate grass program and using a controller module that reads an xml
simulation definition. However, doing lots of replications and
sensitivity analysis results in huge numbers of raster maps and I have
decided to implement a tool to manage simulation replications and run
analysis across them too. I've decided to use python and pygtk for the
GUI because I need to develop this fast and I've been meaning to learn
python for ages.
I'm aware of the usage of and motivation behind tcltk in GRASS - but
I'm primarily developing the GUI for my own use and researchers that
follow me. I'd love to be apart of the GUI development team, but I'm
in the last year of my PhD and time is scarce and shouldn't take on
further commitments lest I forget my girlfriends name 
-Joel
On 5/18/06, Michael Barton <michael.barton@asu.edu> wrote:
Joel,
The main GUI development is focusing on TclTk at the moment. There are a
couple of reasons for this. First, there is considerable investment in TclTk
already in GRASS so there is a lot of code available. Second, it is very
easy and quick to create sophisticated GUI's in TclTk that are portable
across many platorms (i.e., running natively in various Linux flavors, Mac
OS X, and Windows).That said, there are also reasons that a different platform (e.g, QT or
WxWidgets) might be a better GUI platform in the long run. The ultimate goal
is the development of a new, improved, and better integrated GUI for GRASS.
However, to do that, it is necessary to make existing GRASS modules more
generic with respect to GUI and make it so that they no longer *require* X11
(especially if we want GRASS to run natively in non *nix platforms). But
there needs to be a reasonable alternative to X11--for interaction and
display--to make it worthwhile to begin to rewrite the C-code modules. The
big push now is to create a TclTk system that allows GRASS to run without
X11 so that kind of module updating can proceed. We're very close to that
now. We have a much more sophisticated display system that uses the PNG
driver rather than the Xdriver, and quite a few improved display management
and interface tools to go with it. It is robust enough that we have
switched to this as the default GUI in the current development version of
GRASS--while still maintaining the older X11-based GUI for the modules that
still need it. The next step will be to revisit alternative GUI development
platforms (and possibly even more sophisticated TclTk platforms like tile).
I also see that TclTk has a SWIG module.One of the great things about GRASS is that its structure permits multiple
user interfaces. However, if you'd like to help with the main GUI project,
you expertise would be welcome.A different kind of interface project that is just getting started by a
collaboration between my research team and others is to try and develop an
interface (not a GUI) between Java applications (particularly agent modeling
platforms) and GRASS. We hope that it can be built so that it is not
necessary to run GRASS within Java or Java within GRASS, but that both can
operate independently and pass information back and forth (e.g., agents
sending commands to GRASS and receiving the results of querys). You might be
interested in helping on this also.Cheers
Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State Universityphone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton> From: Joel Pitt <joel.pitt@gmail.com>
> Reply-To: <joel.pitt@gmail.com>
> Date: Thu, 18 May 2006 15:36:39 +1200
> To: <grassuser@grass.itc.it>
> Subject: [GRASS-user] Re: python interface
>
> Thanks to everyone for their response!
>
> I've already been doing os.system and os.popen calls as people suggested.
>
> I'm trying to develop a GUI program to manage my dispersal experiments
> so alot of the low level GRASS interaction is already implemented as
> seperate C programs. I would like to be able to do some low level
> interaction however - but this is basically reading raster rows and
> calculating means for binned integer ranges.
>
> My plan is to have a map display within a pyGTK interface and I've
> heard of people using the PNG driver to display the monitor in an
> appropriate widget. Are there any other methods or already implemented
> widgets for GTK (I know there is a qtGRASS project...)?
>
> I could possibly spend time on integrating the swig interface with
> GRASS but I'm relatively new to python so I'll wait till I've slightly
> more competent
>
> Cheers
> Joel
>
> On 5/17/06, Joel Pitt <joel.pitt@gmail.com> wrote:
>> Hi there,
>>
>> I was wondering if there are any plans to incorporate the python swig
>> interface into current GRASS cvs (
>> http://gnowledge.org/pipermail/free-gis/2006-March/000075.html )?
>>
>> Also if any body has had any experience with using python with GRASS,
>> either using the mentioned swig interface or just as a scripting tool
>> I'd love to hear their experience/tips.
>>
>> Cheers,
>> Joel
>>
>> --
>> "Wish not to seem, but to be, the best."
>> -- Aeschylus
>>
>
> --
> "Wish not to seem, but to be, the best."
> -- Aeschylus
>
--
"Wish not to seem, but to be, the best."
-- Aeschylus