On Apr 7, 2008, at 7:52 AM, Frank Warmerdam 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,
Markus,
I think to a large extent the Python Cartographic Library and related
efforts aspire to do this. They provide a very pythonic interface
to projects like GDAL/OGR, MapServer, PROJ.4, and so forth. I have
added a brief note pointing to http://gispython.org/ but I think any
real effort to progress on this should involve understanding what is
already there at gispython.org. It might be fruitful to discuss the
idea with Sean Gilles or Howard Butler who are knowledgable about
the existing python interfaces.
PCL is actually moving the other way. Rather than a unified,
monolithic wrapper around the entire Python geo world, Sean and co.
have been breaking things up into smaller pieces with common API (like
__geo_interface__). Examples of this approach include libraries like
Shapely (builds on GEOS), Rtree (builds on Marios Hadjieleftheriou's
spatialindex), OWSLib (OGC capabilities parsing and functionality),
and WorldMill (yet another GDAL/OGR binding).
The downside of a monolithic wrapper of everything is that getting the
dependencies together is downright overwhelming for most folks.
Additionally, often people only want individual pieces of the pie --
spatial indexing or geographic algebra -- and don't need everything.
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
Discuss@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
