I've been sketching out an alternative to the OSGeo Tiled Map Service for most of the spring. Not yet another standard, but an example of another, more RESTful way of providing tiles to a mapping client. I'm just going to scrap it now and point you to Chapter 5 of RESTful Web Services by Leonard Richardson and Sam Ruby.

The OSGeo TMS is composed of a general family of algorithms, parameterized by map scale and image coordinate origin, for finding the URL of specific map tile. The basic algorithm is coded within web map client applications, and the clients query a service for an enumeration of all the variants of the algorithm that it implements. The client application selects the optimal variant of the algorithm, and executes it to obtain the URIs of the map imagery it needs. The advantages of TMS over an OGC WMS are that map tile resources can distributed over any number of servers (it scales, trivially), and that clients can leverage the caching mechanisms built into the Web (If-Modified-Since and ETag, also known as conditional GET) to conserve bandwidth and improve performance.

The service outlined by Richardson and Ruby has all the advantages of TMS and one more: there's no requirement on map clients to possess or execute tile-locating algorithms. A request for imagery to such a service would return a document containing:

1. a link to the central map tile
2. links to that tile's neighbors

A map client would simply GET and render the central tile, and then traverse the links to build out a full map mosaic.

This is rather a lot like the RESTful feature services I wrote about in April: simply elegant, but also a hard sell. Mainstream GIS folks recoil in horror at the thought of relying on link traversal to render their maps. I think this is partly based on experience with under-performing OGC WMS instances, partly on discomfort with anything too different than desktop architecture (web-as-filesystem), and on the fact that there are no web-traversing map services in the wild. We're also following Google's lead in this area because its hard to argue with the success of Google Maps. Richardson and Ruby gloss over the fact that Google's map tile service is much more like the OSGeo TMS than their ROA (Resource Oriented Architecture) maps.

Lots of good stuff in the book. I hope the librarians out there appreciate my link to WorldCat instead of Amazon ;)

  <a class="nw-neighbor" ...>...</a>

Nice! Another food and drink (beer, at least) and GIS blogger. It doesn't seem like we'll agree on software at all, but I couldn't agree more about the goodness of Dogfish Head brews. I haven't had the Black and Blue yet, but it seems like it's right up my alley.

All spring, on the FRUGOS list, we've been chatting about having a Front Range geo-unconference. Now, thanks to Tom Churchill, we have a venue and the GeoSummit unconference is on.

When: 16 June, from 0900 MDT until topics and participants are spent.

Where: Churchill Navigation (map)

What: intense and fun discussion at the intersection of geography, location, and technology. Business, science, history, environment, transportation, software development, you name it.

People often report that hallway conversations and debates between (and sometimes instead of) scheduled sessions are the best part of conferences. An unconference is all about eliminating the boring stuff and getting right to these vital discussions.

The GeoSummit is not a BarCamp as such, but BarCamp is the model. Sessions will be created ad-hoc during the sign-in. No spectators. Everyone participates. Absolutely bare minimum sign-up fee. If you're interested, join the GeoSummit Google Group so that we can start to get a feel for numbers, and spread the word.

That's me, Voltron's left fist.

The Open Archaeology blog writes:

It's encouraging to see that such a large project benefits from free software and, at the same time, gives back to the community.

It would be great if also Pleiades data were available under a free license.

I think Pleiades is producing some nice tools, particularly for Python users. The OWSLib, Quadtree, and Rtree modules are, or have, Pleiades contributions. Our geocoding and slippy map Plone products are also getting playing time. However, to most historians and archaeologists the data is more important than the tools. New Pleiades data will be available under a CC or Science Commons type license, but the negotiation of terms for existing Barrington Atlas data (under similar license) is not quite finished. Fortunately, we're not petitioning solo: people like Eric Kansa, Ross Scaife, and Peter Suber (to name just a few) are making open access to scholarly data a very respectable enterprise.

It's great to see that three of my favorite hobby-horses -- REST over SOAP or WxS, web search over portals and one-stops, and open source over proprietary software -- are coming to the fore at mainstream industry events.

Howard Butler has just uploaded Rtree 0.2.0. Once you've installed the spatial index library on which it depends (no longer distributed with Rtree, see the README), installation should be as simple as:

$ easy_install Rtree

Maybe we can work the dependency into the easy install down the road. I welcome ideas on how to do that.

Persistence of indexes, nearest neighbor lookup, and item deletion are now supported. See the doctests for usage examples.