Quadkey support

[geospatial-jeff]

Tile matrix sets have the notion of X/Y/Z coordinates so technically we can generate a quadkey. However not all tile matrix sets have 4 children per parent which breaks the parent/child hierarchy. A good example of this is Canadian NAD83 LCC.

This all being said, I do think there are many benefits to supporting quadkeys:

• serialization/deserialization of tiles
• server side caching (generating unique per-tile cache keys)
• fast parent/child lookups

I think this comes down to whether or not morecantile will support tile matrices which don't decimate by a factor of 4 (width or height is 2**zoom). From the README, docstrings, and general usage my thought is that it shouldn't, but that isn't entirely clear.

[blacha]

@geospatial-jeff (Not sure if this is the best place to post this)

This is something I'm quite interested in, we have been looking at how to make QuadKeys from the NZTM tiling scheme.

there are a few issues with NZTM when it comes to quadkeys,

• zoom 0 is a 2x4 grid
• zoom 8 to zoom 9 and zoom 13 to zoom 14 use a 2.5x increase rather than a 2x increase.

To work around these two issues we have had two thoughts

Create a new TileMatrixSet
since the bounding box and origin are know we could create another tile matrix set that starts with a 1x1 tile at the original z0 resolution and then increase, using a 2x factor for all zoom levels. This would make a nice quadkey for all zoom levels we would need, but then tiles will never really "align" to the original. We thought this would be just creating another TileMatrixSet and didnt want to have two NZTM TileMatrixSets

Create a offset based QuadKey mapping for NZTM,

Most of NZTM increases by 2x and is almost square, we can take z0 which is 2x4 and make it a virtual 4x4 grid, then we can zoom out and create a virtual z-1 (2x2) and z-2 (1x1) which would then perfectly map to quadkeys,

• QK '' => z:-2, x:0, y:0 (not a real tile)
• QK '0' => z-1, x:0, y:0 (not a real tile)
• QK '21' => z:0, x:1, y:2 (real tile!)

Then we have QuadKeys that could be "valid" or "invalid", the TileMatrixSet knows if they are valid or not,

This still leaves the problem of z8-z9 transition, the z8 -> z9 transition means that a z9 tile may have 4 z8 tiles as it's parent so any math that creates a covering of a tile >= z9 may need up to 4 parent tiles.

what this means in practice is we can use QuadKeys to easily reference anything between z0 and z8, then possibly have to use 4 quad keys for anything in >= z9.

We have currently gone with the second option (example source: https://github.com/linz/basemaps/blob/master/packages/geo/src/tms.quad.key.ts)

But we are open to better solutions!

[geospatial-jeff]

@blacha as you mention the 2.5x zoom fundamentally breaks the math behind quadtrees so I think the approach you have come up with is as good as you can get. Creating an offset quadkey is a clever way of handling the differing matrix dimensions.

[adrian-knauer]

I think we don't have to decide yet if we always want to support quadkeys. We could just implement a function that checks if a custom Tile Matrix Set supports quadkeys. If not we just raise an NoQuadkeySupport error. I would implement this function and then just copy over the two functions quadkey and quadkey_to_tile from mercantile and add them to the TileMatrixSet class. Is it ok if I create a PR for this?

[vincentsarago]

🙏 @adrian-knauer

[blacha]

Just to follow up on this, we ended up deciding that it was worth the effort to replace the old tile matrix set with one that is quad key compatible, the 2.5x scale jumps also caused issues with things like COG creation with GDAL (this is now fixed)

So now we have:

• NZTM2000 Deprecated
• NZTM2000Quad

[vincentsarago]

closed by #56