The growing consensus is that map image and feature services can be (and should be) done RESTfully. Is there any aspect of web GIS that cannot? Geo-processing, perhaps?

Last week I started to roughly sketch out how one might RESTify an OGC Web Processing Service (WPS). Post data to a process resource, get back a 202 ("Accepted") response with a "job" URL to be checked for status ... more or less what Richardson and Ruby propose in Chapter 8 of "RESTful Web Services". Then I remembered that there is a different approach, at least for data that is already on The Web: pull your data through a processing resource with HTTP GET. Like Yahoo Pipes.

I've got a feed at http://pleiades.stoa.org/places/settlement/classical.atom. It contains the locations of human settlements in ancient Lycia and Pisidia attested to be occupied during the Classical period, and I want to find the intersections of their spheres of influence. For that matter, I'd like anyone to be able to find those intersections, using whatever radius they wish. Furthermore, I'd like to let people process practically any GeoRSS feed in this way.

To this end, I've made a process resource at http://sgillies.net/mush/self-intersection. You pull another feed through it via a URL like:

http://sgillies.net/mush/self-intersection/
?url=http%3A%2F%2Fpleiades.stoa.org%2Fplaces%2Fsettlement%2Fclassical.atom&d=10.0

The source data's URL is provided as the url parameter, and a radius of 10.0 kilometers is specified using the d (distance) parameter. Go ahead and get the result feed and display it using Google Maps.

Here are a couple more examples:

OpenContext projects feed, 200 km intersections

Geo-Annotated Reuters News feed, 100 km intersections

Interested? Feel free to try the user interface to the services at http://sgillies.net/mush.html.

Keep in mind that this service is just an educational toy. There's little support for asynchronous processing, and attempts to pull big feeds will certainly time out. Feeds with less than 50 or so intersections will be fairly responsive. YMMV. I'll try to keep it running as much as I can.

Intersection of 2 different feeds is obviously the next step.

Kurt Schwehr, who's making fink packages of OWSLib, Quadtree, and PCL-Core, is blogging about working on the Phoenix Mars Lander. Are these packages going to Mars, or helping from Earth? Let us know if the Lab can be of any assistance.

Update: more from Kurt.

It's been reported that the architects of the INSPIRE enterprise are likely to choose WS-*. Before the decision is made, they should read Benjamin Carlyle's lessons of The Web. The point Carlyle makes often, and better than almost anyone else, is the ability of Web-like architectures to evolve. Should INSPIRE's enterprise be a distributed object system, upgrading to new versions across the board simultaneously (and this certainly means rarely)? Or should it be more like The Web, allowing clients, servers, and data to be upgraded independently and as needed? Carlyle's blog is bursting with this kind of sound advice.

OGC web services have no uniform interface, and therefore are not well suited for RESTful architectures. That's the why not. A uniform interface is the core tenet of REST. Ron Lake has a comment here.

Let me remind readers that the Geo-Web-REST discussion group is open to the public.

Do GIS/geo blogs have any such impact on the media?

Via Slashdot.

Tom Kralidis asked the following question about OWS common metadata parsing, but it could be asked about almost any aspect of web GIS:

But then I thought why not just implement this in MapServer, and have the functionality exposed via mapscript?

Why write new web GIS software? Why not add to MapServer? I'm going to explain by analogy: it's like picking camping gear.

Call me soft, but I like filtered water, hot meals and drinks, shelter from the rain, and a warm bed when I go camping. For the sake of argument, let's call these the basic requirements for alpine camping equipment:

• water filtration and storage;
• heat source for cooking food;
• shelter from rain and snow;
• warm bedding;
• means of transporting the above.

There are 2 distinctly different philosophical approaches to meeting these requirements. The first involves acquiring:

• a hand-pumped sub-micron water filter, and several liter bottles;
• a compact single-burner kerosene stove, with pot, kettle, cup, and spoon;
• a weatherproof, folding tent with light, collapsable graphite framework;
• a sleeping bag and stuff-sack;
• a backpack.

The REI approach, if you will (disclosure: I am an REI member). The second approach is to get a recreational vehicle with everything (including the kitchen sink) built in. See where I'm going with this analogy? The RV is certainly convenient, but gives you no flexibility. The configuration of its components is fixed. None of them can be removed and used away from the vehicle. The REI approach, on the other hand, provides maximum flexibility. Want to camp kilometers from a road? Pack your gear in the backpack and walk. Water sources are far from your campsite? Take your filter and bottles to the source and carry treated water back. Maybe you're just "carpet camping" at a friend's ski cabin? Bring only your sleeping bag.

My projects require similarly modular, agile software tools. There are places that MapServer can't readily go, and that's why I'm working on OWSLib, Quadtree, Rtree, GeoJSON, and Shapely.

I'm stalking the "GeoWeb" buzzword via Technorati and found this prime specimen, which takes it to the next level with "GeoWeb Ecosystem". Most of my offline friends are ecologists, and they talk about little else, so I'm steeped in ecology and sensitive to the use of ecosystem in marketing.

If Google is the primary source of the "GeoWeb Ecosystem", then it's a pretty limited and fragile ecosystem. Like the organisms living off hydrogen sulfide leaking from a deep-sea vent, we must huddle closely around an API, pray to Neptune that it doesn't shut off, and dream of brighter, richer realms.

Completely untrue:

"It's like combining chocolate and peanut butter. They're good by themselves, but the combination is much more valuable than when they are served in isolation."

(John Hanke, Google's director of maps, in Business Week)

The combination of chocolate and peanut butter is in no way better than pure chocolate. To my dismay, Hanke appears to be either a barbarian, or one who cynically perpetuates the fraudulent premise of Reese's Peanut-Butter Cups.

Steve C.-P. pointed me to this bad analogy by David Chappell

To anybody who's paying attention and who's not a hopeless partisan, the war between REST and WS-* is over. The war ended in a truce rather than crushing victory for one side -- it's Korea, not World War II. The now-obvious truth is that both technologies have value, and both will be used going forward.

that Elliotte Rusty Harold picks off and runs the other way for a touchdown:

That's a nice analogy. Take it one step further though. WS-* is North Korea and REST is South Korea. While REST will go on to become an economic powerhouse with steadily increasing standards of living for all its citizens, WS-* is doomed to sixty+ years of starvation, poverty, tyranny, and defections until it eventually collapses from its own fundamental inadequacies and is absorbed into the more sensible policies of its neighbor to the South.

I enjoyed Martin Davis's love letter to the relational model, but would like to remind readers that object databases aren't entirely academic. The Zope Object Database (ZODB) is employed in Zope and Plone, and supports sites including the Nature Conservancy, the FGDC, the CIA, KCRW, the Brazilian Government, and many other regional or communal government sites. I appreciate relational databases (PostgreSQL in particular) and love SQL, but also appreciate being able to model data and manipulate it purely in Python.