Geo-Enterprise to Geo-Web

Ron Lake's The Architecture of the GeoWeb mishandles a subtle point of the Web's architecture. Web crawlers don't find and read files, they traverse the web of resources, URL to URL, and parse the documents that represent those resources. The contents of enterprise spatial databases are not passed over because they are not files, but because they have no URLs. They are not of the Web.

Any Rails, Django, or Zope (for example) application has resources that are stored in a database, and these are duly indexed because they have URLs. The geographic places of Pleiades, such as Antiphellos/Habesos, persist in an object database (ZODB) and have URLs. These places are connected to the Web by virtue of their links from other documents, and are spatially referenced by linking to KML or GeoRSS representations. This is a geo-web architecture that truly builds upon that of the Web.

Go read Lake's post. It's a good overview of new web spatial indexes, and the current isolation of enterprise geo-data from the Web.

Trac Changeset Links from Chatzilla

Update: Chatzilla 0.9.78 breaks this script. Looks like I'll have to add some priority levels to the munger rules when I get some spare time.

Update: New version 0.2, here, allows per-channel Trac sites.

Following this tutorial, I just wrote a Chatzilla script that makes links to Trac changesets from IRC text matching /r\d{1,6}/. You enter:

r42

and you see:

<a href="http://.../changeset/42">r42</a>

It's a bit rough (no per-channel control) but useful enough.

Under your "Auto-load scripts" directory, create a sub-directory named "trac-rev". Save the following script as trac-rev/init.js and modify the changeset URL accordingly:

CHANGESET_URL = "http://YOUR_PROJECT/changeset/%s";

function initPlugin(glob)
{
  plugin.id = "trac-rev";
  plugin.major = 0;
  plugin.minor = 1;
  plugin.version = plugin.major + "." + plugin.minor;
  plugin.description = "link to trac revisions";
  client.munger.addRule(
    "trac-rev-link", /(?:\s|\W|^)(r\d{1,6})/i, mungerTracRev, 1
    );
  display(plugin.id + " v" + plugin.version + " enabled.");
}

function mungerTracRev(matchText, containerTag)
{
  var number = matchText.match(/(\d+)/i)[1];
  var anchor = document.createElementNS("http://www.w3.org/1999/xhtml",
                       "html:a");
  anchor.setAttribute("href", CHANGESET_URL.replace("%s", number));
  anchor.setAttribute("class", "chatzilla-link");
  anchor.appendChild(document.createTextNode(matchText))
  containerTag.appendChild(anchor);
}

Comments

W*S and REST, Again

I'm experimenting with watching Planet Geospatial less, and stalking more keywords on Technorati. This led me to a blog I hadn't seen before, and a post asserting the RESTful-ness of OGC W*S, a notion that I thought we'd put to bed last year.

Statelessness, HTTP transport, and use of URLs are necessary but insufficient elements of RESTful architecture. Statelessness is only one aspect of "hypermedia as engine of application state". Using HTTP as a simple pipe, ignoring request and response headers, is not RESTful. Finally, the important thing about URLs is that they can be dereferenced to obtain a resource. This WFS query:

http://example.com/cgi-bin/wfs?
  typename=PointsOfInterest&
  maxfeatures=50&
  SERVICE=WFS&
  VERSION=1.0.0&
  REQUEST=GetFeature&
  SRS=EPSG%3A4326&
  BBOX=3.048788%2C36.755769%2C3.071012%2C36.773231

is not a resource URL. It's a remote procedure call.

Comments

Re: W*S and REST, Again

Author: Allan

OK, I'll bite. To what extent would a collection of GML objects returned by a query be a resource no matter how you request it? Or, put differently, how would you do the same thing in REST? I guess in database terms, you could define a View as a query and then the resource would be the view. Or the view would be the resource. In that case, then it would see to me that http://example.com/cgi-bin/wfs?view=[query expression] would point you at a resource. Then if you substitute the actual WFS request for [query expression] you have REST. So REST depends on the plausibility of calling the thing you get back a resource. I think early on Ron Lake was pushing XQuery, Xpath, and XLink as the means of doing what a WFS does. Would that me more RESTful? I'm neither a full-bore student of REST, nor a database person, so the distictions may be too subtle for me.

Re: W*S and REST, Again

Author: Paul Ramsey

It is not clear to me that the W*S baseline as currently defined can be mapped neatly into REST. The example that has the most resonance for me is WMS versus Google Maps. Both provide a way of getting maps on your screen. By pivoting the problem slightly, Google Maps is able to provide a completely RESTful solution to the problem (every tile is definitively a resource). Now, I could flip WFS into REST easily enough, by defining each feature as a resource. But I am not sure how scalable that approach would be. At some point you need to query. And frankly, that aspect of RESTful handwaving still eludes me: how is a REST query operation any less of a schmozzle than any other web services query? And once your data domain gets large enough that the only practical way to work with it is via query mechanisms, is it still possible to see the RESTful aspects of the design behind all the querying? At that point does REST not degerate into the much simpler "I push XML over HTTP, and try to respect the HTTP operations and headers while doing so".

Re: W*S and REST, Again

Author: Sean

You misunderstand me. Queries are essential to a RESTful GIS. I'm only reminding readers that WxS is RPC, not REST.

Re: W*S and REST, Again

Author: John Caron

We are trying to define a RESTful alternative to W*S. I would really appreciate understanding why "WxS is RPC, not REST" and how to do the same thing RESTfully. My best guess would be something like http://example.com/cgi-bin/wfs/PointsOfInterest/EPSG%3A4326? BBOX=3.048788%2C36.755769%2C3.071012%2C36.773231& maxfeatures=50 The role of query parameters vs. URI path is rather confusing.

Mr. Plow, Meet the Plow King

How annoying. At least ArcSDE on PostgreSQL will be interoperable with PostGIS. If OSGeo is right, that's the best deal we can get.

Simpsons reference: 9F07

Comments

Re: Mr. Plow, Meet the Plow King

Author: Andy

I don't think it is a big deal that they will be providing their own types. We will just have to add that to OGR and then we can convert back and forth between them and whatever else we need.

Another REST sighting

Dave Bouwman points out the low profile of REST in the ESRI developer world at the tail end of a blog entry. RPC and SOA own these people.

The thing that really surprises me about the survey is that IronPython barely gets on the radar. ESRI and their users should be all over IronPython.

Different Perspective on ESRI and FOSS4G

Jachym Cepicky has kindly made an English translation of an entry I found yesterday.

Certainly this means more money, more attention of media, which means also more attention of the public and more customers. On the other hand, I would not say, there would be more money or even developers in projects like GRASS or MapServer or PostGIS or any other great program at once.

Comments

Re: Different Perspective on ESRI and FOSS4G

Author: Allan

I think everyone should click through the link and read Jachym Cepicky's entire post. Well said!