According to the v2.1 specification for mvt, arbitrary projects and tile extents are possible, although to date none of the widely used libraries implement any other projections than epsg 4326/3857 with google tiling scheme. It seems that the gdal driver for MVT already support this although it would be good to have it here too as I think tippecanoe is still the preferred way to make mvt/pmtiles in general.
The OGC TileMatrixSet (TMS) specification (https://docs.ogc.org/is/17-083r4/17-083r4.html) makes it possible to easily encode tiling schemes with projection information, so if tippecanoe was updated to accept a TileMatrixSet instead of just a projection, it would be possible to have much more flexibility in creating pmtiles.
By default, the WebMercatorQuad TMS would be used for epsg:3857 and shouldn't break a thing, as the tile indexes map 1:1.
For 4326 WorldCRS84Quad would be used (although there are two variants, one that uses OGC:CRS84 and the other that uses EPSG:4326, so some work to handle the axis order may be needed).
The motivation behind this idea, is that there are other CRS authorities than the EPSG, and in particular the IAU that defines coordinate systems for planetary bodies (Moon, Mars, Europa, etc) with the OGC and I am working on TMS specs for all of these bodies that I hope to eventually get registered and discoverable. Now I would say for the majority of users, the current defaults work just fine and realize this goal already, but other less resourced groups (such as the planetary science community) would have to do a bunch of hacks/intermediate steps to using mvt/pmtiles.
TMSs are used in other OGC standards and it is possible to make COGs that use TMSs to define their internal tiling (see TILING_SCHEME creation option). If the same tiling scheme is used across raster and vector cloud optimized formats (pmtiles) then a lot of possibilities are opened up for more users trying to use these data together.
As a reasonable first pass only supporting TMSs that are true quad tree structures and are not 2:1/1:2 aspect ratio is probably sufficient. Coalesced grids like the GNOSISGlobalGrid may be a little complicated to handle, but also may not be as efficient for high latitudes when dealing with vector data, but I haven't fully thought this through. Otherwise most of the changes I think would be isolated to projection.cpp to load the constants from the CRS used and to update the totile and tileto functions to load cached constants. Maybe some additional work is needed to support more kinds of TMSs and so existing implementations from GDAL/morecantile can be used for implementation reference.
The only blocker I maybe see is the mbtiles spec, but from the mvt spec it sounds like this would all be allowable, but I am not sure exactly what the hierarchy for these specs mvt/mbt/pmt is. presumably pmt is downstream though.
If this idea needs to be discussed elsewhere let me know.
According to the v2.1 specification for mvt, arbitrary projects and tile extents are possible, although to date none of the widely used libraries implement any other projections than epsg 4326/3857 with google tiling scheme. It seems that the gdal driver for MVT already support this although it would be good to have it here too as I think tippecanoe is still the preferred way to make mvt/pmtiles in general.
The OGC TileMatrixSet (TMS) specification (https://docs.ogc.org/is/17-083r4/17-083r4.html) makes it possible to easily encode tiling schemes with projection information, so if tippecanoe was updated to accept a TileMatrixSet instead of just a projection, it would be possible to have much more flexibility in creating pmtiles.
By default, the WebMercatorQuad TMS would be used for epsg:3857 and shouldn't break a thing, as the tile indexes map 1:1.
For 4326 WorldCRS84Quad would be used (although there are two variants, one that uses OGC:CRS84 and the other that uses EPSG:4326, so some work to handle the axis order may be needed).
The motivation behind this idea, is that there are other CRS authorities than the EPSG, and in particular the IAU that defines coordinate systems for planetary bodies (Moon, Mars, Europa, etc) with the OGC and I am working on TMS specs for all of these bodies that I hope to eventually get registered and discoverable. Now I would say for the majority of users, the current defaults work just fine and realize this goal already, but other less resourced groups (such as the planetary science community) would have to do a bunch of hacks/intermediate steps to using mvt/pmtiles.
TMSs are used in other OGC standards and it is possible to make COGs that use TMSs to define their internal tiling (see TILING_SCHEME creation option). If the same tiling scheme is used across raster and vector cloud optimized formats (pmtiles) then a lot of possibilities are opened up for more users trying to use these data together.
As a reasonable first pass only supporting TMSs that are true quad tree structures and are not 2:1/1:2 aspect ratio is probably sufficient. Coalesced grids like the GNOSISGlobalGrid may be a little complicated to handle, but also may not be as efficient for high latitudes when dealing with vector data, but I haven't fully thought this through. Otherwise most of the changes I think would be isolated to projection.cpp to load the constants from the CRS used and to update the
totileandtiletofunctions to load cached constants. Maybe some additional work is needed to support more kinds of TMSs and so existing implementations from GDAL/morecantile can be used for implementation reference.The only blocker I maybe see is the mbtiles spec, but from the mvt spec it sounds like this would all be allowable, but I am not sure exactly what the hierarchy for these specs mvt/mbt/pmt is. presumably pmt is downstream though.
If this idea needs to be discussed elsewhere let me know.
relevant projects: https://github.com/developmentseed/morecantile https://github.com/developmentseed/timvt
https://gdal.org/en/latest/drivers/vector/mvt.html
relevant old issues from the mapbox repo: https://github.com/mapbox/tippecanoe/issues/770
possibly blocking issues: https://github.com/mapbox/mbtiles-spec/issues/60