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