Sean Gillies Blog

Frank Warmerdam's Geospatial Data Abstraction Library, GDAL, is a big part of the foundation of our open source GIS software stack, and the 1.3.0 release is now available for download.

This release corrects some GML parsing and spatial reference issues that I found in version 1.2.6. I'm only using a subset of GDAL's formats; there are improvements across the board. Hobu and Kevin Ruland have revised the GDAL and OGR scripting framework to make it possible to produce Java and C# bindings using SWIG. Perhaps even PHP, if SWIG support for that language improves.

Unfortunately for me, Python was the first scripting language for GDAL and its interface has a distinctly un-Pythonic feel. New language users have nothing but blue skies and can work with SWIG to make APIs with the right feel. Java users, for example, really want methods with a getFoo form rather than GetFoo for sake of consistency and clarity. This can be accomplished using SWIG's %rename directive:

%rename(getLayer) DataSource::GetLayer;

Perhaps it seems like a lot of work to some, but I guarantee that some Java user will make the time to do this. Hell, I would if I could, but there are too many legacy Python scripts out there to allow any such changes for the Python bindings. While I'm at it, I might as well wish for a pony ;)

I haven't looked at SWIG's online docs since the 1.3.23 release: when did they get so purty?

Before the OSG conference i chatted with Cameron Shorter about using mapbuilder with ZCO. I didn't have a chance to dig into it before the conference, and once there was too busy presenting to meet the mapbuilder folks. Too many presentations was a big mistake on my part, and I really should have spent more time watching and listening and getting clued in to mapbuilder earlier. It's a rich and fairly mature AJAX library, and consumes a wide range of OGC web services. Unlike its more glamorous counterpart, ka-map, mapbuilder doesn't depend on a non-standard tile server, and runs practically right out of the box.

In very little time I was able to traverse the mapbuilder-lib source distribution and load it into Zope as a tree of folders, DTML methods, and images. After instantiating mapbuilder configuration and models as more DTML methods, and creating a page template to mount the widgets, I had my first Zope and mapbuilder demo.

The first three layers come from NASA's OnEarth, and the fourth is from a WMS service implemented using ZCO on zcologia.org. Not bad performance from the ZCO WMS, though it's certainly not under the same load as OnEarth.

I've been forwarded a postcard of sorts from a GIS user in the U.S. Army Corps of Engineers which gives big props to MapServer and GDAL for helping to power their Katrina response. While analysts and engineers are using ArcGIS on their desktops and notebooks, our favorite open source tools are efficiently and reliably doing much of the grunt work. Moving earth and filling sandbags, if you will. I'm expecting Tyler Mitchell to have more details soon.

Artem Pavlenko's Mapnik continues to advance, and I'm still trying to keep an eye on this as a another potential rendering engine for PCL and PrimaGIS. Agg, Boost, thread-safety ... I welcome this, but since he's starting mostly from scratch, there is a bit of catching up yet to do. While simple, Artem's Hello World demonstrates again how good Agg can be for producing clean looking maps. Would be great to see some other layers, and examples of the feature-level transparency that MapServer lacks.

We're waiting until people get back to work to announce on Freshmeat, FreeGIS, and plone.org, but there is now a new PrimaGIS 0.5 release, supported by releases of ZCO 0.7 and PCL 0.10. This first release from the new project site features integration with the MochiKit AJAX library, compatibility with Plone 2.1, a users manual, and a host of other improvements.

A new mapnik release from Artem showed up on freshmeat right ahead of PCL 0.10.0. Mapnik sure does make an attractive map.

Tim Schaub wrote in about a javascript map scalebar that he's developed, and Kai is working with him to get it included with PrimaGIS. Now I don't feel so bad about deferring work on scalebars for ZCO.

Matt Perry has a great example of scripting the creation of Tissot Indicatrix circles with OGR. This is the only use of ogr.py that I've seen on the blogosphere since I posted my graticule recipe.

Update: http://zcologia.com/news/429/geometries-for-python-update/

