[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