A Specification Grows in Cyberspace
E-mail lists and blogs covered the Open Source Geospatial Foundation's (OSGeo) announcement of a Tile Map Service Specification last week. It's a vision that springs from a real world problem: Web Map Servers (specifically those that offer free/public data via the OGC's Web Map Service Specification) go down or get bogged down. That means that the Landsat data you were counting on to use as the background for a map may be slow to show up or never reach you. Schuyler Erle offered up a vision to solve this situation at the Open Source meeting in Minneapolis last year (document here).

Erle’s animated presentation (it was a lightening session) and the fact that so many in the room (myself included) had "been there" provoked a lot of response. In brief, and not too technically, he envisioned a series of servers that cached commonly used public data and could redundantly serve it up, really fast. That idea seems to have grown to include the idea of tiles and a standard way of calling those tiles. The interest from last year apparently continued to this year's FOSS4G conference held in September, resulting in, among other things, a wiki.

Some bloggers have examined practical issues - like where to store data and not pay too much. Other bloggers examined the idea in general, including our own contributing writer Simon Greener.

It is nice to see the use of tiled map libraries becoming more visible and getting some respect. Post MrSID and ECW, there was, I think, a presumption that technology like image catalogs were "old technology" and we know what such a pejorative tag being "old" is in the buzzword driven world of modern IT.

It appears that the increased visibility of Tiled Map Services, such as Google Maps, etc., has meant that the issue of image catalog use is being revisited.

About time.

This is not well understood internally yet. On the one hand, I don't want to take on a "standards process" as a part of our mission. I am generally pleased to have OGC, ISO, IETF, etc take on that role which is a hard one.

On the other hand, we have lots of folks on different projects interested in establishing some defacto common approaches, which in some cases might later be taken to a formal standards organization.

Whether we formalize this in any way is still open to debate. There are those that would like to see OSGeo as a home for lightweight standards like GeoRSS and tile spec standards.

• OSGeo brought together enough players to agree that this is a common problem.
• OSGeo enabled members and the open source community to get together to propose a solution without any formal standards process. This is not unlike how GeoRSS got going, though it was not under any organization's (OGC, OSGeo, W3C's) auspices.
• OSGeo has not ruled out anything at this point - OSGeo might do standards, or it might depend on existing organizations to formally vet what it produces, or neither of the above.
• OSGeo, like GeoRSS.org, has put out a document that people can begin to explore. To date, I've found one implementation from Paul Ramsey at Refractions.