[OSGeo-Discuss] Proposal: OSGeo Python Library

[Howard Butler]

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