search

mapbox / mbtiles-spec

specification documents for the MBTiles tileset format
https://www.mapbox.com/help/an-open-platform/#mbtiles
Other
612 stars 99 forks source link

Support custom tiling scheme #60

Open jingsam opened 5 years ago

jingsam commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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.