[GRASS-user] Re: python interface

Thu May 18 20:30:45 EDT 2006

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 at 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 University
>
> phone: 480-965-6213
> fax: 480-965-7671
> www: http://www.public.asu.edu/~cmbarton
>
>
>
> > From: Joel Pitt <joel.pitt at gmail.com>
> > Reply-To: <joel.pitt at gmail.com>
> > Date: Thu, 18 May 2006 15:36:39 +1200
> > To: <grassuser at 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 at 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