Hi Pietro, this is an interesting and very useful submission. A numpy matrix interface would be a valuable addition, but as Markus Metz said, we need also direct row access without reading the whole raster or vector map into the memory.
Actually with the vtk-grass-bridge there is already an object orientated interface to the grass raster, vector and voxel libraries providing convenient high level access classes and methods for C++, Java and Python[1]. You may orient on this interface when designing the Python GRASS classes? Best regards Soeren [1] http://code.google.com/p/vtk-grass-bridge Example vector and raster processing in C++, Java and Python: http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Cxx/v.sample.rast.cxx http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Java/v_sample_rast.java http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Modules/Python/v.sample.rast.py vtk-grass-bridge Python unit tests: http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster/Testing/Python/GRASSRasterMapReaderWriterTest.py http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Vector/Testing/Python/GRASSVectorMapTopoReaderWriter.py http://code.google.com/p/vtk-grass-bridge/source/browse/trunk/Raster3d/Testing/Python/GRASSRaster3dMapReaderWriterTest.py 2012/4/1 Pietro <[email protected]>: > 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! > > Pietro > > [http://grass.osgeo.org/wiki/GRASS_SoC_Ideas_2012/High_level_map_interaction] > [http://docs.python.org/library/doctest.html] > [http://www.python.org/dev/peps/pep-0020/] > _______________________________________________ > grass-dev mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/grass-dev _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
