Richardson and Ruby's RESTful Maps and Gazetteer
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:
a link to the central map tile
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 ;)
Comments
Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Keyur
One problem I see with this approach is that every tile fetch incurs 2 GETs - one for the document that contains info about the central tile and its neighbors and another to actually fetch the tile image. An approach that I can think of is - one GET to fetch the metadata about the entire tile grid for a given level and then the client constructing URIs based on this metadata and directly GETting tile images. I understand that URI opaqueness is the better practice when it comes to linking resources but when it comes to fetching a resource "grid", constructing URIs is a fair compromise. Both GMaps and VE have gone the path of constructing URIs and it works out quite well.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Sean
I agree, URI construction seems to be the way to go for homogeneous, gridded data. Still, how bad would the double GET be using persistent HTTP connections? Is pure link traversal orders of magnitude slower, or just somewhat slower?Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Allan
I appreciate the RESTfulness. But REST doesn't quite do everthing that's needed, does it? I get back a list of 9 tiles. How would a program know which one goes where? There either has to be just the slightest non-opacity in the URLs that a program can latch on to, or the list of URLs has to be ordered in a way that can be gleaned by the program. One of the tenets (or escape clauses) of REST is that the resource could also provide the Javascript code that knows where the neighbors go. But then the consumer would need a description of the API of the Javascript. Thus there would still be a need to know some a-priori magic that can't be glossed over. I guess I better read the book! It's on my "saved for later" Amazon list. I just bought a Ruby book and a Rails book, so it's going to have to wait.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Allan
Persistent connection or not, the second GET can't happen before the results of the first one are received since you need to do a GET on what came back. You can't have any benefit of pipelining, so to fist order, you incur two round-trip times in the pure REST approach where you would have one plus some small increment in Keyur's approach, and exactly one round trip time in a completely parameterized approach. When you measure ping times of ~50msec or larger cross-country or 200+ in non-broadband parts of the world, round trip times add up.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Sean
Allan, this book is filled with Ruby code. How to assemble the tiles? At the very least, you'd need a microformat One could argue that extracting these microformatted links is also an algorithm, but it sure is a dirt simple one.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Paul Ramsey
Yes, this is good. The me-and-my-neighbors approach is good, and can be scaled up to an arbitrary NxN metatile, with links to children and parent. It has the same odd performance characteristics as the pure REST feature server though, in that, if I am coming to the service at a high resolution, I have to start at the low resolution root and traverse documents all the way in until I get to the effective resolution I am interested in and can fetch actual imagery. I guess the "problem" with all rest approaches to image services is that a metadata document is pretty much required in order to explicate the structure of the imagery -- unless one uses URL construction. Note that this is basically the same approach as KML <Region>s.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Leonard Richardson
Hi, I don't want to butt into your conversation, but if you look in chapter 8 of RWS you'll see a discussion of constructed URIs vs. links, that shows the tradeoffs in the context of chapter 5's map service. The section is "why connectedness matters".Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Sean
I definitely see how connectedness matters. My major criticism of the so-called "Geo-Web" is how poorly linked everything has been. There's no web there (here, for example). I'm using links extensively in my current project (not a map imagery service). However, the enterprise GIS developer's solution to integrating new, more detailed source data (after all, we can get the road vectors themselves) would be to render it into new gridded map imagery at the same scale, maintaining their powers of two (for example) scheme for URI construction. There are, of course, maps for which no source data exists, but historical GIS is a very small niche. Still, I like the connected map service example, and would love to find the time to implement something like it and compare with a TMS.Re: Richardson and Ruby's RESTful Maps and Gazetteer
Author: Sean
Paul, while zoom levels are linked together, you're not absolutely required to start at the lowest resolution any more than you are required to start at the root of any website and traverse to its documents. Their RESTful maps can be bookmarked like any other hypermedia.