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.

Google Maps now groks GeoRSS. For example, here's a map of ancient bridges from map 65 of the Barrington Atlas:

http://maps.google.com/maps?q=http://pleiades.stoa.org/places/bridge.atom

Update: more coverage on the GeoRSS Blog.

Few details, but an interesting mention of JSON in the context of ArcGIS Server.

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);
}

07:21:42 < crschmidt> r783
07:21:46 < oltrac> http://trac.openlayers.org/changeset/783, at , by crschmidt:
                   Refactor GeoRSS Layer to support 'real' GeoRSS :) (geo:lat,
                   geo:lon).
07:21:47 < crschmidt> #541
07:21:51 < oltrac> Ticket #541: Drawing a single point takes inordinate amount
                   of time, http://trac.openlayers.org/ticket/541

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.

Not so much. Ephraim Lytle, in the Toronto Star, provides the real background for the truthy new battle-porn epic, 300.

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

Are you using JSON as a format for geographic data? Join the discussion: http://wiki.geojson.org/Main_Page.

Update: more.

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.

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.