[Tiling] How to Find Tiles

[Matt Priour]

I really like the idea of using the simplest possible metadata file that 
sufficiently describes the data source. Making a small modification to the 
already well-known OWS WMC file as you have proposed sounds good. I think 
other good possibilities are AtomPub / GeoRSS, or a self-explanatory JSON 
file.

One addition I would like to see are optional tile scheme origin  and tile 
scheme max resolution elements. The valid data extent and the tile spec 
extent are not always the same. For example one could use the Google Maps 
tiling scheme but only have produced tiles for the Greater New Orleans area. 
In such a case, it would be inappropriate for the published tile set to 
advertise its extent and resolution as the global parameters of the tiling 
scheme but if it only advertised its actual resolution & extent then it 
would impossible for a client to actually construct a valid URL.

Matt Priour

--------------------------------------------------
From: <christopher.schmidt at nokia.com>
Sent: Monday, September 13, 2010 4:42 PM
To: <tiling at lists.osgeo.org>
Subject: [Tiling] How to Find Tiles

> 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
>
> _______________________________________________
> Tiling mailing list
> Tiling at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/tiling
>