I am trying to determine the best way to integrate python and GRASS for some simulation modelling. I have a nice discrete event simulation model in python that uses spatially explicit data. Every so often during the simulation, I would like to call GRASS and determine the spatial extent of some disturbance, and either return affected polygon id's, or write them to a database. I was thinking of writing a GRASS module to do this using weave, which allows C code to be called from python. Would it work to run python within the GRASS environment (in much the same way as R does) and have it call GRASS functions. Just wondering if this seems like a plausible strategy to more experienced GRASS programmers.
Any feedback would be most helpful.
Chris
--
Christopher J. Fonnesbeck ( c h r i s @ f o n n e s b e c k . o r g )
Georgia Cooperative Fish & Wildlife Research Unit, University of Georgia
Christopher Fonnesbeck wrote:
I am trying to determine the best way to integrate python and GRASS for
some simulation modelling. I have a nice discrete event simulation
model in python that uses spatially explicit data. Every so often
during the simulation, I would like to call GRASS and determine the
spatial extent of some disturbance, and either return affected polygon
id's, or write them to a database. I was thinking of writing a GRASS
module to do this using weave, which allows C code to be called from
python. Would it work to run python within the GRASS environment (in
much the same way as R does) and have it call GRASS functions.
Yes. There isn't anything particularly special about "the GRASS
environment"; it's just a matter of setting certain environment
variables.
However, I would advise caution with using GRASS functions in
long-running programs. The GRASS libraries don't have a particularly
good record regarding memory leaks. For a typical GRASS program (read
data, perform computation, write data, terminate), this isn't really
an issue. But if you are performing many cycles, any net memory
accumulation over the course of the cycle could cause significant
problems. Confining the GRASS code to a separate program which was run
once per cycle would eliminate this problem.
Another issue: the GRASS API isn't remotely re-entrant; the core
libraries use a lot of static data. I'm not familiar with Python, or
the mechanisms which it uses to interface to C code, so I don't know
whether it will be an issue in your particular case, but it can be an
issue for some languages.
--
Glynn Clements <glynn.clements@virgin.net>