SLD and Python

Ireland topography and electoral districts

[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.

Comments

Re: SLD and Python

Author: Chris Holmes

Yay code sharing! I have no idea how relevant it is in the Python world, and if you can get the same implementation that's the way to go. But one compromise we go for with GeoTools is to encourage others to do the same interface, which allows people to do their own thing in implementation, yet makes it so you can share somem code.

Mapnik News

body_html_template

Comments

Re: Mapnik News

Author: J.F.

Sean, I think it's important to remember what Mapnik is meant to be: It is a C++ library for cartography, both for the web and desktop use. It never was intended to be pure Python ... The Python bindings to the core C++ API are just a nice feature. Hence, having the core library implementing SLD-like styling mechanisms is perfectly in-line with it's intent ... The fact the Python API ends up looking PCL'ish is coincidental really. So I would disagree that these are "mirror-world" implementations. One is a pure Python implementation (PCL), the other a pure C++ one (Mapnik) ... that just happens to have the option of being wrapped in Python! :) (Hopefully Boost.Ruby will evolve, and you'll have wrappers for that language too!) That being said I agree that PCL/Mapnik integration would be interesting ... I'm looking into it :)

GIS Features and JSON

I'm a big believer in GML, but not such a fan of XSLT. For many web applications, I want to bypass the transformation and directly get GIS features (whether by WFS or other service) as javascript objects. In PrimaGIS we are using JSON-RPC, and a data structure that is modeled after the GML simple features profile:

// feature collection
[
  // a feature
  {
    'id': 'aa1',
    'properties': {
      'name':     'Foo',
      'category': 1,
      ...
    }
  },
  ...
]

I'm curious if there are other programmers interested in a JSON simple features profile. The representation of non-geometry properties is obvious, but what about geometries? Is it better to aim at existing Javascript drawing APIs like WZ, or look to Canvas?

Foundation, Physics, and Fun

Jo Walsh has a post that's making me consider whether the open source geospatial foundation more or less addresses my concerns from last summer. Back then, when I typed "organic" I could have just as easily used the word "grassroots". I wasn't looking for ideological purity as much as something that was really of and for the existing community.

i-cubed Imagery in Yahoo Maps

My image processing mentor Yusuf Siddiqui wrote in to point out that i-cubed is the source for the new satellite imagery in Yahoo Maps. What a coup for Russ Cowart and his company! I worked at i-cubed programming data processing workflows until 2002, and they've been a customer of mine since then. It's great to see the company name come out big time along Navteq and TeleAtlas.

Ruby and GEOS

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.