[Tilecache] Patch for WMTS in TileCache

Christopher Schmidt crschmidt at metacarta.com
Thu Sep 3 08:10:57 EDT 2009


On Thu, Jun 25, 2009 at 07:38:26PM +0930, Jim Groffen wrote:
> Hello,

Sorry this has taken so long. 

> Attached is a patch file that, if I made it correctly, will update TileCache revision 391 with the WMTS capabilities. I've added a guide (WMTSGuide.txt) and sample configuration file (wmts.cfg) to the docs folder that describes the new features.

Having briefly reviewed this patch, I have the following questions:

 * Currently, TileCache is designed to support accessing any tile set
   with any cache backend. Since all tiling schemes essentially work the
   same -- specifically, they all work on a fixed grid, with a set of
   scales and reslutions that allows a multilevel fixed grid, typically
   with the same corners at all levels of the grid -- it is easiest to
   transform this grid into a fixed set.

   It seems like the WMTS layer does not do this, and invents its own
   cache instead. 

   Is the cache set up by WMTS different enough that this is *really*
   neccesary?

 * It appears that WMTS has been developed as a 'Layer'. Layers are ways
   of accessing backend services -- so the MapServer layer accesses a
   MapServer service, the WMS layer accesses a WMS service, etc. WMTS
   does not appear to be this (since you're pointing at my WMS for your
   demo config). Instead, it appears that WMTS should be a *service*
   (TileCache/Services/ directory); the configuration parameters that
   you are using to define tilesets should potentially be added to *any*
   layer, and these configuration parameters are used to return metadata
   and tile requests whenever a request comes in in the WMTS service
   format.

   As it is now, presumably WMTS doesn't work with Mapnik, MapServer,
   GDAL, etc. backends. This ireally counter to the design of TileCache,
   and I'm sorry that was unclear. 

   Note that a WMTS layer -- that is, a layer class which requested
   tiles fro ma WMTS service -- is not out of the question, and could be
   implemented -- as could a TMS layer, for example, but I don't think
   that either of those is what has been built here.

   
 * top_left=-180,90
   Generally, this can simply be extracted from the bbox, though I see
   here that different levels can have different 'top left' expectations
   (hooray for setting up a standard that is completely different from
   everything else). I guess that this means that WMTS really isn't the
   same, though I still feel that it's probably better to not go bother
   writing another cache, and simply document that you can't use WMS and
   WMTS on the same cache. Porting each of the Layer and Cache classes
   to WMTS would mean duplicating tons of code.

> The implementation got a fair bit of testing in the OWS-6 testbed, but
> since then I've implemented support for MetaTiling, which only I've
> tested. A couple of things I came up with while merging with the
> latest revision and writing the documentation were:
> 
> 
> -          I avoided changes to existing TileCache files as much as
> possible. The goal was to keep the WMTS functionality contained to its
> Service, Layer and Disk module files as much as possible. When it
> comes to the changes to support reading TileMatrixSet configurations
> though I had a hard time separating this out from Service.py. I wasn't
> keen to subclass Service.py, but I don't like how much complexity has
> been added to the configuration reading. If anyone can suggest
> something that'd be great.

I really think that -- althogh your effort was admirable -- I feel like
a lot of this work was simply done in the wrong place/way. 

> 
> -          MetaTile was subclassed with WMTSTile so it could keep
> track of tile_matrix (used instead of resolution to go from tile
> co-ords to bounds). After implementing meta tiling for WMTS I think It
> may have been better to add tile_matrix to the Tile class instead, and
> WMTS specific code could look for it in the class if they wanted to
> use it.

Describe tile_matrix more, and I can probably comment on it. What is a
tile_matrix? What does it map to most closely in existing code?

> 
> -          top_left configuration setting - I don't like this name
> because it causes a bit of confusion. The setting wants a coordinate
> which is usually ordered left,top and not top,left. The top_left
> matches the wording as it comes out in the WMTS capabilities document,
> but perhaps this should be something like 'origin'? The problem with
> origin is it doesn't state what corner of the bounds is used as the
> origin. I don't like left_top either - it may be more accurate than
> top_left most of the time but it still implies a specific order and
> now doesn't match WMTS (which is TopLeftCorner), so after all that I'm
> not sure what it should be called. Maybe top_left_corner?

If the ordering is always 'x,y' (or lon,lat) and not some freaky changed 
thing with projections, then I'd preer to just call it left_top and be
done with it.

> 
> -          There is a pending change request that was popular to make
> style always be specified in the path. When this change occurs, If no
> style is set in configuration then a default style name should be set
> and used in the paths which won't affect the WMS getMap requests. This
> would be easy enough to do but isn't *quite* yet standard WMTS
> behavior . Should it get done now?

Not enough information to understand the question. 

Regards,
-- 
Christopher Schmidt
MetaCarta



More information about the Tilecache mailing list