MBTiles - metadata - suggestion for OpenStreetMap support

mj10777 commented 11 years ago

In the 'Roadmap' text it is suggesting that support for the OpenStreetMap naming convention is being considered.

'The format will switch tile ordering to the XYZ schema popularized by OpenStreetMap and away from the Tile Map Service specification.'

I would like to suggest the following:

add a 'metadata' name: name='tile_row_type'

with (at the moment) 2 possible values:

'tms' 'osm'

A reader could then check for 'tile_row_type':

if not found OR 'tms' -- assume 'Tile Map Service Specification' as described at http://wiki.osgeo.org/wiki/Tile_Map_Service_Specification
if 'osm' is found -- assume 'Slippy map tilenames' as described at http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames

I am the author of the Bash-Shell script tileinfo.sh

http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames#tileinfo.sh

this tool was developed as a helper to determine a tile address from a WSG84-position (for both tms and osm) or to determine a WSG84-position from a tile address (for both tms and osm).

Today I have added the functionality of creating a .mbtile database from an existing tile-directory

assuming that either sqlite3 or spatialite is installed
a parameter can be given to tell the script that the tile-directory is a tms directory

Here I have added the metadata name 'tile_row_type', setting the value always to 'tms' - since all readers (at the moment) assume this. I will be doing the same for a QT based map library that reads tile-directorys and show the result on a map.

There are also Android applications, that together with their format (similar, yet different) also can read the present mbtiles format.

OruxMaps is the Application that I use mostly on my telefon/tablet and this application can read the created .mbtiles -- including the metadata names bounds and center - when listed: shows the extent of 'bounds' and when opened zooms to the position given in 'center' -- unfortunately, at the moment at least, a empty 'android_metadata' table must exist for this to work I have had contact with this developer and would like to convince him to switch over to the .mbtiles format. At the moment his application can create and fill a sqlite.db from an selected area. The created database uses the fields (z,x,y,image) and stores a 'CalibrationPoint' in an external xml file, which is used as the (oms) position 0,0. I am planing to work on a conversion function for this and will be using a 'calibration_point' in the metadata to calculate the offset from the default value of: '-180,-85.0511,180,85.0511'

For this reason I would also suggest adding a name 'calibration_point'

the default being '-180,-85.0511,180,85.0511'.

Adding these 2 values for reading applications to use would, I believe, encourage a wider use of the .mbtiles format.

Mark Johnson, Berlin Germany

tmcw commented 10 years ago

While we'd love to go back and never use TMS for the silly historical reasons we did, it's important to remember that, as a rather heavily-adopted specification, breaking changes like supporting XYZ (which would break old readers with new files) would be tough to justify.

For this reason I would also suggest adding a name 'calibration_point' the default being '-180,-85.0511,180,85.0511'.

What would another value be, for example? I'm not clear on what the usefulness of this feature would be and how it's related to the tiling scheme.

mj10777 commented 10 years ago

2014-06-16 20:24 GMT+02:00 Tom MacWright notifications@github.com:

While we'd love to go back and never use TMS for the silly historical reasons we did, it's important to remember that, as a rather heavily-adopted specification, breaking changes like supporting XYZ (which would break old readers with new files) would be tough to justify.

For this reason I would also suggest adding a name 'calibration_point' the default being '-180,-85.0511,180,85.0511'.

What would another value be, for example? I'm not clear on what the usefulness of this feature would be and how it's related to the tiling scheme.

I agree to the why. but there are database created that use a 'calibration_point' and start at that point with tile 0,0 (OruxMaps) for one - for what ever reasons that I do not understand

this making it clear that this information should be included in the file

and not as others due in an extra file that may not be included

Otherwise the others (that I wrote in August 2013) ideas was mainly adding 'metadata' parameters

when missing the default - for older reader should be assumed could be added - mainly osm/google tile-notation (which if I remember correctly was consideres a possible TODO)

Mark Johnson, Berlin Germany

Reply to this email directly or view it on GitHub https://github.com/mapbox/mbtiles-spec/issues/35#issuecomment-46215256.

tmcw commented 10 years ago

I agree to the why. but there are database created that use a 'calibration_point' and start at that point with tile 0,0 (OruxMaps) for one - for what ever reasons that I do not understand

This sounds like a bug in software that implements MBTiles, that should be fixed in that software, not MBTiles.

tmcw commented 8 years ago

Closing; this behavior is documented and should be implemented as in the spec.

mapbox / mbtiles-spec

MBTiles - metadata - suggestion for OpenStreetMap support #35