Hi All,
I’ve read somewhere (by Glenn, I think) that Python-SWIG might not go much farther with GRASS due to some limitations of the SWIG interface (I’m not expert enough to know either way). Despite that, I can’t see another way to program what I want to do with GRASS. So, I was hoping that someone on the list has a full list of currently wrapped GRASS functions so that I know what I have to work with so far. Fortunately, I can just use Python scripting in the module when I don’t have direct access to GRASS functions, although that’s going to slow it all down. The other question I have is related to raster editing. I need to be able to edit specific cells in a raster map based on coordinate locations passed to the editing function (I can sort of see how to do it using the buffers that hold the row of raster data), but I don’t want a whole new map generated every time an edit is made. Is it possible to edit a cell and then just close the map without re-writing the whole matrix? Also, if I’m making say a thousand calls to that function will there be a noticeable lag time because of all the opening and closing of the raster map (i.e. how much time does it take to open and close a raster for reading/editing?). Thanks,
Chris
Create a cool, new character for your Windows Live™ Messenger. Check it out
chris carleton wrote:
I've read somewhere (by Glenn, I think) that Python-SWIG might not
go much farther with GRASS due to some limitations of the SWIG
interface (I'm not expert enough to know either way). Despite that,
I can't see another way to program what I want to do with GRASS. So,
I was hoping that someone on the list has a full list of currently
wrapped GRASS functions so that I know what I have to work with so
far.
Everything in the following headers has been wrapped:
G3d.h
P_datetime.h
Vect.h
arraystats.h
cluster.h
datetime.h
dbmi.h
display.h
gis.h
gisdefs.h
gmath.h
gprojects.h
imagedefs.h
imagery.h
raster.h
stats.h
transform.h
vect/dig_defines.h
vect/dig_structs.h
vedit.h
However, some of those wrappers will be unusable because of an
inability to pass an argument from Python or return the result to
Python.
Fortunately, I can just use Python scripting in the module when
I don't have direct access to GRASS functions, although that's going
to slow it all down.
The other question I have is related to raster editing. I need to be
able to edit specific cells in a raster map based on coordinate
locations passed to the editing function (I can sort of see how to
do it using the buffers that hold the row of raster data), but I
don't want a whole new map generated every time an edit is made. Is
it possible to edit a cell and then just close the map without
re-writing the whole matrix?
Rasters cannot be modified "in place".
Also, if I'm making say a thousand
calls to that function will there be a noticeable lag time because
of all the opening and closing of the raster map (i.e. how much time
does it take to open and close a raster for reading/editing?).
Modifying rasters one cell at a time isn't practical.
One practical option is the mechanism which d.rast.edit uses:
individual changes are stored internally; the map is updated by
exporting the changes to a raster map using r.in.ascii, then the
changes are merged with the original map using r.patch.
--
Glynn Clements <glynn@gclements.plus.com>
Thanks very much for the reply Glynn (sorry about the misspelled version of your name). Do you think I could use G_put_map_row_random to fill a new raster with the modified values of cells at various locations in the region and then use patch to change the original raster? What would the other cell locations contain in a raster map written in this way (nulls, zeros, nothing)? To help clarify, I’m writing a GRASS_ABM extension and the agents will need to modify the rasters they interact with, but the simulation could run for thousands of iterations and I want to maximize speed and minimize memory usage. Once I get a working skeleton of ABM functions together (move, read raster, change raster, spawn new agents, die) then I’ll clean up the messy code, document, and let the ABM mailing list know about the progress.
Chris
From: glynn@gclements.plus.com
Date: Sat, 6 Jun 2009 18:52:20 +0100
To: w_chris_carleton@hotmail.com
CC: grass-dev@lists.osgeo.org
Subject: Re: [GRASS-dev] Python SWIG
chris carleton wrote:
I’ve read somewhere (by Glenn, I think) that Python-SWIG might not
go much farther with GRASS due to some limitations of the SWIG
interface (I’m not expert enough to know either way). Despite that,
I can’t see another way to program what I want to do with GRASS. So,
I was hoping that someone on the list has a full list of currently
wrapped GRASS functions so that I know what I have to work with so
far.
Everything in the following headers has been wrapped:
G3d.h
P_datetime.h
Vect.h
arraystats.h
cluster.h
datetime.h
dbmi.h
display.h
gis.h
gisdefs.h
gmath.h
gprojects.h
imagedefs.h
imagery.h
raster.h
stats.h
transform.h
vect/dig_defines.h
vect/dig_structs.h
vedit.h
However, some of those wrappers will be unusable because of an
inability to pass an argument from Python or return the result to
Python.
Fortunately, I can just use Python scripting in the module when
I don’t have direct access to GRASS functions, although that’s going
to slow it all down.
The other question I have is related to raster editing. I need to be
able to edit specific cells in a raster map based on coordinate
locations passed to the editing function (I can sort of see how to
do it using the buffers that hold the row of raster data), but I
don’t want a whole new map generated every time an edit is made. Is
it possible to edit a cell and then just close the map without
re-writing the whole matrix?
Rasters cannot be modified “in place”.
Also, if I’m making say a thousand
calls to that function will there be a noticeable lag time because
of all the opening and closing of the raster map (i.e. how much time
does it take to open and close a raster for reading/editing?).
Modifying rasters one cell at a time isn’t practical.
One practical option is the mechanism which d.rast.edit uses:
individual changes are stored internally; the map is updated by
exporting the changes to a raster map using r.in.ascii, then the
changes are merged with the original map using r.patch.
–
Glynn Clements glynn@gclements.plus.com
Attention all humans. We are your photos. Free us.
chris carleton wrote:
Do you think I could use G_put_map_row_random
to fill a new raster with the modified values of cells at various
locations in the region and then use patch to change the original
raster?
Note that G_put_map_row_random() has been removed in 7.0. Nothing was
using it, and it only works with pre-5.0 rasters (no support for
floating-point or nulls).
What would the other cell locations contain in a raster map
written in this way (nulls, zeros, nothing)?
Zeros. When you open a new map with G_open_cell_new_random(), the
output file is filled with zeros. These are then overwritten by
G_put_map_row_random().
To help clarify,
I'm writing a GRASS_ABM extension and the agents will need to modify
the rasters they interact with, but the simulation could run for
thousands of iterations and I want to maximize speed and minimize
memory usage. Once I get a working skeleton of ABM functions together
(move, read raster, change raster, spawn new agents, die) then
I'll clean up the messy code, document, and let the ABM mailing
list know about the progress.
You may be better off using a plain file to store intermediate data,
and exporting to a GRASS raster at the end.
--
Glynn Clements <glynn@gclements.plus.com>