Jaime, all, On Tue, Apr 8, 2008 at 12:05 AM, Jaime Carrera <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering if someone could give me some kind of orientation on > how wxgrass accesses the list of raster/vector maps and both the > tables and columns for the latter. I've gone through the code a > couple of times, but I'm missing something.
I have no answer for you but I report an email from Howard Butler here (GDAL Python guru) which might be (partially) relevant to improve our code documentation. Perhaps I am wrong and it's all fine.. no idea :-) Here we go: [ http://lists.osgeo.org/pipermail/discuss/2008-April/003345.html ] On Mon, Apr 7, 2008 at 4:26 PM, Howard Butler <[EMAIL PROTECTED]> wrote: > > Markus Neteler wrote: > > > Hi OSGeo, > > > I would like to propose another idea which might be a (long term) goal > > > of OSGeo software development: > > > OSGeo Python Library > > > http://wiki.osgeo.org/wiki/OSGeo_Python_Library > > > Currently it is quite complex to set up a Python based OSGeo software > > > environment without knowing well the individual projects. It would be > > > great > > > to have a common abstraction layer/API which contains binding to several > > > relevant OSGeo and related software projects with Python bindings to > > > simplify programming. > > > Hacks to the Wiki page and comments welcome, ... > I think the most fruitful way to make it easier for folks to be able to use > Python for geo stuff is to ensure that projects do the following: > > 1) Embrace PyPI. I made a major push with GDAL 1.5 to allow it to be built > from *outside* the GDAL source tree. This means that a user can install > gdal-bin and gdal-devel with their favorite package management system and > then do "easy_install GDAL" and have working bindings. I would like to get > Python MapScript to this point as well, but doing so will require a bit more > effort than GDAL to get MapServer's source tree in shape (MapServer isn't > really split into -devel and -bin, it's all just a big ball right now). > Projects that aspire to be on PyPI and be easier to use from a Python > perspective should ensure they're using Python distutils/setuptools and not > require that an entire source tree of dependencies be available to build > themselves. > > 2) Leverage Python docstrings. I also made a lot of effort to include > Python docstrings in the OGR 1.5 release. I haven't gotten to GDAL's yet, > but I hope to in the future. doctests, which are Python's name for > combining documentation with regression testing, are also an excellent way > to provide leverage. Python users have been heavily conditioned to look for > doctests/docstrings in other Python libraries, and the OSGeo camp should > follow suit. > > 3) Support things like __geo_interface__ and numpy's array interface. > Python makes it so easy for everyone to write their own that everyone does. > There are bits that everyone can agree on, and those are the points at which > easy integration of the various libraries can be made. > > Howard > _______________________________________________ > Discuss mailing list > [EMAIL PROTECTED] > http://lists.osgeo.org/mailman/listinfo/discuss _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
