Locating TMS tile z/x/y where y>2^z

Question

I am using mapproxy to generate tiles using a WMS endpoint. My mapproxy.yaml file is:

services:
  tms:
    use_grid_names: true
    origin: 'nw'
    
layers:
  - name: italyparcels
    title: italyparcels
    sources: [ItalyCache]
    
caches:
  ItalyCache:
    grids: [webmercator]
    sources: [ItalyWMS]
    cache:
      type: file
      directory: cached_tms
      directory_layout: tms

sources:
  ItalyWMS:
    type: wms
    req:
      url: https://wms.cartografia.agenziaentrate.gov.it/inspire/wms/ows01.php?language=ita&
      layers: CP.CadastralParcel,strade,vestizioni,province,codice_plla,fabbricati,CP.CadastralZoning,acque,simbolo_graffa,copyright
    supported_srs: ['EPSG:25832']

grids:
  webmercator:
    base: GLOBAL_WEBMERCATOR

globals:

I start a local server using mapproxy-util serve-develop mapproxy.yaml. Then, I query for the tiles in a browser. To my surprise, http://localhost:8080/tms/1.0.0/italyparcels/webmercator/5/34/40.png returns a tile (with an outline of the Italian peninsula):

(Strangely, if I change tms/1.0.0 to tiles and 5/34/40 to 6/34/23 in the URL: http://localhost:8080/tiles/italyparcels/webmercator/6/34/23.png, I get the exact same tile - more details here.)

I found this surprising, as both 34 and 40 are larger than 2^5-1, ie these X and Y tile coordinates are outside the usual range of coordinates at zoom level 5.

Similarly, 280207 and 333564 are both larger than 2^18-1, but http://localhost:8080/tms/1.0.0/italyparcels/webmercator/18/280207/333564.png also returns a tile:

I am aware that the y-axis of TMS points northwards, unlike standard XYZ layers (source). Nevertheless, I haven't yet been able to come up with a transformation which takes the tile ID 5/34/40 and gives me a square in Italy.

The WMS is also accessible in QGIS, so once there is a transformation, we can see if it takes us roughly to the right place or not.

Knowing how to locate arbitrary tileIDs will hopefully also reveal why it is not an issue that in some cases the X and Y tile coordinates are larger than 2^z-1.

I compared 5/34/40 to the standard webmercator tile grid, and I found it isn't a standard slippy map tile. The most similar slippy map tile is 6/34/23, but it is not identical:

Question phased while keeping in mind the above-presented specifics: How to locate TMS tile 5/34/40?

Essentially the same question, phrased in a more general way: How to locate TMS tile z/x/y where y>2^z?

Answer 1

The default MapProxy tiling scheme for the /tms/1.0.0 path is different than what some others use. Here is an overview on MapProxy's tiling scheme (created using this repo of mine):

What is nowadays normally referred to as zoom level 1 (by slippy map/XYZ standard), is the z=0 level here when querying MapProxy's /tms/1.0.0/ service. More about tile naming conventions: here.

In this tiling scheme, it is not surprising if a tile's X or Y value is higher than 2ᶻ (where z is the TMS zoom level). They just need to be lower than 2ᶻ⁺¹-1. (Reassuringly, both 280207 and 333564 are smaller than 2^(18+1)-1.)

To locate http://localhost:8080/tms/1.0.0/italyparcels/webmercator/18/280207/333564.png, we need to translate TMS tileID 18/280207/333564 to XYZ (or slippy) tileID. After reading this, we can conclude that:

• Z_slippy = Z_tms +1 = 19
• X_slippy = X_tms = 280207
• Y_slippy = 2^(Z_tms+1)-1-Y_tms = 2^(18+1)-1-333564 = 190723

Let's verify: launch via mapproxy-util serve-develop mapproxy.yaml and query for http://localhost:8080/tiles/italyparcels/webmercator/19/280207/190723.png. We get the exact same tile:

as we got when querying for http://localhost:8080/tms/1.0.0/italyparcels/webmercator/18/280207/333564.png. Once we know that we are after XYZ tile 19/280207/190723, we can use zabop.github.io/tilecalc/3857 (I'm the author) to locate this tile:

It's here.

Similar calculation can be done for TMS tile 5/34/40. It's equivalent to XYZ tile 6/34/23. The outline of Italy does indeed differ from the expected outline. It is probably just a bug on the server side, and not a flaw in our calculations (you can see that the Italian shores "jump" as we are around zoom level 5-6, supporting the view that the WMS is probably a bit buggy at these low zoom levels).