[OSM-dev] Migrating osm.org to vectors/Kartotherian

Stadin, Benjamin Benjamin.Stadin at heidelberg-mobil.com
Sat Jan 2 03:08:25 UTC 2016


I know I¹m a bit late...

Am 01.11.15, 04:04 schrieb "Paul Norman" unter <penorman at mac.com>:

>>#2 SQL -> Vectors
>>This is very similar to the set of SQL statements that osm-carto uses
>>to generate data. Mapbox is now on version 6 of vtile structure, so it
>>is obviously a hard problem to nail down. [4] We could make it
>>compatible, or come up with a different structure.
>>TBD: vtile structure
>
>A style designed for showing off OSM data and mapper feedback will put
>different data into vector tile different ways than one designed for
>Wikimedia's purposes. If osm-carto was vector tile based, we'd probably
>be changing the vector tile definitions every 6-12 weeks, and these
>would be backwards-incompatible changes.

Maybe one option would be to "borrow" some parts of the GeoPackage spec
[1] to handle the data aspect.
There is no single answer for how to add tile data to GPKG, but how about
starting with defining a default "OSM presentation data export":
- A standard GPKG container
- including a (probably large) set of gpkg_data_columns definitions
- pure vector features (no tile data at this point)
- versioning (could be done in a quite simple way then probably, since
several concerns are defined by GPKG itself)

Other "consumers" could then add own data and definitions to this
container in a standardized way
(e.g. append some data field and expect the existence of a certain
gpkg_data_columns definition).

There could be a several such OSM containers (though I think the feedback
data could be made part of the presentation data container).

In a next step, this data container can then be further optimized for
rendering by creating tile sets or else - while retaining all data as
defined within the GPKG.
Maybe there can be a tile data BLOB and a user data BLOB (both protocol
buffers) as part of the tile data table.
The user data proto buf must then by definition be an exact match to the
gpkg_data_columns.
So this custom data could be a simple addition to the GPKG tile data spec,
and it should work for both raster and vector tile data.
I've recently made a similar suggestion to a related topic for MapBox on
Github [2]. John Firebaugh's suggestion for vector tiling was to create a
WebP like extension for MapBox vector tiles within GPKG for their next
offline db.

In the end there could (ideally) be a concise set of standardized OSM
exports for different purposes,
a standardized way to deal with and extend this data by external tools and
data, and some way to deal
with different render data formats (e.g. vector tiles or else) with
embedded data. The latter can¹t be standardized easily in my opinion, we
have for example pretty different demands about the rendering data for our
native GL map renderer.

[1] http://www.geopackage.org/spec/
[2] 
https://github.com/mapbox/mapbox-gl-native/issues/3373#issuecomment-1671620
61




More information about the dev mailing list