Support custom tiling scheme

[jingsam]

As mvt driver of OGR using TILING_SCHEME=crs,tile_origin_upper_left_x,tile_origin_upper_left_y, tile_dimension_zoom_0 to support custom tiling scheme, I think mbtiles should not to be limited to web mercator.

I assume mbtiles will be a generic spatial data format in the near future. a generic spatial data format should not to be constrained to only one tiling scheme.

[jingsam]

@ericfischer Let's start here to make mbtiles more generic. As this will be a big step forward, I suggest a major version bump: mbtiles 2.0. However, the changes are backward compatibility, mbtiles defaults to web mercator, unless it is explicitly specify crs,tile_origin_upper_left_x,tile_origin_upper_left_y, tile_dimension_zoom_0 in metadata table.

There would a whole lot of toolchains should be revised to adopt 2.0, such as:
tilelive and tilelive modules
node-mbtiles
tippecanoe
GDAL
mapbox-studio
mapbox-gl
...

But that's OK, let's move forward step by step.

[ThomasG77]

Could be wrong but MBtiles spec writers does want to keep the spec limited to simple use cases (no projection or custom grid)
You should better look at Geopackage. It support tiles with custom matrix and projections http://www.geopackage.org/spec121/index.html#tiles

[e-n-f]

I think I would be in favor of adding variants of the center and bounds metadata that are denominated in terms of fractions of the unit square of the zoom level 0 tile, or of a multiple of its size, so that tiles themselves are the only coordinate system that mbtiles talks about.

I think it would be a mistake to add anything that requires reference to any other CRS, since that is external knowledge that a client may not have access to.

[jingsam]

I think I would be in favor of adding variants of the center and bounds metadata that are denominated in terms of fractions of the unit square of the zoom level 0 tile, or of a multiple of its size, so that tiles themselves are the only coordinate system that mbtiles talks about.

I am not getting the meaning of the center and bounds metadata. A little tip is that not all tiling shemes only have one tile at zoom level 0. For example, EPSG:4326 tiling scheme have 2 tiles at zoom 0. So which center and bounds of zoom level 0 should be record?

I think it would be a mistake to add anything that requires reference to any other CRS, since that is external knowledge that a client may not have access to.

A tiling scheme consists of two factors: CRS and grids. if clients don't know CRS, clients may have no idea that which bounds a z/x/y tile represent for.

I think it's the responsibility of clients to get CRS and grids information through TileJSON before overlay with other layers. If the client library get a different CRS and grids source and it does not have the ability of dynamic reprojection, the client should refuse to load the tile source.