[GRASSLIST:175] Re: Reading/writing maps

[Glynn Clements]

David Finlayson wrote:

> I find that I have to script cell-by-cell processing frequently, and 
> occasionally, I want to store the results back as a new raster.
> 
> I have written a couple of primitive Python classes that read and write 
> the r.out.arc ascii format.  I basically stored the whole raster in a 
> numeric array along with its header information as a short dictionary. 
> Then I overloaded most of Python's operators so that this "raster" 
> object could be used in math statements.  Add a get(row, col) and a 
> put(row, col) and you have a fairly complete re-implementation of 
> r.map.calc in about 300 lines of Python (try that in C!).  This even 
> gives you the full power of Python's numeric library for additional fun.

One question: how do you handle nulls?

> Now the down side is the initial dump from grass and reload is really a 
> waist of time.  And there is a definite disconnect between the grass 
> code and the Python code (even if they do work together nicely)
> 
> Ideally, we should run SWIG over the Grass API and build some Python 
> wrapper classes that encapsulate the C function library.  I would 
> envision a 2 stage process: 1) get Python talking to the C Api, then 2) 
> build some convenience classes that make it easy to work with the data 
> structures from within Python.  The idea is to get the power of the C 
> api into a package that can be easily learned and utilized by Grass 
> users.  Ease of use is the number one goal, performance is important but 
> secondary (of course, performance is where real programmers are 
> important rather than a half-baked geologist!)

For handling rasters, you wouldn't need to use all that many
functions; e.g. r.mapcalc only uses 49 GRASS functions.

However, it would be best if you could avoid reading the entire raster
into memory. The easiest way to do that would be to make the "get"
function cache the most recently used N rows.

OTOH, while GRASS allows rows to be read in any order, the output has
to be written top-to-bottom (G_get_raster_row() etc take the row
number as an argument, while G_put_raster_row() etc always write the
next row).

-- 
Glynn Clements <glynn.clements at virgin.net>