New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2.0 spec #46

Open
wants to merge 18 commits into
base: master
from

Conversation

Projects
None yet
7 participants
@pnorman

pnorman commented Sep 7, 2016

Fixes #43
Fixes #44
Fixes #31
Fixes #28
Closes #47 (imo)

This is a draft of a 2.0 spec which addresses tile formats and compression.

Unaddressed are spec versioning (#3), tileset versioning (#31), and tileset type (#28) since no decision was made on if those changes should be accepted or not.

For a diff of 1.2 to 2.0, see 14942c6...pnorman:2.0

CC @hallahan @blair1618 @systemed

pnorman added some commits Sep 6, 2016

Add compression metadata
This allows compression to be applied on top of tile data, which
is an advantage for some tile types.

@hallahan hallahan referenced this pull request Sep 8, 2016

Closed

Core MBTiles Support #960

@hallahan

This comment has been minimized.

Show comment
Hide comment
@hallahan

hallahan Sep 8, 2016

I like that you included o5m. Other formats that I would like to use are OSM XML and OSM PBF. How would we declare those? Perhaps we should allow any data format for the contents of a tile and have a good way of describing what it is?

hallahan commented Sep 8, 2016

I like that you included o5m. Other formats that I would like to use are OSM XML and OSM PBF. How would we declare those? Perhaps we should allow any data format for the contents of a tile and have a good way of describing what it is?

@tmcw

This comment has been minimized.

Show comment
Hide comment
@tmcw

tmcw Sep 8, 2016

Contributor

Some comments:

  • Since MBTiles is a container format, it's certainly chill to store whatever in it. But also since it's a container format, having MBTiles filled with more exotic formats will inevitably reduce the expectation of "this will work" from MBTiles consumers. If the spec starts pushing for more formats of vector data sources, I think it should also explicitly acknowledge that it does not require implementors to include support for all formats, and potentially should make clear what implementors should do when an unknown format is encountered.
  • Listing explicit formats seems like a slope to shoutouts to everyone. Could we say, instead, that if a format is a mime-type, then it is treated as that type?
Contributor

tmcw commented Sep 8, 2016

Some comments:

  • Since MBTiles is a container format, it's certainly chill to store whatever in it. But also since it's a container format, having MBTiles filled with more exotic formats will inevitably reduce the expectation of "this will work" from MBTiles consumers. If the spec starts pushing for more formats of vector data sources, I think it should also explicitly acknowledge that it does not require implementors to include support for all formats, and potentially should make clear what implementors should do when an unknown format is encountered.
  • Listing explicit formats seems like a slope to shoutouts to everyone. Could we say, instead, that if a format is a mime-type, then it is treated as that type?
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 8, 2016

Listing explicit formats seems like a slope to shoutouts to everyone. Could we say, instead, that if a format is a mime-type, then it is treated as that type?

I was trying to preserve compatibility with jpg and png so a valid mbtiles 1.2 is a valid 2.0. If breaking backwards compatibility is an option, I'd go with MIME type.

Since MBTiles is a container format, it's certainly chill to store whatever in it. But also since it's a container format, having MBTiles filled with more exotic formats will inevitably reduce the expectation of "this will work" from MBTiles consumers.

2.0 makes it clear that it is a container format that can store any tiled data, which is not possible on 1.x. Does this require modifications to the prose or README.md?

If the spec starts pushing for more formats of vector data sources,

Well, support for any vector data sources.

I think it should also explicitly acknowledge that it does not require implementors to include support for all formats, and potentially should make clear what implementors should do when an unknown format is encountered.

Right now the spec places no requirements on implementations, just on the mbtiles files. I see the role of mbtiles here similar to that of .tar - it defines a way to store content/files, and it's up to something else to make use of that content.

I agree that right now any implementation is likely to have the same support for png and jpg and the situation will change with arbitrary types, so I'll try to come up with appropriate wording that makes it clear there's no requirement on what readers do with the contained tile data. fwiw, this is theoretically possible in 1.2 if you had a reader that supported jpeg but not png.

pnorman commented Sep 8, 2016

Listing explicit formats seems like a slope to shoutouts to everyone. Could we say, instead, that if a format is a mime-type, then it is treated as that type?

I was trying to preserve compatibility with jpg and png so a valid mbtiles 1.2 is a valid 2.0. If breaking backwards compatibility is an option, I'd go with MIME type.

Since MBTiles is a container format, it's certainly chill to store whatever in it. But also since it's a container format, having MBTiles filled with more exotic formats will inevitably reduce the expectation of "this will work" from MBTiles consumers.

2.0 makes it clear that it is a container format that can store any tiled data, which is not possible on 1.x. Does this require modifications to the prose or README.md?

If the spec starts pushing for more formats of vector data sources,

Well, support for any vector data sources.

I think it should also explicitly acknowledge that it does not require implementors to include support for all formats, and potentially should make clear what implementors should do when an unknown format is encountered.

Right now the spec places no requirements on implementations, just on the mbtiles files. I see the role of mbtiles here similar to that of .tar - it defines a way to store content/files, and it's up to something else to make use of that content.

I agree that right now any implementation is likely to have the same support for png and jpg and the situation will change with arbitrary types, so I'll try to come up with appropriate wording that makes it clear there's no requirement on what readers do with the contained tile data. fwiw, this is theoretically possible in 1.2 if you had a reader that supported jpeg but not png.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 8, 2016

Perhaps we should allow any data format for the contents of a tile and have a good way of describing what it is?

Any data format is allowed, it's just a question of describing it.

pnorman commented Sep 8, 2016

Perhaps we should allow any data format for the contents of a tile and have a good way of describing what it is?

Any data format is allowed, it's just a question of describing it.

@hallahan

This comment has been minimized.

Show comment
Hide comment
@hallahan

hallahan Sep 9, 2016

One thing to make note of is that the MIME type of MVT is application/vnd.mapbox-vector-tile. Looking at how VND MIME types work, can we basically put whatever we want in there? I've seen vnd.android.cursor.dir where android would be the IANA recognized vendor name. Having the vendor name isn't required though...

I'd say we really do not want to break backwards compatibility with the 1.x specs. Part of the motivation to continue using MBTiles is that it has been a well known format for 5+ years.

hallahan commented Sep 9, 2016

One thing to make note of is that the MIME type of MVT is application/vnd.mapbox-vector-tile. Looking at how VND MIME types work, can we basically put whatever we want in there? I've seen vnd.android.cursor.dir where android would be the IANA recognized vendor name. Having the vendor name isn't required though...

I'd say we really do not want to break backwards compatibility with the 1.x specs. Part of the motivation to continue using MBTiles is that it has been a well known format for 5+ years.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 9, 2016

Looking at how VND MIME types work, can we basically put whatever we want in there?

You register MIME types, but it's easy. See mapbox/vector-tile-spec#48 for background. I'm talking to some people about doing this for OSM types.

I'd say we really do not want to break backwards compatibility with the 1.x specs. Part of the motivation to continue using MBTiles is that it has been a well known format for 5+ years.

Is there much software which relies on png/jpg to know what to do with tile data?

pnorman commented Sep 9, 2016

Looking at how VND MIME types work, can we basically put whatever we want in there?

You register MIME types, but it's easy. See mapbox/vector-tile-spec#48 for background. I'm talking to some people about doing this for OSM types.

I'd say we really do not want to break backwards compatibility with the 1.x specs. Part of the motivation to continue using MBTiles is that it has been a well known format for 5+ years.

Is there much software which relies on png/jpg to know what to do with tile data?

@hallahan

This comment has been minimized.

Show comment
Hide comment
@hallahan

hallahan Sep 9, 2016

Looking at Mapbox Android SDK Legacy (DEPRECATED), it looks like the MBTiles support doesn't look at format at all. It simply assumes that it is PNG, since it uses Android's BitmapFactory to decode an InputStream. BitmapFactory won't handle JPEG decoding.

https://github.com/AmericanRedCross/OpenMapKitAndroid/blob/5df03841475b805141c9b8441512653cbd8672c9/MapboxAndroidSDK/src/main/java/com/mapbox/mapboxsdk/tileprovider/tilesource/MBTilesLayer.java#L199

https://github.com/AmericanRedCross/OpenMapKitAndroid/blob/5df03841475b805141c9b8441512653cbd8672c9/MapboxAndroidSDK/src/main/java/com/mapbox/mapboxsdk/tileprovider/MapTileCache.java#L102

Looking at WhirlyGlobe-Maply (Android), it looks like it does the same thing.

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTiles.java#L249

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTilesImageSource.java#L68

However, WhirlyGlobe does check to see if it is jpg or png, so that suggests that jpg support may come in the future.

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTiles.java#L188

However, that is referencing the Android implementation. The iOS implementation can handle either, because under the hood, it uses UIImage which figures out the format from they blob for you.

https://github.com/mousebird/WhirlyGlobe/blob/8e7b1693d95c32be643f55aff4d41bf4bc296753/WhirlyGlobeSrc/WhirlyGlobeLib/src/LoadedTile.mm#L91

Another good one would be Nutiteq, though I don't have access to the source. For the Android, my best guess would be that they do the same thing and only support PNG.

Phew! So, I think the answer would be: no. The implementation either assumes it's PNG or discerns if it is PNG or JPG from the data itself.

hallahan commented Sep 9, 2016

Looking at Mapbox Android SDK Legacy (DEPRECATED), it looks like the MBTiles support doesn't look at format at all. It simply assumes that it is PNG, since it uses Android's BitmapFactory to decode an InputStream. BitmapFactory won't handle JPEG decoding.

https://github.com/AmericanRedCross/OpenMapKitAndroid/blob/5df03841475b805141c9b8441512653cbd8672c9/MapboxAndroidSDK/src/main/java/com/mapbox/mapboxsdk/tileprovider/tilesource/MBTilesLayer.java#L199

https://github.com/AmericanRedCross/OpenMapKitAndroid/blob/5df03841475b805141c9b8441512653cbd8672c9/MapboxAndroidSDK/src/main/java/com/mapbox/mapboxsdk/tileprovider/MapTileCache.java#L102

Looking at WhirlyGlobe-Maply (Android), it looks like it does the same thing.

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTiles.java#L249

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTilesImageSource.java#L68

However, WhirlyGlobe does check to see if it is jpg or png, so that suggests that jpg support may come in the future.

https://github.com/mousebird/WhirlyGlobe/blob/develop_3_0/WhirlyGlobeSrc/Android/src/com/mousebird/maply/MBTiles.java#L188

However, that is referencing the Android implementation. The iOS implementation can handle either, because under the hood, it uses UIImage which figures out the format from they blob for you.

https://github.com/mousebird/WhirlyGlobe/blob/8e7b1693d95c32be643f55aff4d41bf4bc296753/WhirlyGlobeSrc/WhirlyGlobeLib/src/LoadedTile.mm#L91

Another good one would be Nutiteq, though I don't have access to the source. For the Android, my best guess would be that they do the same thing and only support PNG.

Phew! So, I think the answer would be: no. The implementation either assumes it's PNG or discerns if it is PNG or JPG from the data itself.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 9, 2016

Phew! So, I think the answer would be: no. The implementation either assumes it's PNG or discerns if it is PNG or JPG from the data itself.

That means that we can break backwards compatibility but there is a subset of 2.0 tilesets which will work the same on most 1.2 readers.

I'm surprised by the lack of JPEG support, are there not many JPEG tilesets in the wild?

pnorman commented Sep 9, 2016

Phew! So, I think the answer would be: no. The implementation either assumes it's PNG or discerns if it is PNG or JPG from the data itself.

That means that we can break backwards compatibility but there is a subset of 2.0 tilesets which will work the same on most 1.2 readers.

I'm surprised by the lack of JPEG support, are there not many JPEG tilesets in the wild?

@hallahan

This comment has been minimized.

Show comment
Hide comment
@hallahan

hallahan Sep 9, 2016

From my experience, it's always been PNG unless MapQuest made it. I think Mapbox does JPG too, but people usually use the PNG endpoints?

hallahan commented Sep 9, 2016

From my experience, it's always been PNG unless MapQuest made it. I think Mapbox does JPG too, but people usually use the PNG endpoints?

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 9, 2016

From my experience, it's always been PNG unless MapQuest made it. I think Mapbox does JPG too, but people usually use the PNG endpoints?

The main reason for this is that PNG is a better format for maps unless you have hillshading, imagery, or some other raster data.

I'll edit to use MIME type if we think this is acceptable. For OSM MIME types, I'm going to be starting a discussion on registering them - some details still need working out.

pnorman commented Sep 9, 2016

From my experience, it's always been PNG unless MapQuest made it. I think Mapbox does JPG too, but people usually use the PNG endpoints?

The main reason for this is that PNG is a better format for maps unless you have hillshading, imagery, or some other raster data.

I'll edit to use MIME type if we think this is acceptable. For OSM MIME types, I'm going to be starting a discussion on registering them - some details still need working out.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 14, 2016

The roadmap has "The format will switch tile ordering to the XYZ schema popularized by OpenStreetMap and away from the Tile Map Service specification." Do we want to do this in 2.0, put it off to a later version, or drop it from the roadmap?

pnorman commented Sep 14, 2016

The roadmap has "The format will switch tile ordering to the XYZ schema popularized by OpenStreetMap and away from the Tile Map Service specification." Do we want to do this in 2.0, put it off to a later version, or drop it from the roadmap?

pnorman added some commits Sep 14, 2016

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 14, 2016

The roadmap has "The format will switch tile ordering to the XYZ schema popularized by OpenStreetMap and away from the Tile Map Service specification." Do we want to do this in 2.0, put it off to a later version, or drop it from the roadmap?

fwiw, I'm in favour of dropping it. The conversion between the two is technically trivial and I think the pain from breaking compatibility in this way is worse than any potential gains.

pnorman commented Sep 14, 2016

The roadmap has "The format will switch tile ordering to the XYZ schema popularized by OpenStreetMap and away from the Tile Map Service specification." Do we want to do this in 2.0, put it off to a later version, or drop it from the roadmap?

fwiw, I'm in favour of dropping it. The conversion between the two is technically trivial and I think the pain from breaking compatibility in this way is worse than any potential gains.

pnorman added some commits Sep 14, 2016

@hallahan

This comment has been minimized.

Show comment
Hide comment
@hallahan

hallahan Sep 14, 2016

👍 . Support for Google TMS would just make things more confusing. Perhaps give this hint in the spec:

y = (1 << z) - 1 - y;

hallahan commented Sep 14, 2016

👍 . Support for Google TMS would just make things more confusing. Perhaps give this hint in the spec:

y = (1 << z) - 1 - y;
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Sep 15, 2016

Couple of changes following some gitter discussion and the discussion here

  • Keep format as REQUIRED.
  • Require all data in a mbtiles to have the same compression, even if compression is not specified. A tileset of mixed formats or compressions would require detecting information from magic numbers of tile data, which we want to avoid.
  • Use MIME type
  • Adjust prose in the readme that mbtiles is a container format

Remaining issues

  • Is more prose explaining the implications of mbtiles being a container format and a specific mbtiles might not be useful to a specific piece of software needed?
  • The spec guarantees interoperability in reading mbtiles, but with views there is no guarantee that two tilesets will be written the same way, or that an implementation can add tiles to a tileset. Should this be made explicit?
  • Review that "tileset" is being used everywhere that mbtiles files are mentioned

pnorman commented Sep 15, 2016

Couple of changes following some gitter discussion and the discussion here

  • Keep format as REQUIRED.
  • Require all data in a mbtiles to have the same compression, even if compression is not specified. A tileset of mixed formats or compressions would require detecting information from magic numbers of tile data, which we want to avoid.
  • Use MIME type
  • Adjust prose in the readme that mbtiles is a container format

Remaining issues

  • Is more prose explaining the implications of mbtiles being a container format and a specific mbtiles might not be useful to a specific piece of software needed?
  • The spec guarantees interoperability in reading mbtiles, but with views there is no guarantee that two tilesets will be written the same way, or that an implementation can add tiles to a tileset. Should this be made explicit?
  • Review that "tileset" is being used everywhere that mbtiles files are mentioned
@ericfischer

This comment has been minimized.

Show comment
Hide comment
@ericfischer

ericfischer Oct 6, 2016

Contributor

BTW, I had failed to see this PR and just made my own attempt (#47) to document the current de facto standard for mbtiles, which I should now attempt to reconcile with these changes.

Contributor

ericfischer commented Oct 6, 2016

BTW, I had failed to see this PR and just made my own attempt (#47) to document the current de facto standard for mbtiles, which I should now attempt to reconcile with these changes.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Oct 7, 2016

I think the only changes left are informative ones to the prose of the text to make some aspects clearer. Does anyone see anything else?

pnorman commented Oct 7, 2016

I think the only changes left are informative ones to the prose of the text to make some aspects clearer. Does anyone see anything else?

@ericfischer

This comment has been minimized.

Show comment
Hide comment
@ericfischer

ericfischer Oct 7, 2016

Contributor

@pnorman I know I am very late to this, but I would suggest (based on what I did in #47):

  • Recommend creating an index for metadata
  • Recommend creating an index for tiles
  • Document existing png, jpg, mvt, and pbf as aliases for MIME types in format
  • Add recommended center, minzoom, and maxzoom to metadata
  • Document what version and type are for. (As far as I know nothing actually cares, so maybe they should be removed instead.)
  • Document json field, which is required for Mapbox Vector Tiles
  • Include the formula for converting between TMS Y axis and tile URL Y axis
  • Maybe make all the metadata except name, format, and json optional, since existing implementations will infer the rest
Contributor

ericfischer commented Oct 7, 2016

@pnorman I know I am very late to this, but I would suggest (based on what I did in #47):

  • Recommend creating an index for metadata
  • Recommend creating an index for tiles
  • Document existing png, jpg, mvt, and pbf as aliases for MIME types in format
  • Add recommended center, minzoom, and maxzoom to metadata
  • Document what version and type are for. (As far as I know nothing actually cares, so maybe they should be removed instead.)
  • Document json field, which is required for Mapbox Vector Tiles
  • Include the formula for converting between TMS Y axis and tile URL Y axis
  • Maybe make all the metadata except name, format, and json optional, since existing implementations will infer the rest
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Oct 8, 2016

I view indexes as an implantation detail because views are allowed, they don't need to be tables.

More on other comments when I get home.

pnorman commented Oct 8, 2016

I view indexes as an implantation detail because views are allowed, they don't need to be tables.

More on other comments when I get home.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Oct 11, 2016

@pnorman The only tool I know that insists on a particular format is tile-reduce, which wants pbf, but that should be easy to fix. Given that, I'm fine with requiring a MIME type going forward.

I could see grandfathering jpg and png, but never pbf which no conformant mbtiles implementations would have produced. pbf also has the problem that there's lots of different pbf encodings for geodata.

The wording that I came up with for the json row is in my pull request if you'd like to use it.

I looked at it, and I'm 👎 on using it because it puts lots of format-specific data into the spec, and does so in the wrong way. If we wanted to add additional information we should do so with additional metadata keys or additional tables.

pnorman commented Oct 11, 2016

@pnorman The only tool I know that insists on a particular format is tile-reduce, which wants pbf, but that should be easy to fix. Given that, I'm fine with requiring a MIME type going forward.

I could see grandfathering jpg and png, but never pbf which no conformant mbtiles implementations would have produced. pbf also has the problem that there's lots of different pbf encodings for geodata.

The wording that I came up with for the json row is in my pull request if you'd like to use it.

I looked at it, and I'm 👎 on using it because it puts lots of format-specific data into the spec, and does so in the wrong way. If we wanted to add additional information we should do so with additional metadata keys or additional tables.

@ericfischer

This comment has been minimized.

Show comment
Hide comment
@ericfischer

ericfischer Oct 11, 2016

Contributor

@pnorman I'm ok with putting the json definition in some other document and just referring to it here, but it has been a de facto requirement for producing vector tilesets that the Mapbox Unpacker will accept for more than two years, and I think it would be negligent to revise the spec without documenting it.

Contributor

ericfischer commented Oct 11, 2016

@pnorman I'm ok with putting the json definition in some other document and just referring to it here, but it has been a de facto requirement for producing vector tilesets that the Mapbox Unpacker will accept for more than two years, and I think it would be negligent to revise the spec without documenting it.

pnorman added some commits Oct 12, 2016

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Oct 12, 2016

  • Made some metadata OPTIONAL
  • Added a section on implementation compatibility
  • Added wording about TMS tile_row != XYZ y
  • Added myself to authors list

json is implementation specific and not all implementations require or produce this.

I am happy with the state of the PR, although another pass of copyediting would be welcome.

pnorman commented Oct 12, 2016

  • Made some metadata OPTIONAL
  • Added a section on implementation compatibility
  • Added wording about TMS tile_row != XYZ y
  • Added myself to authors list

json is implementation specific and not all implementations require or produce this.

I am happy with the state of the PR, although another pass of copyediting would be welcome.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 22, 2016

I am happy with the state of the PR, although another pass of copyediting would be welcome.

What else needs doing here?

pnorman commented Nov 22, 2016

I am happy with the state of the PR, although another pass of copyediting would be welcome.

What else needs doing here?

@ImreSamu

This comment has been minimized.

Show comment
Hide comment
@ImreSamu

ImreSamu Nov 22, 2016

Thank you for working on this ..

It is possible to modify the spec to

  • language neutral

  • and add multi-language support ( like in OpenStreetMap )

    • attribution_<language_code>: An attribution string, which explains in <language_code> (and HTML) the sources of data and/or style for the map.
    • description_<language_code>: A description ( in <language_code> ) of the layer as plain utf text

ImreSamu commented Nov 22, 2016

Thank you for working on this ..

It is possible to modify the spec to

  • language neutral

  • and add multi-language support ( like in OpenStreetMap )

    • attribution_<language_code>: An attribution string, which explains in <language_code> (and HTML) the sources of data and/or style for the map.
    • description_<language_code>: A description ( in <language_code> ) of the layer as plain utf text
@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 22, 2016

language neutral

Yes, I can fix this to be non-discriminatory. The encoding of strings is part of sqlite, and not something that belongs here, and I don't even think you have a good way to see what the encoding is.

pnorman commented Nov 22, 2016

language neutral

Yes, I can fix this to be non-discriminatory. The encoding of strings is part of sqlite, and not something that belongs here, and I don't even think you have a good way to see what the encoding is.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Feb 22, 2017

I believe all outstanding issues are solved.

Do the maintainers see anything else that needs changing?

pnorman commented Feb 22, 2017

I believe all outstanding issues are solved.

Do the maintainers see anything else that needs changing?

@TimSC

This comment has been minimized.

Show comment
Hide comment
@TimSC

TimSC Jun 4, 2017

I support the suggestion by @ericfischer that version could do with clarification. "Version of the mbtiles spec? Revision of the tileset itself? Something else?"

TimSC commented Jun 4, 2017

I support the suggestion by @ericfischer that version could do with clarification. "Version of the mbtiles spec? Revision of the tileset itself? Something else?"

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Nov 21, 2017

Pinging @flippmoke on this, since he said mapbox is resuming work on mbtiles

pnorman commented Nov 21, 2017

Pinging @flippmoke on this, since he said mapbox is resuming work on mbtiles

@flippmoke

This comment has been minimized.

Show comment
Hide comment
@flippmoke
Member

flippmoke commented Nov 22, 2017

/cc @ericfischer

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman commented Jan 9, 2018

@flippmoke

This comment has been minimized.

Show comment
Hide comment
@flippmoke

flippmoke Jan 16, 2018

Member

After some discussion with @ericfischer and @springmeyer on this issue last week we have decided to hold off on this until after #47 is complete. Our initial goal is to have the spec represent what is currently existing in the wild and then from there work towards how we want the spec to actually be. I believe this PR has a lot of potential in it for the next version 2.0 of the spec after 1.3.

If there are elements of this PR that should be moved into 1.3 (if they represent what is currently existing in the wild), please note and we will do our best to update it there.

That being said, I am somewhat concerned about the rebase of this branch after we update to 1.3 as we will need to "rebase" the spec here.

Member

flippmoke commented Jan 16, 2018

After some discussion with @ericfischer and @springmeyer on this issue last week we have decided to hold off on this until after #47 is complete. Our initial goal is to have the spec represent what is currently existing in the wild and then from there work towards how we want the spec to actually be. I believe this PR has a lot of potential in it for the next version 2.0 of the spec after 1.3.

If there are elements of this PR that should be moved into 1.3 (if they represent what is currently existing in the wild), please note and we will do our best to update it there.

That being said, I am somewhat concerned about the rebase of this branch after we update to 1.3 as we will need to "rebase" the spec here.

@pnorman

This comment has been minimized.

Show comment
Hide comment
@pnorman

pnorman Jan 16, 2018

Our initial goal is to have the spec represent what is currently existing in the wild and then from there work towards how we want the spec to actually be.

That's the goal with this 2.0 work too. Anything in the wild should work with it. The format key has changed, but existing software ignores that.

If there are elements of this PR that should be moved into 1.3 (if they represent what is currently existing in the wild), please note and we will do our best to update it there.

14942c6...pnorman:2.0 is the best thing to look at.

Off hand, I'd add

  • all the grammatical changes
  • use of RFC 2119
  • TMS vs. XYZ wording
  • "The tile_data blob column contains raw tile data in binary." although compression needs to be clarified

That being said, I am somewhat concerned about the rebase of this branch after we update to 1.3 as we will need to "rebase" the spec here.

The git side is easy, because they're all different documents. The problem is applying any changes made in 1.3 to this.

I still feel the 2.0 route is a better one to go with. In any case, I do not expect to allocate any time to it, because I mentally gave up on the mbtiles and tilejson specs a few months ago

pnorman commented Jan 16, 2018

Our initial goal is to have the spec represent what is currently existing in the wild and then from there work towards how we want the spec to actually be.

That's the goal with this 2.0 work too. Anything in the wild should work with it. The format key has changed, but existing software ignores that.

If there are elements of this PR that should be moved into 1.3 (if they represent what is currently existing in the wild), please note and we will do our best to update it there.

14942c6...pnorman:2.0 is the best thing to look at.

Off hand, I'd add

  • all the grammatical changes
  • use of RFC 2119
  • TMS vs. XYZ wording
  • "The tile_data blob column contains raw tile data in binary." although compression needs to be clarified

That being said, I am somewhat concerned about the rebase of this branch after we update to 1.3 as we will need to "rebase" the spec here.

The git side is easy, because they're all different documents. The problem is applying any changes made in 1.3 to this.

I still feel the 2.0 route is a better one to go with. In any case, I do not expect to allocate any time to it, because I mentally gave up on the mbtiles and tilejson specs a few months ago

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment