[Tiling] How to Find Tiles

[Arne Kepp]

  I'm a bit unsure what the intended scope of this discussion is. Is it 
limited to reducing the number of XML documents, or is it appropriate to 
bring up points that would make the open source tiling solutions (and 
others) more useful to "big users"?

$z should not be assumed to be an integer. If you have big sets of 
tiles, it may take months to build up the cache for 1:250. But you don't 
want to restart that just because you need a new intermediate step (say 
1:55000) to support a legacy application.

One should not have to redefine the entire set just because it is 
available in more than one format. {format} ?

Ideally, the same thing for other dimensions, such as styling or a time 
parameter. But I realize that's a big can of worms.

There should be a vehicle for extending the spec with *optional* 
profiles. For example, I think GML (Multipolygon) could be a useful way 
to describe data extent, e.g. for a country like Norway where something 
like 4/5 of the tiles within the bounds would be water or Sweden. The 
IETF uses separate RFCs for such, I think in our case it would mean 
subsections in separate wiki pages, as opposed to having the vendors try 
to align such vendor extensions in private or on mailinglists that are 
poorly covered by search engines.

I do think the distinction between data and grid extent is important, 
alternatively that you have some other way of growing with the data, 
like specifying an origin. De facto standard grid sets (worldwide, 
national, local) would make life much simpler for web developers who do 
not work with geospatial stuff on a daily basis. At least my impression 
is that whoever provides the best background map for a region sets that 
standard.

I agree that the way TileCache organizes the directory structure works 
well on a lot of filesystems. You could mandate that as something the 
clients must know how to deal with, alternatively support simple math 
and bit shift operations to be specified in the template. Like {x >> 2} 
, it does get ugly very quickly.

Quadtile indexes and most such schemes become a real pain if the 
resolutions are not a geometric series.

-Arne


On 9/13/10 11:42 PM, christopher.schmidt at nokia.com wrote:
> 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