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.

Update: I made the example a little more clear by pulling the filter out of the wfs:Query.

In a previous post, I wrote that a more RESTful WFS should never accept POST as the HTTP method for a query. Well then, what to do about huge filters? IE limits your GET URI to 2K characters, and Apache will handle only up to 8K. A WFS filter containing literal geometries (like 1:250K boundaries of Norway -- potentially megabytes of fjords) could be many times larger than these limits. So, POST them, although it would be a shame to have to send the filters again for another request?

No. Posting a query destroys the uniform interface, and should only be done if there is no other option. In this case, there is another option, and a fine one: implement filter resources subordinate to feature type resources. The filtered type could then be accessed in the same manner as the feature type itself. The URI:

/places

is a feature type, and:

/places/filters/asdf

would be a subordinate filtered type. You'll recognize that this approach is not very different in concept from a Technorati watch list or a Google custom search engine.

  /places/filters/21f10d70b724f5215cb183d96f27053e/features?type=High+School

  /places/schools?type=High+School

XLink is part of GML, but I've never seen a WFS return GML that links to other resources. Does anybody use GML like this, and what client would they use?