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

[Markus Metz]

On Sun, Apr 1, 2012 at 12:16 AM, Pietro <peter.zamb at gmail.com> wrote:
> Hi everyone!
>
> 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`.
>
> For curious people, that want to understand my insane idea I add a new
> page in the Wiki [0] to try to explain what I mean. I have used the
> python doctest [1]: to give an brief idea of how we could interact
> with the new python module, and in case of consensus, as the basis for
> a test-driven development approach for the GSoC.
>
> There are many aspect that could be improved and that must be
> resolved, I try to highlight possible problems. But, of course, I need
> some help to find out more and to understand if the idea, is or not,
> good to contribute to the great GRASS software.
> Please feel free to critique, add new examples, raise problems,
> doubts, etcetera. In particular I would like to invite all developers
> to check to find incoherence/inconsistency with the GRASS and/or
> Python philosophy[2].
>
> Any suggestions and criticism are more than welcome!

I like the general concept of making the GRASS python API more
python-like. But I am not so sure about the raw data access in a numpy
way with a matrix holding raster data. Actually I am against it,
because GIS data handling is, because of their potential size,
different from say statistical data handling. When working with raster
data, there are a number of ways how to deal with them in chunks or
rows to avoid memory issues. You can have a look at r.example, the
cache used by r.proj, the segment lib and the rowio lib in order to
better understand how GIS raster algorithm development works. Also the
file-based spatial index in the GRASS 7 vector lib can give you an
idea about GIS data handling. See also the recent post of Alex Mandel
in the user ml [0]. Raw data access should IMHO be left to existing
modules, in particular because you intend to provide an easy to use
GRASS Python API primarily for users.

Markus M

[0] http://osgeo-org.1560.n6.nabble.com/Re-ArcGIS-vs-GRASS-notes-td4679637.html