[Tiling] How to Find Tiles

christopher.schmidt at nokia.com christopher.schmidt at nokia.com
Mon Sep 13 17:42:07 EDT 2010


Okay, so here's a thought that I've had off and on for a long while now.

We used to talk about TMS as RESTful, and have all this intermediate document
stuff that is kind of silly, since most people don't use it, and it makes some
forms of implementation worse.

In fact, one of the big things that the OGC WMTS vs. TMS comparison at FOSS4G
talked about was the fact that for TMS, you have to load multiple XML documents
to actually find out about the layers.

I feel pretty strongly now that the TMS spec was always somewhat incomplete; 
I'll note that although TMS came out of the tiling discussion, it was not 
something we spent any time on together back at FOSS4G in 2006, and was instead 
done shortly thereafter. (WMS-C is something we discussed in detail; TMS came 
out of people wanting something that didn't have question-marks in the URLs.)

Generally speaking, when we describe tile resources, what we are now talking
about is:

 1. What are the available tilesets?
 2. What is the metadata about each tileset? Most importantly, what is the 
    extents, and resolutions, of the tileset and its zoom levels?
 3. What is the URL I use to get tile at z=12, x=7, y=73 ?

Essentially, the way this gets implemented in clients is that they take a 
TMS base and slap $z/$x/$y.png to the end of it.

In reality, I'm sort of wondering whether what we really want for TMS
(or something like it) is something closer to a WMC document crossed with
an OpenSearch document. Imagine that you could create a WMC, but one that
had in its OnlineResource support for well-defined replacement operators.

So, an OnlineResource might look like:

  <OnlineResource>http://example.com/tms/2.0.0/${z}/${x}/${y}.png</OnlineResource>

A simple WMC looks something like this:

<ViewContext xmlns="http://www.opengis.net/context" version="1.1.0" id="OpenLayers_Context_235" xsi:schemaLocation="http://www.opengis.net/context http://schemas.opengis.net/context/1.1.0/context.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ol="http://openlayers.org/context">
<LayerList>
  <Layer queryable="0" hidden="0">
  <Server service="OGC:WMS" version="1.1.1"><OnlineResource xlink:type="simple" xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://t1.hypercube.telascience.org/cgi-bin/landsat7"/></Server>
  <Name>landsat7</Name>
  <Title>NASA Global Mosaic</Title>
  <Extension>
    <ol:maxExtent minx="-129.999999999999980" miny="14.0000000000000000" maxx="-60.0000000000000000" maxy="55.0000000000000000"/>
    <ol:tileSize width="256" height="256"/>
    <ol:numZoomLevels>4</ol:numZoomLevels>
    <ol:units>degrees</ol:units>
  </Extension>
  </Layer>
</LayerList>
</ViewContext>

(Note that the fact that apparently WMC doesn't have parameters for 
any of these things is probably evidence that WMC itself is not the right spec.)

So, if you imagine changing this to: 

<ViewContext xmlns="http://www.opengis.net/context" version="1.1.0" id="OpenLayers_Context_235" xsi:schemaLocation="http://www.opengis.net/context http://schemas.opengis.net/context/1.1.0/context.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ol="http://openlayers.org/context" xmlns:xlink="http://www.w3.org/1999/xlink">
<LayerList>
  <Layer>
  <Server service="OGC:TMS" version="1.1.1">
    <OnlineResource xlink:type="simple" xlink:href="http://example.com/landsat7/2.0.0/${z}/${x}/${y}.png"/>
  </Server>
  <Name>landsat7</Name>
  <Title>NASA Global Mosaic</Title>
  <Extension>
    <ol:maxExtent minx="-130.0" miny="14.0" maxx="-60.0" maxy="55.0"/>
    <ol:maxResolution res="1.40625" />
    <ol:tileSize width="256" height="256"/>
    <ol:numZoomLevels>4</ol:numZoomLevels>
    <ol:units>degrees</ol:units>
  </Extension>
  </Layer>
</LayerList>
</ViewContext>

you can see that this is a description of all the things that one would 
need to load a tileset (I think). 

Now, obviously this has some upsides and downsides, but as a tile discovery
mechanism, I like this a lot better than I like the existing metadata for
TMS, with its long lists of zoom levels.

Does this make some sense? This isn't a finalized thought in any way, this
is just a first attempt at trying to toss together something I've been
bouncing around in my head for a while.

If we can create a simple spec that's aligned with OpenSearch or WMC, I think
that we might have more traction for uptake, and make client implementation
simpler to boot. 

If we really wanted to go whole-hog, we could even go so far as to define
multiple replacement styles to mimic some of the things that we've seen 
which aren't just z/x/y -- like quadtile indexes, or TileCache's funky
17/05/24.png addressing.

I'm also happy to skip the whole WMC/XML alignment and just create something
simple in JSON, or create an XML and define a standard mapping to JSON, or
none of the above is this seems like a stupid idea.

My opinion is that currently, TMS metadata is too complex for people to want
to create it by hand, so many valuable providers -- like OSM -- simply don't
provide it at all. I think the community would be well-served by creating a
simple-to-copy-paste format for metadata about tile resources which are 
addressable by x/y/z, and I'd like to discuss it here, where we have both 
server and client implementors available to discuss.

Thoughts?

-- Chris



More information about the Tiling mailing list