Python Geo Frameworks 2

Here, continuing on from my previous post, are some of the forces arrayed against an all-encompassing OSGeo Python framework:

Scarcity: few develop GIS applications using Python, fewer applications that would benefit from a global library, and fewer yet would contribute to the development of the global library. From my experience, you can't expect more than 3 people at the top of this community pyramid. That's probably not enough. And you can't really count on this number increasing very much in the future. Users want apps and data, not libraries and APIs. See Google Earth. Yes, there are exceptions, but Java, not Python, is their home.

Scale: GDAL, OGR, PROJ4, GRASS, QGIS, MapServer, ... data, analysis, projections, stats, graphical user interfaces, printed and plotted maps, service oriented architecture, ... that's a lot to keep in your head. Designing such a thing is a big job for a small team, not something you knock out in a week unless you join the GeoTools/GeoAPI cargo cult like I did when I started PCL (after which you'll realize that Python programmers don't want GeoTools). Programming in Python is more productive than programming in Java, or .NET, but designing Python libraries isn't any easier. Without a driving business need or lots of itch scratching (which won't happen, as I explained above), the task of designing a global OSGeo Python library is doomed by the size of its scope.

Physics: a Python library that depends on

• GDAL/OGR (and Xerces, etc)

• MapServer (and Agg, etc)

• GRASS

• QGIS (and Qt, etc)

is like a giant cinema spider, awesome on the drawing board, but in reality something that can't but collapse under its own weight. There are too many dependencies, too many of which have no current binaries, with incompatible Python bindings written by hand, or generated by SWIG or SIP. There's also a rather large amount of functional overlap among these projects, governance of which is something that GeoTools (which I'm continuing to hold up as a successful holistic library) doesn't have to be concerned about. I suspect the social and software engineering details haven't fully dawned on OSGeo developers yet. These details are not an itch I need to scratch, they are a patch of poison oak I need to avoid falling into.

Well, that's the verbose edition. The shorter history of PCL: it's brutally hard and there is precious little reward for the designer. I feel like there's more to write on Python and geospatial or GIS frameworks, especially with reference to the Python web framework debates, but that's for another day.