Giters

mapbox / mbtiles-spec

specification documents for the MBTiles tileset format

Home Page:https://www.mapbox.com/help/an-open-platform/#mbtiles

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

MBTiles - metadata - suggestion for OpenStreetMap support

mj10777 opened this issue · comments

commented

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

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

commented

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.

commented

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).

commented

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.

commented

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