REST and GeoRSS may be alpha-geek stuff and not quite yet ready for the masses, but, Ed, you're not helping when you frame them as lite technologies (emphasis mine):

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.

So we may find that organisations will use OGC style interfaces to communicate to other public sector organisations and the commission, while using lighter weight technologies to publish information to their citizens. This is no bad thing !!

HTTP REST is not about light weight (RFC 2616 is just as heavy as a WxS spec), it's about working with the grain of the Web.

The final paragraphs of Ed's (excellent, despite my one quibble) post hint at the biggest risk from using SOAP and WxS:

I am however disappointed by the continued focus on metadata driven catalogue services as the primary mechanism to find geospatial data, I don't believe this will work as nobody likes creating metadata, and catalogue services are unproved.

INSPIRE needs GeoSearch !!

Agreed. Service and data discovery is seriously hindered by the fact that SOAP and WxS services aren't of the WWW.

Update: I just received a reminder that numpy.asarray doesn't copy data.

Here's an example of using Shapely to connect OGR data sources to Matplotlib:

import ogr
import pylab
from numpy import asarray
from shapely.wkb import loads

source = ogr.Open("/tmp/world_borders.shp")
borders = source.GetLayerByName("world_borders")

fig = pylab.figure(1, figsize=(4,2), dpi=300)

while 1:
    feature = borders.GetNextFeature()
    if not feature:
        break

    # Make a Shapely geometry from exported WKB
    geom = loads(feature.GetGeometryRef().ExportToWkb())

    # Wrap the geometry in a Numpy array, slice out lat/long, and plot
    a = asarray(geom)
    pylab.plot(a[:,0], a[:,1])

pylab.show()

The result:

I hope you'll agree that this is considerably simpler than the code I used at the 2005 Open Source Geospatial workshop. An even more direct solution for ogr.py fans would be to provide the Numpy array interface directly from OGR geometries.

I dropped the blogroll from my blog's home page since it wasn't accurately reflecting what I read. Go ahead and unlink me if you're keeping score.

body_html_template

So, everybody has linked to Bruce Sterling's recent piece for Wired, but it seems like nobody agrees with me that the best part is right at the top where he sends up geobloggers and the way they (in the future) shill for shiny toys:

My new Sensicast-Tranzeo 3000 is everything palmtops and cell phones have been struggling to become. I can already feel this device completely changing my life. And a wireless consortium pays me to promote it! You should buy one right now. See that handy link there? Did I mention the free shipping? This mobile is so location-aware, it can ship itself!

I wonder if Sterling isn't reading Planet SpaceNavigator/N95/iPhone.

My wife has deep roots in Northern California, and that's where we're headed on vacation: some vino-tourism in the Anderson Valley and lazy days on the Mendocino and Sonoma coasts. Our neighbors (thanks, Dan!) have promised to keep the yard and garden alive during this dry stretch. If anyone can keep the Overton windows moving on WxS and REST, and make sure that GeoDRM doesn't creep out of the basement, I'd be much obliged.

Interest in WFS for Zope/Plone is rising again. The happy future I envision for geographic computing in the digital humanities is more RESTful than OGC, but I still need to provide a way for people to get Pleiades places into the desktop GIS that they bought and installed within the last few years. For now that's WFS, though I expect we might also make shapefile snapshots for people on legacy systems.

I've identified a veritable continent of common ground in Zope for services that I consider to be otherwise orthogonal: WFS and the Atom Publishing Protocol (APP). We Zope users routinely use containers (think of a container as a dict or hash) to model our information systems. In this design, a container full of geo-referenced content, like "places", becomes a WFS feature type or an APP collection. Some such containers are aggregated in yet another, like "root", which becomes a WFS or APP service.

For APP, we register an atomserv view on the outer, service container, and an atom view on the inner, collection containers. These views return APP service and feed documents. Add HTML (and perhaps JSON) views of the collection items, and you've got a geo web service that also happens to act a lot like a web site. Every resource is directly addressable.

WFS is RPC, and has no surface, but rather an endpoint. That endpoint is entirely implemented by the wfs view registered on the outer, service container.

Below the views, there is a big potential for sharing and reuse of interfaces and adapters. I envision that all these views will be acting upon the same IGeoService, IGeoCollection, IGeoItem, and IGeometry.

It's been pointed out that Google Earth has reinvented syndication where GeoRSS might have been used. Andrew Turner has a proposal for the right way to do it.

If you're interested in the expert/amateur debate, you must read the latest from Clay Shirky:

Digital and networked production vastly increase three kinds of freedom: freedom of speech, of the press, and of assembly. This perforce increases the freedom of anyone to say anything at any time. This freedom has led to an explosion in novel content, much of it mediocre, but freedom is like that. Critically, this expansion of freedom has not undermined any of the absolute advantages of expertise; the virtues of mastery remain are as they were. What has happened is that the relative advantages of expertise are in precipitous decline. Experts the world over have been shocked to discover that they were consulted not as a direct result of their expertise, but often as a secondary effect -- the apparatus of credentialing made finding experts easier than finding amateurs, even when the amateurs knew the same things as the experts.

This applies to mainstream GIS as well. Who was the go-to person for GIS data formats before blogs? Frank Warmerdam. Who's the go-to person today? Frank Warmerdam. A million amateurs typing in their blogs about the pros and cons of various formats hasn't changed that in the least. Likewise, a million amateur heatmaps won't reduce the value of a sharp spatial statistician. What has changed is the situation for people with industry credentials but only marginal expertise.

For what it's worth, here's the result of a quick search for REST on the agendas of some of this year's GIS conferences:

• ESRI User Conference: 1;

• GeoWeb: 0 -- exclusively OGC, SOA (meaning SOAP), or OGC-SOA;

• FOSS4G: 2 (so far) -- I figure the OSM talk will broach the subject -- and at least 9 presentations and workshops based on OGC, or SOA.