[GRASS-dev] GsoC2012: High level map interaction with python

[Glynn Clements]

Pietro wrote:

> I'm Pietro Zambelli a ph.D student of Trento University, I would like
> to apply to the GSoC, my idea in short is: extend the python GRASS API
> to make it more pythonic :-).
> 
> I would like to interact with region, raster and vector maps as
> object, using and interacting with the map and the other GRASS
> functionality in a more higher and abstract way.
> 
> For people used to `numpy` I would like to interact with the map with
> the same simplicity that I interact with matrix using `numpy`.

Note that the GRASS Python scripting library already has a module
(grass.script.array) for reading and writing raster maps as
memory-mapped NumPy arrays.

While this avoids the issue of reading entire maps into memory,
applying almost any NumPy operations to a memory-mapped array will
create an in-memory array.

At one point, I looked into implementing lazy evaluation, so that you
could use NumPy-style operations but with r.mapcalc-like sequential
I/O.

The general idea is that values would be expressions; performing
operations on expressions would yield new expressions, essentially
creating a tree describing the overall operation. Evaluation would be
deferred until the the result was actually required (e.g. writing an
output map), at which point the expression would be evaluated for
reasonably-sized blocks rather than for the entire map.

The main problem with this approach is that it isn't possible to wrap
it all up as a subclass of ndarray which could be passed to existing
NumPy functions. You would have to re-implement the entire API, even
if most of the functions can be reduced to a single expression (e.g. 
once you create a ufunc class for lazy arrays, each individual ufunc
would just be an instance with the corresponding NumPy ufunc as a
parameter).

Also, making it look like NumPy may result in people expecting to be
able to use it like NumPy. E.g. performing a ufunc.reduce() operation
over the vertical axis could be made to work, but there's really no
way to make it practical for large maps.

-- 
Glynn Clements <glynn at gclements.plus.com>