I left a comment on Jeroen Ticheler's blog, recommending Atom over RSS 2.0, which seems to have been eaten. Coincidentally, Dan Cohen reminded me today about the new ORE specification and its Atom serialization. I think there are some good lessons in ORE for the geospatial respository people. Atom as a format is one.

We have some graph-y plans for the resources of Pleiades and related projects that fit perfectly with ORE.

Very cool. Is this neogeogenomics? I hope the JTS/GEOS architects are equally pleased. You could do this with the OGR Python bindings of course, but since there are no projections involved, and no GIS data to read – only the comparably baroque genetic software formats – there's little point in doing so. I designed Shapely to provide simple spatial functions and otherwise get out from under the feet of your imagination.

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.

This is an fun coincidence: yesterday I blogged about PyWPS and applying open source GIS software to not-exactly-GIS problems in archaeology, and today one of the Ominiverdi (a company supporting PyWPS) developers blogs about an even more interesting application of that kind. Via Stefano Costa.

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.

By popular demand (okay, 2 people asked), you can now browse or clone the inscriptOL repo. I need to get back to the GIS-y aspects of Pleiades and won't be actively developing inscriptOL for a while, but patches are very welcome. SVG.js needs to be extended so that the format supports points and polygons as well as polylines. OpenLayers.Format.GML was my starting point and the difference between the polyline methods in the files should be illustrative. Code to browse and select source imagery, with setting of bounds and dimensions to appropriate values should also not be much of a task. Sound support for editing traced features is the most complex of the first things that need to be done to turn this into a serious tool.

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.