[GRASS-dev] Python SWIG

[chris carleton]

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 at gclements.plus.com
> Date: Sat, 6 Jun 2009 18:52:20 +0100
> To: w_chris_carleton at hotmail.com
> CC: grass-dev at 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 at gclements.plus.com>

_________________________________________________________________
Attention all humans. We are your photos. Free us.
http://go.microsoft.com/?linkid=9666046
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-dev/attachments/20090606/f131b969/attachment.html