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.

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

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.

Update 4 (2008-01-16): RC1 has been removed. See http://pypi.python.org/pypi/Shapely/1.0rc2.

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.

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 http://sgillies.net/hammock/index.atom
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="http://www.w3.org/2005/Atom"
  xmlns:georss="http://www.georss.org/georss">
  <title>Vineyards Domaine de l'Hortus</title>
  <link rel="alternate" type="text/html"
    href="http://sgillies.net/hammock/places/10.html"/>
  <link rel="edit" type="application/atom+xml"
    href="http://sgillies.net/hammock/places/10"/>
  <link rel="edit-media" type="application/vnd.google-earth.kml+xml"
    href="http://sgillies.net/hammock/places/10.kml"/>
  <summary>
    Mourvedre, according to http://www.wineanorak.com/hortus.htm
  </summary>
  <author><name>anonymous</name></author>
  <published>2007-08-06T16:57:40-06:00</published>
  <updated>2007-08-06T16:57:40-06:00</updated>
  <georss:where>
    <gml:Point xmlns:gml="http://www.opengis.net/gml">
      <gml:pos>43.7896297407 3.83361116447</gml:pos>
    </gml:Point>
  </georss:where>
  <content/>
</entry>

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.

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.

Update (2008-01-09): I have a demo running. Try the KML document at http://sgillies.net/pgx/locations/@@kml-document 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 http://svn.gispython.org/svn/zope/geo-products-example/trunk pgx
$ cd pgx
$ python bootstrap.py
$ ./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

http://localhost:8080/plone/places/@@kml-document

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

Interesting. And just the other day Joe Francica was telling us that polar bear numbers are actually increasing. I think that was the moment that All Points Blog jumped the shark.

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.