Hobu, Inc.

Hello again. My Plone site got trashed by the spammers, and I’m so sick of Plone that I just grabbed an RSS feed of my posts and plopped them into this Wordpress site. Yes, I know this is PHP. Weblogging in Python sucks.

Everyone’s reimplementing Python bindings to GDAL these days. Sean’s got one or two attempts, and the GeoDjango wrote ctypes bindings for OGR and GEOS. Neither of these efforts are as complete as gdal.py/ogr.py in the standard GDAL distribution, but they are going off and writing new stuff anyway. Why?

GDAL’s Python bindings are really C/C++ in Python form

The API in GDAL’s Python bindings is not at all pleasant to program with if you are a true blue Python coder. There are some gotchas because resource management is foisted on the Python developer who is not used to it, TheNamesOfThingsAreHardToReadSometimes, and the APIs don’t map to other standard Python ways of doing things.

I have been reacting to this by adding more sugar to GDAL’s bindings. Specifically, you will be able to call feature.items() and feature.keys() instead of manually fetching them in the upcoming GDAL 1.5 release. You can also do for ‘feature in layer’ and it will iterate for you. These minor improvements should make things a little better. If anyone has more suggestions for sugar that won’t impact backwards compatibility, let me know.

GDAL’s Python bindings are hard to deploy

GDAL’s deployment story in the past was miserable. Most people depended on pre-packaged Python binaries because it was so difficult to get them built, they didn’t install in a standard (setup.py/disutils) way, depended on external data (the GDAL_DATA directory), and polluted your site-packages. For GDAL 1.5, this story will be improved significantly:

• Setuptools/distutils is now used by default to build and deploy the bindings. I will be registering the GDAL bindings with the CheeseShop, and once available, you should be able to easily build your own bindings if you have the GDAL base library (and headers) installed.
• I am expecting to include the scripts/utilities and GDAL_DATA files *with* the Python package for distributions such as the CheeseShop one and the download.osgeo.org Windows binaries.
• The bindings are now in the ‘osgeo’ namespace, so you can do ‘from osgeo import ogr’ instead of just ‘import ogr’. Note that the old method will continue to work for a while as we deprecate things, but we’re moving in the right direction.

The reimplementers hate SWIG.

SWIG sucks. “Simplified” my ass. SWIG is a complex ball of stuff. If you only have one language to support, SWIG is the worst possible way you could choose to write bindings. If you have five or six languages to support, SWIG is the *only* way you can choose to write bindings and hope to not have to manually maintain thousands and thousands of lines of native interface code. SWIG does indeed suck, but without it GDAL would likely only have Python bindings… not Python, Java, C#, and Perl.

This entry was posted on Friday, November 16th, 2007 at 4:59 pm and is filed under gdal. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.