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.

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.

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.

GDAL 1.5.0 and GEOS 3.0.0 were released during the holiday and are now used in the Knowhere and Gdawg buildouts. The big change in GDAL is new Python bindings. The ones that Howard Butler has been calling the next generation bindings are now the official primary Python bindings. My benchmarks say 1.5.0 is a little (~5%) slower than 1.4.2:

sean@lenny:~/Projects/Gdawg$ ./bin/gdawgpy benchmark.py
WorldMill (Cython)
8951.09 usec/pass

ogr.py (new bindings)
24846.93 usec/pass

WorldMill remains faster at its tasks. The GDAL/OGR C API hasn't changed in 1.5.0, so WorldMill builds without a hitch.