[Tiling] How to Find Tiles

[Rushforth, Peter]

Chris,

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

Inevitably, by the time somebody like me knows something about a subject
like REST,
it is bound to have fallen from the peak of inflated expectations into
the trough of disillusionment.  But, if it's a web application, I doubt
that it's the REST part that has made the implementation worse.

> Generally speaking, when we describe tile resources, what we
> are now talking about is:
>
>  1. What are the available tilesets?

a) The set of available tilesets could be a collection resource.  This
could be described by an Atom feed with markup extensions for metadata
about that collection.    See atom file called "TileMatrixSet.atom"
here: http://pastebin.com/rsPVcVeK.  Although the markup applies to
WMTS, I think a TileMatrixSet corresponds to "available tilesets".  This
could also be done for TMS.


>  2. What is the metadata about each tileset? Most
> importantly, what is the
>     extents, and resolutions, of the tileset and its zoom levels?

b) In a) above, each entry could contain metadata about a tileset.  Each
entry could also provide an atom:link element pointing to a feed with
metadata about each and every tile.  See atom file called
"TileMatrixSet_6000m.atom" here: http://pastebin.com/aSbbEn5q.  This
feed contains exclusively media link entries,  supports HATEOAS: the
link at rel="east" (etc) would provide a way for a user agent to navigate
(paged) sub-feeds in the named direction of the same dimensions as the
current sub-feed (in units of tiles).



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

c) In both a) and b) above there is an atom:link at rel="search" link to an
OpenSearch document "opensearchdescription.xml" (below).  It contains
url templates to various media types, allowing the client to bypass the
metadata altogether and skip straight to the tile images.  This is
almost like HATEOS, but skips the intervening H ;-).  

<?xml version="1.0" encoding="UTF-8"?>
<OpenSearchDescription xmlns="http://a9.com/-/spec/opensearch/1.1/">
    <ShortName>Required by OpenSearch</ShortName>
    <Description>Required by OpenSearch</Description>
    
    <!-- the bbox parameter allows clients to filter the tiles in tile
matrix feeds by *intersecting* box -->
    <!-- if the results were used to navigate to media entries for
display, the client would still have  -->
    <!-- arrange the results and perform clipping itself, although there
might be some way to sort the   -->
    <!-- query results canonically such that they are arranged
left-to-right, top-to-bottom or in the    -->
    <!-- structure as the tile matrix itself in other words; there would
have to be some metadata telling -->
    <!-- how many rows and columns were present in the result
(?MatrixHeight, ?MatrixWidth) -->
    <!-- the response feed will contain media link entries only -->
    <!-- the response feed will be paged by the server using atompub
paging link relations (first, next, last) -->
    <!-- there is no need for an equivalent media entry -->
    
    <!-- the wmts:tilematrix @rel value identifies the search results as
representing a WMTS tile matrix -->
    <Url rel="wmts:tilematrix ogc:intersects results"
type="application/atom+xml;type=feed"
template="http://example.com/geomap/bmng/en/{wmts:ZoomLevel}?bbox={geo:b
ox?}"/>
    <!-- note: box intersection is a little different than the
OpenSearch-Geo extension, which specifies
        the semantic of results *within* the box.  Maybe this requires
an extension to the 
        OpenSearch-Geo extension, allowing more OGC Simple Features
operator semantics. --> 
    
    <!-- this template allows clients to access tile media link entries
individually.  Useful for metadata. -->
    <Url rel="wmts:tile" type="application/atom+xml;type=entry"
template="http://example.com/geomap/bmng/en/{wmts:ZoomLevel}/{wmts:TileR
ow}/{wmts:TileCol}"/>
    
    <!-- this template allows clients to by-pass the feeds and go
directly to the tile media entries -->
    <Url rel="wmts:tile" type="image/png"
template="http://example.com/geomap/bmng/en/{wmts:ZoomLevel}/{wmts:TileR
ow}/{wmts:TileCol}"/>
    
    <!-- featureinfo templates allows clients query the features at
row(J), col(I) of a particular tile image -->
    <Url rel="wmts:featureinfo results"
type="application/atom+xml;type=entry"
template="http://example.com/geomap/bmng/en/{wmts:ZoomLevel}/{wmts:TileR
ow}/{wmts:TileCol}/{wmts:J}/{wmts:I}"/>
    
    <!-- J,I are pixel row,col in a tile image -->
    <Url rel="wmts:featureinfo results" type="text/html"
template="http://example.com/geomap/bmng/en/{wmts:ZoomLevel}/{wmts:TileR
ow}/{wmts:TileCol}/{wmts:J}/{wmts:I}"/>
</OpenSearchDescription>

 

> 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}.pn
> g</OnlineResource>
>

WMTS supplies url templates for this purpose too.  But like that spec,
you're missing the opportunity to leverage broader standards such as
OpenSearch, and AtomPub.  


> 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/landsa
> t7"/></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).

IMHO "Context" is another word for "state", as in HATEO Application
State.   You are using WMC here as a way of describing the service.   I
think you want to provide a hint to the client on how to search and/or
directly access your collection of tile resources?  If so, use
OpenSearch.  

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

Maybe tools that create image pyramids could also generate the metadata,
or possibly only the metadata, where the links from the media link
entries point to a map image generating service.   

Cheers,

Peter