On Sun, Apr 1, 2012 at 12:16 AM, Pietro <peter.z...@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 _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev