INSPIRE and Model-Driven Architecture

I'm trying to keep up with INSPIRE developments because I'm curious about how big time architects approach big time geospatial projects. I don't have time to ingest all the papers coming out of the INSPIRE community and am partially dependent on the recommendations of others such as Jeff Thurston, who is following INSPIRE more than any other blogger. I was surprised to see, in the European Commission's Data State of Play, such an emphasis on Model-driven architecture (MDA). Surprised in part because of Ed Parson's explanation of the conservative approach required by INSPIRE:

Now here is the rub, despite the fact that much of the INSPIRE directive is not expected to be implemented until at least 2010, it is been designed now and must used well specified and recognised standards - things like the ISO 19100 series of standards developed by the Open GeoSpatial Consortium.

It’s not difficult to appreciate the problem, REST based interfaces, KML, GeoJSON, GeoRSS etc might actually be the best technologies to use today and would be the tools of choice of many, however like many other Government IT projects INSPIRE needs to follow the low risk route of SOAP, WSDL, WMS, WFS etc.

Nevermind that I think Ed's assessment of WS-risk is wrong. Gartner's 2006 analysis had MDA 5-10 years out and nowhere near the so-called plateau of productivity that INSPIRE should be mining for technology. MDA is emerging technology. It is conceivable that, like CORBA (probably the most famous OMG technology), MDA may never really emerge into mainstream use.

Here's where I agree with proponents of MDA: code is not an asset. Under MDA, designers write models and code is generated by tools. The tools are presumably written by extremely talented programmers using bombproof processes, or by meta tools, or by a hierarchy of meta tools and AIs. Or idiot-savant demons from another universe where time runs faster. Theodore Sturgeon's Neoterics. Gods of programming. Ideally, the code generated by these tools would be of higher quality and lower cost than code written by merely mortal programmers. It would also be practically disposable. As Steve Vinoski explains, very few of us write machine code anymore, and MDA is just taking the abstraction to greater heights.

Lest you think I'm just talking through my hat, know that I'm actually "doing" MDA for Pleiades: we have an entity model in annotated UML from which we generate Python classes for Plone using the ArchGenXML tool. It works well enough, but I honestly think we're only just breaking even. Python is a terse language already, and learning and writing the UML annotations eats up the resources I would have spent writing Python code directly. Perhaps if we were using a language full of boilerplate and syntactic noise we would find code generation more productive. Certainly if productivity were measured by lines of code, but maybe also if measured by the time to deliver products. But we're not using such languages. We're using Python, which lets me accomplish the same tasks with the fraction of the code I'd need to write in C, or Java, or C#.

Maybe the INSPIRE community is overlooking a simpler and more mature solution to the overabundance of code problem: more productive programming languages like Python and Ruby? It's a large and sure step in the right direction.

Incidently, Vinoski's and Tomayko's views on definition languages and code generation came together Monday on Vinoski's blog. Lots of food for thought in that post.


Re: INSPIRE and Model-Driven Architecture

Author: Ed Parsons

Sean, Great post, it's not my risk assessment rather that of my perception of the establised community around INSPIRE. My view of the risk WxS type services meeting the needs of INSIRE are not that different from yours I would suspect. Time will tell as to the actual approach implementation takes, as you say it's not to late ed

Re: INSPIRE and Model-Driven Architecture

Author: Sean

Thank you for the correction and compliment, Ed. Is MDA as big a part of the plan as that document made it to be? Know any INSPIRE architects who can set me straight?

Technology is not Religion

An SOA governance platform based on AtomPub. Why not? Via James Snell.


Re: Technology is not Religion

Author: Ed Parsons

Sean, Great post, it's not my risk assessment rather that of my perception of the establised community around INSPIRE. My view of the risk WxS type services meeting the needs of INSIRE are not that different from yours I would suspect. Time will tell as to the actual approach implementation takes, as you say it's not to late ed

Re: Technology is not Religion

Author: Sean

Thanks, Ed. I think my commenting system may have misfired. I took the liberty of copying your comment above over to Okay?

Count the Pikas

Migrating poleward is not an option for every critter that lives on the alpine islands of North America. Pika range is decreasing.

"They've been driven upslope a half mile since the end of the last ice age," said Donald Grayson, an archaeologist and paleontologist with the University of Washington who has documented the presence of pika over the past 40,000 years.

"Pikas in general are now found at such high elevations that there's not a lot of places left for them," Grayson said.

Imagine the alpine landscape of North America as an ensemble of cones that top out at 3000-4000 meters and it's obvious that range decreases as the minimum elevation rises, and ultimately approaches zero. As in zero pikas.

In the Denver Post's other climate-related story today, the pine beetle infestation I wrote about last summer has crossed the Continental Divide big time and is spreading across the Front Range. The operant hypothesis is that mild winter weather is allowing more beetles to survive into the next season and infest drought-stressed pines. If there's any good news it's that my favorite tree, the ponderosa pine, is more beetle-resistant.

For a birds-eye view of the epidemic, search on "Rand, Colorado" in Google Earth and check out the red-tinged forest to the immediate southwest.

Shapely Windows Installer

Update 4 (2008-01-16): RC1 has been removed. See

Update 3 (2008-01-14): I have confirmation from a Vista user and uploaded the installer to the Python Package Index: Shapely 1.0rc1.

Update 2 (2008-01-14): Grab an installer with new and improved DLLs from the same URL below.

Update (2008-01-14): apparently the GEOS DLLs don't load on Vista. I'll have a fix ASAP.

Thanks to distutils, even a know-nothing Linux zealot like myself can make Python distributions for Windows. Shapely-1.0rc1.win32.exe [MD5, SHA1] includes GEOS 3.0.0 and with just a few clicks you get a fully documented Python geometry package. You'll need to install ctypes if you are using Python 2.4. Some users may need to install msvcp80.dll.

Shapely is distributed under the familiar 3-clause modified BSD license, which means that you're pretty much free to do what you will with it.

On Config File Design

MapServer's configuration file is probably the most familiar to my readers, and it has definitely evolved into a language or a group of languages with ever-increasing complexity. Adding support for an interpreted language like Python or Javascript is a neat way to add more power while keeping simple things simple.


Joe Gregorio's atompubbase looks promising. To try it out, I ran the apexer program against my Hammock site:

sean@lenny:~$ apexer service
sean@lenny:~$ apexer lc
0   Places
sean@lenny:~$ apexer collection 0
sean@lenny:~$ apexer ls
0   Theater at Hierapolis
1   Springfield/Ninoe
2   Springs at Hierapolis
3   Big Hendy Grove
4   Little Hendy Grove
5   Navarro Vineyards
6   Wehlener Sonnenuhr
7   Pic St-Loup
8   Vineyards Domaine de l'Hortus
9   Vineyards Domaine de l'Hortus
sean@lenny:~$ apexer entry 8
sean@lenny:~$ apexer get
sean@lenny:~$ cat entry
<?xml version="1.0" encoding="utf-8"?>
<entry xmlns=""
  <title>Vineyards Domaine de l'Hortus</title>
  <link rel="alternate" type="text/html"
  <link rel="edit" type="application/atom+xml"
  <link rel="edit-media" type="application/"
    Mourvedre, according to
    <gml:Point xmlns:gml="">
      <gml:pos>43.7896297407 3.83361116447</gml:pos>

I edited that entry and posted it back to the collection:

sean@lenny:~$ apexer create entry --content-type="application/atom+xml"
sean@lenny:~$ apexer ls --all
0   Theater at Hierapolis
1   Springfield/Ninoe
60   Duplicate Vineyards Domaine de l'Hortus

See the result. Publishing geodata can be as simple as that. I don't think AtomPub is going to take over the geospatial world in 2008 -- few of our architects have even heard of it yet let alone begun to dabble outside WxS -- but we'll see a few more high profile implementations. Google Earth as an AtomPub client maybe? The services (Picasa, YouTube, etc) are certainly there already.

Parts is Parts

A service is a service, says James Fee. Well, maybe, if you overlook a score of architectural and implementation details like protocols, wire formats, governance, terms of use, data quality, etc. Another way to look at his post about the range of choice in software and services, if I'm not misreading it, is that the time is ever better for opportunistic companies to step out from behind the aegis of the monolithic platform and start serving customers creative, evolvable, and rightly-engineered solutions.


Re: Parts is Parts

Author: James Fee

Fair enough, every service isn't created the same. What I was getting at is I feel that current GIS implementors need to look at the end product before settling on a specific web service. Too many times I hear of the platform being presented before the product is developed. You just limit yourself that way.

Re: Parts is Parts

Author: Paul Ramsey

No kidding, James, and the prescriptive attitude is one of the things I find most annoying in the consulting business. I don't start a carpentry project with a parts list, I start with a general idea, which I hone into a design, and then finally turn into a parts list. Imagine what I would turn out if I was pre-committed to only using 3-inch nails and leather hinges. However, vendor-centric mindsets are not in short supply in the decision-making halls of organizations large and small.

Plone Geo Interoperability

Update (2008-01-09): I have a demo running. Try the KML document at in Google Earth (should launch for most of my blog readers) and see how you can navigate back to Plone through the link in the placemark bubble.

Yesterday I made a beautiful little ASCII chart showing the gap between Maps and the zgeo packages. Maps has a slick Plone widget for geo-referencing simple location content, and a map view mode for containers that beats the one I implemented for Pleiades. If all your locations are point-like and are going to be viewed exclusively through your Plone site, Maps is pretty much all you need. On the other hand, if you want to serve your geo-referenced content out to the "GeoWeb", view it Google Earth, remix it using Pipes (or Mush), or analyze it in a internet GIS application, you need the features provided by zgeo.*.

Zope's component architecture was designed in part to make it easier to bridge such gaps. Since I'm the one arguing that there is a real benefit to a less naive GIS approach, the obligation to build the bridge is on me. Geographer is my solution. It allows Plone content to be annotated with rich geospatial metadata and provides interfaces useful for generating KML and GeoRSS documents for the GeoWeb. It also adapts Maps Location objects and other content annotated using the geolocation product so that these objects can be represented in KML or GeoRSS documents or analyzed in modern GIS software.

I tested it with Maps this afternoon and made Atom + GeoRSS feed and KML documents from a folder of locations with the zgeo.atom @@atom-search-feed and zgeo.kml @@kml-document views.

The Geographer wiki page has installation instructions for Plone 3. The tricky part for a conventional non-buildout deployment is installing the zgeo packages into your Plone python and installing the ZCML slugs into the instance's etc/package-includes directory. If you drop Geographer into your site's products folder without doing the above, your site will break. Get it right and you can try the above views on folders of your existing geo-located content.

It's far easier to use a Plone buildout, and I'm providing one. All the zgeo packages will be installed and configured. The Maps product is included as well. Get it from the repository and build it out like this:

$ svn co pgx
$ cd pgx
$ python
$ ./bin/buildout
$ ./bin/instance start

This will start Zope 2.10 on port 8080 with a manager role, username: admin, password: admin. From here there are 4 steps to geo-referenced content:

  • Create a new Plone site through the ZMI with id "plone"

  • Add a new top-level Folder "places" as a container for geo-referenced content.

  • In /plone/places, make a new Page with id "test"

  • Go to the location http://localhost:8080/plone/places/test/@@edit-geo-form, enter [0.0, 0.0] in the coordinates field and submit. Yes, I know, the Maps widget is much better. I'm working on it, believe me.

Now you have a geo-referenced page. You can get a KML document representing the places folder at


That's Geographer and zgeo.* in a nutshell.

Geography on Plone

By request, here's a repost of the summary of geographic software for Plone that I sent to the PrimaGIS and PCL community email list:

Maps and PloneGoogleMaps are about georeferencing your existing and new Plone content. They embed tools to geo-annotate (with lat/long) your contents and embed map portlets to view them. Like Eric said, Maps and PloneGoogleMaps can't connect to PostGIS and, as far as I know, can only handle points. If Plone is the major piece of your intranet and you don't have any other spatial data, then these products could serve you well.

PrimaGIS does connect to PostGIS and in the Plone 3 branch will deliver feature data to an OpenLayers map using JSON, but this is probably too heavyweight. Generally, PrimaGIS is a solution when Plone is the major piece of your intranet and you do have other spatial data (shapefiles or spatial databases).

I'm developing a slightly different set of software for my Pleiades project. Plone is just one piece of our system, and we're mainly interested in getting our spatial data out onto the "GeoWeb" so that our community of classicists can view it in Google Earth, Google Maps, or whatever. My new Geographer product for Plone 3 makes GeoRSS and KML views of content which can be handed off to other viewers, perhaps even an embedded map.

Those are the three clusters of spatial tools for Plone as I see them.

If the Maps or PloneGoogleMaps products supported external KML files (which GMaps does), you could stand a simple web service up in front of your PostGIS database to create KML docs from the database. Christopher Schmidt's FeatureServer perhaps. I like this approach in general: an intranet of small apps that can evolve independently instead of doing everything within Plone.

Just for fun, I'll graph the approximate location of the 3 clusters in the space of degree of Plone-centralization of data and Plone-centralization of data interaction/analysis:

(Data) 1 |
         | zgeo.*        Maps
         |           PrimaGIS
       0 +---------------------
         0         (Analysis) 1

Maps and the zgeo.* software are equally focused on geo-referenced Plone data. Their approaches to presentation and analysis are different: Maps is used exclusively through Plone sites while zgeo is concerned only with the production of documents (GeoRSS or KML) for use in other web applications.