[Tiling] How to Find Tiles

Mon Sep 13 18:45:54 EDT 2010

On Sep 13, 2010, at 6:43 PM, ext Matt Priour wrote:

> 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.

Yeah, we can probably also look at ESRI for things like that, since they have 
a similar idea -- grid extent vs. data extent. (Though actually, I think they
just use grid origin, a single point, rather than an extent.)

-- Chris

> 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
>> 