MBTiles - metadata - suggestion for OpenStreetMap support

[mj10777]

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

https://github.com/mapbox/mbtiles-spec/

'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]

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]

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
#35 (comment).

[tmcw]

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]

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