[MapProxy] Issues with WMTS TileMatrix with leading zero resulting in different tiles in cache.

Oliver Tonnhofer olt at omniscale.de
Mon Jun 19 23:58:10 PDT 2017


Hi,

WMTS tile matrix identifiers are strings and not integers. MapProxy uses 00, 01, 02, etc. for 'numerical' identifiers. Both KVP and REST capabilities list <ows:Identifier>00</ows:Identifier>, <ows:Identifier>01</ows:Identifier>, etc.

So, all WMTS clients should request 06 instead of 6....


> When we seed the layers, the tiles are stored without the leading 0.

> ...
> We face this with CouchDB caches.


Ok, I see that the handling of the level directory (integer vs. string) is not handled identical for all cache backends

I've created a new issue for that: https://github.com/mapproxy/mapproxy/issues/315

Regards,
Oliver

-- 
Oliver Tonnhofer  | Omniscale GmbH & Co KG  | https://omniscale.com
OpenStreetMap WMS and tile services         | https://maps.omniscale.com





> On 22.05.2017, at 09:33, Bos, Cees <Cees.Bos at kadaster.nl> wrote:
> 
> Hi all,
> 
>  
> 
> We see double tiles in our cache due to ‘different’ TileMatrix values.
> 
>  
> 
> Example request
> 
> service?SERVI TILEMATRIX=06&TILEROW=32&TILECOL=31
> 
> This results in tiles with key EPSG%3A3857-06-31-32 and with metadata tile_level ‘06’.
> 
>  
> 
> This is not supported:
> 
> service?SERV TILEMATRIX=6&TILEROW=32&TILECOL=31
> 
> This gives an exception: The requested tile is outside the bounding box of the tile map.
> 
>  
> 
> While the same calls with WMTS Rest style
> 
> wmts/brtachtergrondkaart/EPSG:3857/6/31/32.png
> 
> This results in tiles with key EPSG%3A3857-6-31-32 and with metadata tile_level 6.
> 
>  
> 
> wmts/brtachtergrondkaart/EPSG:3857/06/31/32.png works fine and well and uses the same tiles with key EPSG%3A3857-6-31-32 and with metadata tile_level 6
> 
>  
> 
> When we seed the layers, the tiles are stored without the leading 0.
> 
> But these files are not used for the WMTS requests and new tiles are created, so the first type of WMTS requests don’t leverage the cache and create a new set of files for all available files.
> 
>  
> 
> We face this with CouchDB caches.
> 
>  
> 
> Is this as expected? Or is this a bug in the WMTS requests?
> 
>  
> 
> With kind regards,
> Cees
> 
> 
> 
> Disclaimer:
> De inhoud van dit bericht is uitsluitend bestemd voor geadresseerde.
> Gebruik van de inhoud van dit bericht door anderen zonder toestemming van het Kadaster
> is onrechtmatig. Mocht dit bericht ten onrechte bij u terecht komen, dan verzoeken wij u
> dit direct te melden aan de verzender en het bericht te vernietigen.
> Aan de inhoud van dit bericht kunnen geen rechten worden ontleend.
> 
> Disclaimer:
> The content of this message is meant to be received by the addressee only.
> Use of the content of this message by anyone other than the addressee without the consent
> of the Kadaster is unlawful. If you have received this message, but are not the addressee,
> please contact the sender immediately and destroy the message.
> No rights can be derived from the content of this message.
> _______________________________________________
> MapProxy mailing list
> MapProxy at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mapproxy



More information about the MapProxy mailing list