The next release of PCL will include two new components: PCL-Spatial, and PCL-Data, industrial-strength geometries and an agile feature model for Python programmers. I'm going to write about geometries today, and about the feature model in a day or two.

PCL-Spatial is a Python package that wraps and extends GEOS. The Geometry Engine - Open Source is a C++ port of Vivid Solutions' Java Topology Suite, and is the open source C/C++ library for spatial predicates and geometric operations. It's used in GDAL, MapServer, and MapGuide Open Source, to name a few applications, and Safe Software and Autodesk are funding work that will eventually produce a GEOS 3.0 release.

Why not use one of the existing Python geometry modules? Good question. The short answer is that none of them are quite good enough. Everything out there right now comes up a bit short in capability, usability, or portability.

I had a good conversation with Artem Pavlenko yesterday. He showed me the improvement in mapnik labels and we agreed to think about -- and maybe even do something about -- sharing a feature model between mapnik and PCL. His comments were very encouraging, and I am eager to see more convergence.

MapServer 4.8.2, directed by Howard Butler, has been released. We've had a bit of trouble with 4.8.x, particularly with new symbolization features, but this release should get the project back on track. Many bug fixes in this one, including contributions from MapServer's newest commiter, Tamas Szekeres.

A while back I created an initial SWIG interface for GEOS (Geometry Engine - Open Source), focusing on Python. I have subsequently stepped off the SWIG train (they lost me during the big changes made at 1.3.28), but Charlie Savage is forging ahead. The focus is now on Ruby, but if SWIG's unified typemaps work as advertised, bindings for other languages should follow trivially.

One complication is that the GEOS C++ API is a moving target. If the new language bindings are derived literally (as I did originally) from a changing C++ API, your Ruby or Python scripts could be broken by new GEOS releases. This is the reason why I went with the C API for PCL's geometry module. I think Charlie will be able to tweak the SWIG interface to maintain a stable Ruby API, but this was something I found myself unwilling to do.

I try to keep readers updated on mapnik, which I hope will soon provide us (through Agg) with sexier maps than our trusty MapServer or MapGuide Open Source. I was quite disappointed when I learned that Autodesk's new application is also using good old GD. MapServer predates Agg or Cairo, but MapGuide OS has no such excuse.

Now, Jean-François Doyon has included a WMS with mapnik. This is cool, but then as I drilled down into the mapnik source I started to see a familiar Python anti-pattern at work: rather than use PCL's styling package (rules, and symbolizers, etc), mapnik reimplements them. What you get is code that is pretty close to the PCL demos, but with enough difference that there's no interoperability. Since PCL itself rips off, er, emulates GeoTools, I can't be offended, but do we really need two mirror-world implementations of SLD?

[PCL-MapServer output (full size, 145kb)]

I've been thinking a bit more about PCL and mapnik and their separate implementations of SLD. Compatibility would be great, but it might be easier said than done. The problem with sharing an SLD implementation is that mapnik is a C++ framework with Python bindings, while PCL is a Python framework with some C extensions.

Mapnik uses Boost.Python, which makes it very easy to access C++ code from Python. Going the other way is not nearly as easy. I can't tell yet if Boost's support for execution of Python is as good as what SWIG provides through directors. At any rate, to use the PCL styling classes, mapnik developers would have to get very intimate with the Python C API: PyObject_GetAttr() and friends. I assume the mapnik renderer has code that pivots on the C++ type of symbolizers, and some kind of adapter would have to be written. This isn't hard, but it's not trivial either.

MapBuilder 1.0 has arrived. Congratulations to Cameron Shorter, Mike Adair, and the rest of the gang. I've been following development of MapBuilder since just before version 0.4, and admire how the project has grown and progressed. The MapBuilder developers love their cutting-edge Javascript and XSLT web platform, and their discussions have a great energy. There's no shortage of ideas in this community. Most of all, I'm very happy that XHTML 1.0 compatibility is a feature in this release. It's the squeaky wheel that gets the grease, after all.