1.3 - Attempt to document the de facto requirements for mbtiles #47

e-n-f · 2016-10-06T19:26:07Z

incanus

You know better than I the intricacies of de defacto usage these days, so I'm mostly just reviewing grammar and formatting here.

incanus · 2016-10-07T21:44:48Z

README.md

@@ -51,7 +54,8 @@ for presentational data, like rendered map tiles.

 One MBTiles file represents a single tileset, optionally including grids
 of interactivity data. Multiple tilesets - layers, or maps in other terms,
-can be represented by multiple MBTiles files.
+can be represented by multiple MBTiles files. (But vector tiles within a single
+MBTiles file can contain multiple layers.)


I'd lose the parens here since it's a freestanding sentence. Also the But.

incanus · 2016-10-07T21:45:20Z

README.md

+## 1.3
+
+* Information added about vector tiles
+* Metadata revised to reflect de facto usage


I'd add periods to follow the other versions.

incanus · 2016-10-07T21:45:41Z

README.md

-* **Development** - NOT USABLE: [1.2](https://github.com/mapbox/mbtiles-spec/blob/master/1.2/spec.md)
-* **Stable**: [1.1](https://github.com/mapbox/mbtiles-spec/blob/master/1.1/spec.md)
+* **Stable**: [1.3](https://github.com/mapbox/mbtiles-spec/blob/master/1.3/spec.md)
+* NOT USABLE: [1.2](https://github.com/mapbox/mbtiles-spec/blob/master/1.2/spec.md)


Can we elaborate on why 1.2 is not usable? I'm not sure myself.

I'm pretty sure it is usable

incanus · 2016-10-07T21:46:22Z

1.3/spec.md

+## Abstract
+
+MBTiles is a specification for storing tiled map data in
+[SQLite](http://sqlite.org/) databases for immediate usage and for transfer.


for efficient transfer?

This isn't a wording change - I prefer this existing wording because it describes what the spec does.

incanus · 2016-10-07T21:48:05Z

1.3/spec.md

+One other row is **required** if the `format` is `pbf` or `mvt`:
+
+* `json`: Lists the layers that appear in the vector tiles and the names and types of
+  the attributes of features that appear in those layers. See below for more detail.


Anchor link to "below"?

incanus · 2016-10-07T21:49:06Z

1.3/spec.md

+
+### Example
+
+A vector tileset that contains United States counties and primary roads from TIGER might


Link TIGER?

incanus · 2016-10-07T21:49:50Z

1.3/spec.md

+* `type`: `overlay`
+* `version`: `2`
+* `scheme`: `tms`
+* `json`: `{"vector_layers": [ { "id": "tl_2016_us_county", "description": "Census counties", "minzoom": 0, "maxzoom": 5, "fields": {"ALAND": "Number", "AWATER": "Number", "COUNTYFP": "String", "GEOID": "String", "MTFCC": "String", "NAME": "String", "NAMELSAD": "String", "STATEFP": "String"} }, { "id": "tl_2016_us_primaryroads", "description": "Census primary roads", "minzoom": 0, "maxzoom": 5, "fields": {"FULLNAME": "String", "LINEARID": "String", "MTFCC": "String", "RTTYP": "String"} } ] }`


Since this is a pseudo-table anyway, maybe pretty format the json field for legibility?

e-n-f · 2016-10-07T22:05:20Z

@incanus I incorporated most of these suggestions, except

I don't know why 1.2 is not usable. Maybe @tmcw does, since he added that annotation.
I don't know how to pretty-print the JSON within a Markdown bulleted list. But I'll try to figure it out.

incanus · 2016-10-07T22:06:47Z

Looks good. I will take a crack at the formatting, too.

migurski · 2016-10-07T22:08:13Z

To pretty-print the JSON within a Markdown bulleted list, try:

json:

{
    "vector_layers": [
        {
            "description": "Census counties",
            "fields": {
                "ALAND": "Number",
                "AWATER": "Number",
                "COUNTYFP": "String",
                "GEOID": "String",
                "MTFCC": "String",
                "NAME": "String",
                "NAMELSAD": "String",
                "STATEFP": "String"
            },
            "id": "tl_2016_us_county",
            "maxzoom": 5,
            "minzoom": 0
        },
        {
            "description": "Census primary roads",
            "fields": {
                "FULLNAME": "String",
                "LINEARID": "String",
                "MTFCC": "String",
                "RTTYP": "String"
            },
            "id": "tl_2016_us_primaryroads",
            "maxzoom": 5,
            "minzoom": 0
        }
    ]
}

incanus · 2016-10-07T22:10:17Z

Yeah, exactly. See here: https://gist.github.com/incanus/969d3cc9fd1f3a66263b33d90ff3ce68

e-n-f · 2016-10-07T22:12:24Z

Thanks. I guess that's clear enough that it's meant to be part of the bullet.

pnorman · 2016-10-08T15:13:29Z

I'd rather abandon this in favour of 2.0.

e-n-f · 2016-10-10T06:45:51Z

@pnorman I agree that there's no need for this separate PR to exist if the 2.0 spec ends up containing all the necessary information to create working mbtiles files.

kkaefer · 2016-10-11T08:10:13Z

@ericfischer could you please also provide a diff to the previous version?

e-n-f · 2016-10-11T17:14:25Z

@kkaefer I don't know how to make github show a diff between two files with different names, but here it is as a gist: https://gist.github.com/ericfischer/121213249c8d87d632fb89579ba54672

pnorman · 2016-10-11T22:01:41Z

It's best to do what I did and copy old_ver to new_ver in one commit then change new_ver so you can do a diff between the tip of the branch and the commit that copies. e.g. 14942c6...pnorman:2.0

e-n-f · 2016-10-11T22:18:53Z

Great idea @pnorman. I'll make a new branch that does that.

e-n-f · 2016-10-11T22:26:36Z

Thanks again @pnorman. @kkaefer, the diff is c689a6a...vector-revision.

kkaefer · 2016-10-12T10:43:16Z

1.3/spec.md

+`pbf` and `mvt` both refer to zlib-deflated vector tile data in
+[Mapbox Vector Tile](https://github.com/mapbox/vector-tile-spec/) format.
+Historically, vector tilesets have been written with `pbf` as the `format`,
+but version 2 and beyond of the Mapbox Vector Tile spec prefer `mvt`.


Maybe explicitly mention that they should be treated as identical.

kkaefer · 2016-10-12T10:44:20Z

1.3/spec.md

-The `tile_data blob` column contains raw image data in binary.
+Note that the Y axis is reversed from the coordinate system commonly used in the URLs
+to request individual tiles, so the tile commonly referred to as 11/327/791 is inserted as
+`zoom_level` 11, `tile_column` 327, and `tile_row` 1256, since 1256 is 2^11 - 1 - 791.


This schema is known as "TMS"

kkaefer · 2016-10-12T10:46:13Z

1.3/spec.md

+The row contains a single JSON object with a `vector_layers` key, whose value is an array of layers.
+Each layer is a JSON object with the following keys:
+
+* `id`: The layer ID, used for a [CartoCSS selector](https://tilemill-project.github.io/tilemill/docs/guides/selectors/) or [Mapbox GL Style layer](https://www.mapbox.com/mapbox-gl-style-spec/#layers).


It's a string?

kkaefer · 2016-10-12T10:46:30Z

1.3/spec.md

+
+* `id`: The layer ID, used for a [CartoCSS selector](https://tilemill-project.github.io/tilemill/docs/guides/selectors/) or [Mapbox GL Style layer](https://www.mapbox.com/mapbox-gl-style-spec/#layers).
+* `description`: A human-readable description of the layer's contents (or empty string if not available).
+* `fields`: A JSON object whose keys and values are the names and types of attributes available in this layer. The type should be `Number`, `Boolean`, or `String`.


Is it a string "Number"?

e-n-f · 2016-10-12T19:55:45Z

Thanks @kkaefer. I hope these latest revisions address your comments.

pnorman

I feel #46 is a much better approach, so haven't given this an in-depth edit, but I have a number of concerns

The proposed 1.3 is incompatible with de-facto usage, because it
- has implementation-specific details like a json field which not all producers or consumers need or use
- Prohibits o5m, topojson, and geojson vector tiles, all of which have been or are likely to be seen in the wild
- Has implementation specific index details that are incompatible with some implementations
- It is incompatible with storing gzip compressed MapBox vector tiles, a common de-facto use
Maintains confusion on what precisely is a requirement with no use of RFC 2119 keywords or similar

pnorman · 2016-10-13T03:48:22Z

1.3/spec.md

+are tagged with a `format` of `pbf`, which should be treated as
+a synonym for `application/vnd.mapbox-vector-tile`.
+
+Four rows in `metadata` are **suggested** and, if provided, may enhance performance:


It's not clear how these keys relate to performance

Good point. Previous versions of the spec included this performance reference but I am happy to get rid of it.

pnorman · 2016-10-13T03:48:48Z

1.3/spec.md

+* `type`: `overlay` or `baselayer`
+* `version`: The version of the tileset, as a plain number.
+  This refers to a revision of the tileset itself, not of the MBTiles specification.
+* `scheme`: `tms`, to make the tiling scheme explicit


tms is the only allowed scheme, so what's the point of a metadata item which only has one allowed value?

Good point. I mentioned this only because someone filed a ticket asking for it, but I should not be inventing fields when my only goal is to document what existing implementations do.

pnorman · 2016-10-13T03:50:10Z

1.3/spec.md

+For new tilesets, the `format` should be a MIME type: for example,
+`image/png` or `image/jpeg` for PNG or JPEG image data, or
+`application/vnd.mapbox-vector-tile` for
+[Mapbox Vector Tile](https://github.com/mapbox/vector-tile-spec/) data.


Listing formats feels like a shoutout to particular formats

Good point. This line can go.

pnorman · 2016-10-13T03:50:38Z

1.3/spec.md

+in existing tilesets and should be treated as synonyms for
+`image/png` and `image/jpeg`. Many existing Mapbox Vector Tile tilesets
+are tagged with a `format` of `pbf`, which should be treated as
+a synonym for `application/vnd.mapbox-vector-tile`.


👎 to adding more special cases where there isn't cause in the previous version of the spec

There are a lot of existing vector tilesets from Mapbox Studio Classic and Tippecanoe that have a metadata row saying format=pbf. My only goal with this PR is to document what existing implementations do.

pnorman · 2016-10-13T03:54:04Z

1.3/spec.md

+
+It is common to create an index for this table:
+
+    CREATE UNIQUE INDEX name on metadata (name);


Earlier the spec states "Note: the schemas outlined are meant to be followed as interfaces.", so I don't think implementation specific details like this should go in here. An index is also not needed for performance because the metadata table will be under a dozen rows.

I mentioned this index because node-mbtiles and mbutil do it. My only goal with this PR is to describe what existing implementations do.

pnorman · 2016-10-13T04:00:59Z

1.3/spec.md

+Each layer is a JSON object with the following keys:
+
+* `id`: The layer ID, used for a [CartoCSS selector](https://tilemill-project.github.io/tilemill/docs/guides/selectors/) or [Mapbox GL Style layer](https://www.mapbox.com/mapbox-gl-style-spec/#layers).
+* `description`: A human-readable description of the layer's contents (or empty string if not available).


Why not omit if not available?

My understanding is that the implementation requires it to be present even if empty. I should verify that this is actually true.

Thanks. Verified that the description is not actually required.

pnorman · 2016-10-13T04:01:27Z

1.3/spec.md

+The layer object may also contain these keys:
+
+* `minzoom`: The lowest zoom level whose tiles this layer appears in.
+* `maxzoom`: The highest zoom level whose tiles this layer appears in.


How these interact with minzoom and maxzoom of the metadata should be documented.

Good point. Thanks. Will clarify.

pnorman · 2016-10-13T04:01:49Z

1.3/spec.md

+have the following metadata table:
+
+* `name`: `TIGER 2016`
+* `format`: `mvt`


should be a mime type for the example

Good point. Thank you.

pnorman · 2016-10-13T04:03:50Z

1.3/spec.md

+## Abstract
+
+MBTiles is a specification for storing tiled map data in
+[SQLite](http://sqlite.org/) databases for immediate usage and for transfer.


This isn't a wording change - I prefer this existing wording because it describes what the spec does.

pnorman · 2016-10-13T04:10:10Z

1.3/spec.md

+
+    CREATE TABLE tiles (zoom_level integer, tile_column integer, tile_row integer, tile_data blob);
+
+It is common to create an index for this table:


Isn't this table normally a view, making it rare for this to be the case?

it's a table in mbutil and tippecanoe and a view in node-mbtiles. I didn't realize it was often a view because I was following mbutils (and previous versions of this spec).

iandees · 2016-10-18T20:51:32Z

1.3/spec.md

+to summarize what layers are available in the tiles and what attributes are available for the
+features in those layers.
+
+The row contains the string representation of a JSON object with a `vector_layers` key, whose value is an array of layers.


Specify string encoding as UTF-8?

I believe UTF8 is the sole legal JSON encoding.

ImreSamu · 2016-11-22T15:04:28Z

( language neutrality , multi-language support )

I added my opinion to #46 (comment) and probably also relevant for this spec.

pnorman

We're back to no longer documenting de-facto requirements and prohibiting o5m, topojson, and geojson vector tiles. Mbtiles of these exist, and the de-facto requirements need to reflect that.

…ded CONTRIBUTING.md process. Updated the wording of several statements in 1.3 of the spec. Clarified the use of RFC 2119.

flippmoke · 2018-01-16T15:25:03Z

1.3/spec.md

+
+The database MUST contain a table or view named `metadata`.
+
+This table or view MUST yield exactly two columns named `name` and


We should specify the types of the columns here.

Thanks @flippmoke. This and your other comments should be fixed in dc659f4

flippmoke · 2018-01-16T15:28:18Z

1.3/spec.md

+The metadata table is used as a key/value store for settings. It MUST contain these two rows:
+
+* `name`: The human-readable name of the tileset.
+* `format`: The file format of the tile data: `pbf`, `jpg`, `png`, or a MIME type for other formats.


Is "MIME type" the correct thing here? If so should we specify MIME types RFC and/or link https://www.iana.org/assignments/media-types/media-types.xhtml ?

flippmoke · 2018-01-16T15:29:46Z

1.3/spec.md

+
+The database MAY have tables named `grids` and `grid_data`.
+
+The `grids` table MUST contain four columns, named `zoom_level`, `tile_column`,


Should we specify the types of the columns here?

flippmoke · 2018-01-16T15:31:46Z

1.3/spec.md

+
+    CREATE TABLE grids (zoom_level integer, tile_column integer, tile_row integer, grid blob);
+
+The `grid_data` table MUST contain five columns named `zoom_level`, `tile_column`,


Column types specified here as well?

flippmoke · 2018-01-16T15:32:43Z

1.3/spec.md

+* `minzoom`: The lowest zoom level whose tiles this layer appears in.
+* `maxzoom`: The highest zoom level whose tiles this layer appears in.
+
+The `minzoom` SHOULD be greater than or equal to the tileset's `minzoom`,


Why SHOULD here instead of MUST?

You're right, there's no good reason that a layer's zoom levels should go beyond the tileset's.

You might also add wording such as "If minzoom exists..."

flippmoke · 2018-01-17T17:46:42Z

From @pnorman in 2.0 pull request on things to be migrated here:

all the grammatical changes (@pnorman clarify or check?)
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

flippmoke · 2018-01-29T19:05:05Z

1.3/spec.md

+  area covered by all zoom levels. The bounds are represented as `WGS 84`
+  latitude and longitude values, in the OpenLayers Bounds format
+  (left, bottom, right, top). For example, the `bounds` of the full Earth, minus the poles, would be:
+  `-180.0,-85,180,85`.


I assume the -180.0,-85,180,85 is supposed to be web mercator format. However, should the bounds actually be -180.0,-85.06,180.0,85.06 which is ESPG:3857?

sfkeller · 2018-02-01T09:11:52Z

From what I see, vector_layers is mandatory but bounds (extent), minzoom and maxzoom are optional.

I'm aware of reasons to make them optional, but on the other hand, that's exactly the raison-d'etre having this metadata. Clients now have to scan the data to extract the required metadata by themselves which implies delays in order of seconds to minutes.

There are even situations where the extraction e.g. of bounds is impossible for a client: Look at the
missing tiles approach at https://github.com/mapbox/tilelive-vector (to "avoid requiring many duplicate or empty vector tiles to be generated at high zoom levels, the backend source can specify a maskLevel..."). In other words, there are missing tiles on purpose (response is NULL/http 404) which triggers a lookup at client side of the tiles contents at maskLevel.

In addition when comparing with OGC WMS/WMTS, bounds are mandatory there too.

I therefore suggest to make at least bounds mandatory, if possible also minzoom and maxzoom.

flippmoke · 2018-02-02T14:13:48Z

@sfkeller I think I agree that it should be required in 1.3.

That said, I do want to key in on something as we write this though, we need to be careful how we term optional and required in 1.3. The intent of 1.3 is to "describe the existing world". I know that this might not always be the same between all implementations, but making things required that might have been optional in code or datasets could suddenly cause mbtiles files to fail processing where they might not have prior (if someone were to update to follow the spec in their code).

I think making this ideal should be shifted to 2.0 where I think we can be much more strict and we can have fallback approaches for old files still on the 1.x. A much more strict difference in version might be nice? Its a very slight difference, but I think one we should consider as we move forward.

ImreSamu · 2018-02-02T17:27:33Z

@flippmoke

The intent of 1.3 is to "describe the existing world"

I have checked the OSM QA TILES metadata

sqlite> select * from metadata;
scheme|tms
basename|hungary.mbtiles
id|31012018194303.planet
filesize|34391547904
name|hungary.mbtiles
description|hungary.mbtiles
version|2
minzoom|12
maxzoom|12
center|19.2041015625,47.171156436539384,12
bounds|16.171875,45.767522962149904,22.236328125,48.574789910928864
type|overlay
format|pbf
json|{"vector_layers":[{"id":"osm","description":"","minzoom":12,"maxzoom":12,"fields":{}}]}

and as I see - it has a following json row - with empty fields(object)

{  
   "vector_layers":[  
      {  
         "id":"osm",
         "description":"",
         "minzoom":12,
         "maxzoom":12,
         "fields":{}
      }
   ]
}

imho: the fields(object) is optional.
Is it possible to add an OSM QA Tiles metadata as a second example?

mnboos · 2018-02-02T19:35:46Z

@flippmoke

but making things required that might have been optional in code or datasets could suddenly cause mbtiles files to fail processing where they might not have prior (if someone were to update to follow the spec in their code).

Isn't that exactly the idea of a specification? The client then acts accordingly to 1.3 and discards the invalid mbtiles. IMHO the idea of a specification is to describe the current situation, but to say how clients have to behave. At the moment, it's exactly the other way round.

flippmoke · 2018-02-02T20:05:51Z

@mnboos frankly, that is the way it should be. However, development outpaced the specification and existing data in a format exists. I do not want to invalidate a large amount of existing users files if possible suddenly. This is Mapbox's fault. We should have updated the spec as needed.

sfkeller · 2018-02-02T20:10:45Z

@flippmoke Can you enumerate which existing (Mapbox) software and data would not be aligned with mandatory/required vector_layers, bounds (extent), minzoom and maxzoom?

flippmoke · 2018-02-02T20:14:10Z

@sfkeller -- just to clarify, I am all for making it required in this version (interested in @ericfischer 's view however). I just wanted to make sure it was clear about the intention of this release, so a flood of other review items would not be brought up as to how it should be written. This difference is why we decided to go with 1.3 first then make clear changes to how the future should be in 2.0.

sfkeller · 2018-02-02T20:47:45Z

So you say that there exist large amounts of mbtiles user files that have no bounds, minzoom nor maxzoom? I'm astonished about this and somehow left in the dark which (Mapbox) software does not produce these metadata items.

Anyhow. How about this:

Let's go then with 1.3, but add a hint that bounds, minzoom and maxzoom will possibly become required in a next spec. release.
Update TileJSON spec. to vector tiles too.
Initiate a process to update both, mbtiles and TileJSON spec., which includes these attributes being mandatory.

I hope that this processes won't be delayed again. And I suggest that a future spec.s won't be too ambitious since I fear, it could be then blocked by discussions about other far more fundamental additions.

flippmoke · 2018-02-02T20:55:04Z

So you say that there exist large amounts of mbtiles user files that have no bounds, minzoom nor maxzoom? I'm astonished about this and somehow left in the dark which (Mapbox) software does not produce these metadata items.

@sfkeller to be clear, I have no idea if it does or does not. If it does not we should fix this immediately I would think. I agree that we should make the language here to be required. I do not interact with this spec or its software almost at all. I am simply working to help facilitate this document to completion.

I hope that this processes won't be delayed again.

I hope not as well. I know that @ericfischer is on travel currently but will look into this on Monday when he is back. My goal is that Monday/Tuesday we can have this completed and merged.

And I suggest that a future spec.s won't be too ambitious since I fear, it could be then blocked by discussions about other far more fundamental additions.

I have no idea how ambitious the future spec should be here.

sfkeller · 2018-02-06T13:23:18Z

Thanks @ericfischer and @flippmoke and all for the release 1.3!

I've helped out for quite some time to standardize - actually since OGC & ISO 19000 started. But I've never seen such an immediate response like this after this release (see e.g. https://twitter.com/richardf/status/960802937860747264).

Now let's keep the pace and move 1. to sync TileJSON spec. (c.f. mapbox/tilejson-spec#14 (comment)) and 2. to MBTiles spec. 2.0.

e-n-f mentioned this pull request Oct 6, 2016

2.0 spec #46

Open

incanus approved these changes Oct 7, 2016

View reviewed changes

e-n-f added 4 commits October 11, 2016 15:20

Copy 1.2 spec as baseline

c689a6a

Attempt to document the de facto requirements for mbtiles

3c82dba

Add links and reformat as suggested by incanus

6663d75

Pretty-print the JSON block

062347e

e-n-f force-pushed the vector-revision branch from 8c04d1b to 062347e Compare October 11, 2016 22:25

kkaefer reviewed Oct 12, 2016

View reviewed changes

Clarifications on format, scheme, and vector attribute types

27886f6

pnorman suggested changes Oct 13, 2016

View reviewed changes

e-n-f added 2 commits October 13, 2016 12:32

Incorporate corrections and clarifications from pnorman

7b42122

The description is not required in vector layer metadata

ee3efc0

iandees reviewed Oct 18, 2016

View reviewed changes

Really document de facto requirements, not what it should have been

8539170

e-n-f force-pushed the vector-revision branch from cf9c3ff to 8539170 Compare February 22, 2017 00:45

pnorman suggested changes Feb 22, 2017

View reviewed changes

Re-organized README, created a CHANGELOG file, added LICENSE file, ad…

16f4e67

…ded CONTRIBUTING.md process. Updated the wording of several statements in 1.3 of the spec. Clarified the use of RFC 2119.

flippmoke reviewed Jan 16, 2018

View reviewed changes

Add Paul to authors

7fb73ed

flippmoke changed the title ~~Attempt to document the de facto requirements for mbtiles~~ 1.3 - Attempt to document the de facto requirements for mbtiles Jan 16, 2018

e-n-f added 2 commits January 16, 2018 15:29

Clarify types of columns and fields

dc659f4

Avoid running name and type together

d2f5b1f

sfkeller mentioned this pull request Jan 17, 2018

Check for compatibility of MBTiles Spec 1.3 geometalab/Vector-Tiles-Reader-QGIS-Plugin#174

Closed

flippmoke assigned flippmoke and e-n-f Jan 17, 2018

e-n-f added 3 commits January 22, 2018 11:29

Reconcile with some of Paul's wording

684a518

Clean up punctuation a little more

bfa6bfd

Also add webp as a grandfathered format

d22c278

flippmoke reviewed Jan 29, 2018

View reviewed changes

e-n-f mentioned this pull request Jan 30, 2018

Document vector_layers extension mapbox/tilejson-spec#14

Open

sfkeller mentioned this pull request Feb 4, 2018

Can MVT vector tiles be added from a local server? geometalab/Vector-Tiles-Reader-QGIS-Plugin#181

Closed

Call out known spec problems to be addressed in the future

1970e38

e-n-f force-pushed the vector-revision branch from ead2a4e to 1970e38 Compare February 5, 2018 22:21

e-n-f merged commit 6643d4d into master Feb 5, 2018

e-n-f deleted the vector-revision branch February 5, 2018 22:27


		### Example

		A vector tileset that contains United States counties and primary roads from TIGER might


		It is common to create an index for this table:

		CREATE UNIQUE INDEX name on metadata (name);


		CREATE TABLE tiles (zoom_level integer, tile_column integer, tile_row integer, tile_data blob);

		It is common to create an index for this table:


		The database MUST contain a table or view named `metadata`.

		This table or view MUST yield exactly two columns named `name` and


		The database MAY have tables named `grids` and `grid_data`.

		The `grids` table MUST contain four columns, named `zoom_level`, `tile_column`,


		CREATE TABLE grids (zoom_level integer, tile_column integer, tile_row integer, grid blob);

		The `grid_data` table MUST contain five columns named `zoom_level`, `tile_column`,

1.3 - Attempt to document the de facto requirements for mbtiles #47

1.3 - Attempt to document the de facto requirements for mbtiles #47

Conversation

e-n-f commented Oct 6, 2016

incanus left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

e-n-f commented Oct 7, 2016

incanus commented Oct 7, 2016

migurski commented Oct 7, 2016

incanus commented Oct 7, 2016

e-n-f commented Oct 7, 2016

pnorman commented Oct 8, 2016

e-n-f commented Oct 10, 2016

kkaefer commented Oct 11, 2016

e-n-f commented Oct 11, 2016

pnorman commented Oct 11, 2016

e-n-f commented Oct 11, 2016

e-n-f commented Oct 11, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

e-n-f commented Oct 12, 2016

pnorman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ImreSamu commented Nov 22, 2016

pnorman left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

flippmoke commented Jan 17, 2018

Choose a reason for hiding this comment

sfkeller commented Feb 1, 2018 • edited Loading

flippmoke commented Feb 2, 2018

ImreSamu commented Feb 2, 2018

mnboos commented Feb 2, 2018 • edited Loading

flippmoke commented Feb 2, 2018

sfkeller commented Feb 2, 2018

flippmoke commented Feb 2, 2018 • edited Loading

sfkeller commented Feb 2, 2018 • edited Loading

flippmoke commented Feb 2, 2018

sfkeller commented Feb 6, 2018 • edited Loading

sfkeller commented Feb 1, 2018 •

edited

Loading

mnboos commented Feb 2, 2018 •

edited

Loading

flippmoke commented Feb 2, 2018 •

edited

Loading

sfkeller commented Feb 2, 2018 •

edited

Loading

sfkeller commented Feb 6, 2018 •

edited

Loading