Ed Parsons and Chris Holmes were at the GSDI-10 conference and have each written posts about "GeoWebs" and "Global Spatial Data Infrastructures" that touch one of my favorite topics: architecture. Ed says that it is time for grand data sharing designs to yield to an evolutionary approach:

So we need to move away from the "Grand Design" approach and build SDI's organically and simply, perhaps making use of the new Global infrastructures that companies like Google and Microsoft have made available to bootstrap the technology, and deliver faster benefits and to make the case for more in depth infrastructures at a later date.

It's great that the GSDI community is hearing this. Yes, Ed is pitching Google's services as he pitches the Web, but I think it's still an honest argument for the Web. The Web works: not only for Google, but for thousands of other business, governmental, and non-profit enterprises, and for billions of users.

I only need to make one little correction or addendum to these paragraphs in Ed's post:

The Grand Design approach does introduce an additional issue which is technology related, many of the current SDI projects are planned to deliver over decades, with technological developments continuing to move rapidly, it is difficult to plan to implement using a technology which will be obsolete years before the infrastructure goes live.., as it is today the best available standards as drafted by OGC are moving from basic http interfaces to the more web services friendly SOAP based interfaces, while the leading edge is looking to REST based interfaces.

Mostly right. When we say "REST", we mean protocols based on the HTTP application protocol, and the architecture that makes the Web a success. REST is not a radical prescription at all. When you consider that REST won the distributed systems architecture war, to take the losing approach forward seems much more radical.

Chris Holmes's presentation is focused on social change, top-down yielding to bottom-up, but when he writes (on slide 19) that GSDI should

build on what's out there, on successful architectures of participation.

there are to me clear technical implications: The Web has an "architecture of participation", and its architectural style is named Representational State Transfer, or REST. I don't fault Chris at all for not directly pointing out that the OGC architecture is misaligned with the architecture of the Web: it's a distraction from his social message and possibly demoralizing to GIS data managers. But I don't think you can for very long dodge the issue that a "GeoWeb" really demands a RESTful Web-like architecture, and something like HTML. Hypertext, not GetCapabilities() and GetData().

Anybody else ever play Steve Jackson's Illuminati card game? The "Gnomes of Zurich" jumped instantly to mind when I read that the "GeoWeb" conference is the "Davos of Geo" on Ron Lake's (written by Roisin Clarke?) blog.

In emails I've seen mention of a possible REST agenda at the conference. That would be a good thing.

I'm so glad Dave Bouwman made it out because the question of the night was: coming from an all-ESRI environment, how hard is it to learn and get up to speed on an entirely new software stack? It's hard, and I don't deny that, but Dave reminded people that you don't need to take on everything at once. I think it's easier to start using open source on the very front or back ends. Maybe just try OpenLayers as the map interface for a new project, or try gdal_translate or ogr2ogr for ploughing through data offline before it is loaded into your database.

Turnout was surprisingly good: 10 of us, which is even better, per capita, than the huge (25-ish) Denver meetup. The MapWrecker was sorely missed, but the up side of that is nothing was broken.

By coincidence, the local Hacking Society was also meeting at the Bean Cycle tonight. Conversation with Sean and Evelyn reminded me that I probably should have submitted a presentation on Shapely and other Python GIS software to the PyCon committee.

I had a longer post about the new WPS specification that I scrapped after I realized that it reduces to this: the OGC WPS working group gets the formats and parameters more or less right as usual (good), but still can't find any respect for HTTP as an application protocol (bad).

Web geo-processing came up at tonight's meetup in the form of this question: how do I compute zonal statistics on a raster over the web using open source? I said that GRASS would be part of the answer. It wasn't until the meeting broke up that I realized I'd neglected to mention PyWPS, which has a tantalizing kernel of Pythonic goodness.

Meanwhile, it looks like ESRI's ArcGIS Server might be the prime mover for RESTful geo-processing this year.

Update: or maybe it won't. This is not exactly an endorsement by Vish.

Umibot writes:

After some hard work/late nights and prodding from the geo-techno elite, we’ve humbly completed and are pleased to offer RESTful access to our neighborhood API.

In their "REST API", you can use either GET or POST (trampling the uniform interface) to invoke a remote method and get a JSON or XML response. It's better than SOAP, but I'm dismayed that this is hyped as REST.

To enable this is why I added an OWSRequest class and image byte access to mapscript. I'm glad they are getting used.

I was pleased to stumble onto Brent's blog a week ago: I spent my undergrad afternoons working in a molecular biology lab and still dabble in genomics. His genome browser inspired me to see OpenLayers as more than a web GIS tool.

Update: For some background on this particular inscription see Tom's post on the demarcation between Thraces and Moesi.

The subject of digitally annotating texts and art works came up at last fall's NEH/CNR conference, and I thought: we could do that with OpenLayers. Recently, I read this post at the Stoa Consortium and thought: we could really do this with OpenLayers. And that's what we did today at the Pleiades skunk works: put a photo of an inscribed stone in an OpenLayers image layer, drew polylines over it in a vector layer, and then wrote the layer out to SVG: http://sgillies.net/images/MXITRIB.svg.

Feel free to try it out: http://atlantides.org/inscriptol/. Once we add the capability to edit or delete polylines, add text annotations/metadata, and save the results this could be the beginning of a useful tool. Check out that nifty SVG transform group: maybe I haven't lost all my linear algebra yet.

OpenLayers simply rocks.

I think this says something: Google Maps Without the Scripting.

Update (2008-07-21): Everyblock WMS requests are gone, replaced by requests for tile resources at URIs such as http://tile.a.everyblock.com/1.0/main/4/77,502.png.