[Geopackage] New blog post: what about vector tiles in GeoPackage?

Jeff Yutzler jeffy at imagemattersllc.com
Thu Jul 5 09:59:06 EDT 2018


Adam,
Yes, it was specifically designed to align to MVT. It is a strawman - if
someone wants an MVT-based approach I want them to start with that because
it has at least been vetted by a couple of people. I have no idea if it
will grow legs or not. It mostly depends on what direction OGC decides to
go in. This time around, there is a strong desire to establish a conceptual
model first and let the encodings flow from that (basically the opposite of
what happened with raster tiling). To that end, there will be yet another
Vector Tiling Ad Hoc in Stuttgart in September. Maybe this time around
there will be a more clearly defined agenda and set of objectives.
-Jeff


On Tue, Jul 3, 2018 at 1:42 PM, Adam Parsons <aparsons at compusult.net> wrote:

> Jeff,
>
> I understand why the design/data model has went this may, it would seem to
> be mostly related to conforming to the current MapBox vector tiles
> approach. I See the data-model fitting more neatly into our current
> GeoPackage core by taking different approaches. (Physical layers for each
> tileset, which can be related back to gpkg_data_columns). Or an
> alternative, in which a feature inside of a Vector tile referenced back to
> a physical vector(feature) tile layer in the geopackage).
>
> This would require post-processing of pre-existing vector tiles to fill a
> vector tile data-model, and could lead to non-conformance for some core
> concepts. These approaches may be better suited though to NOT duplicate
> feature meta-data, and also to have a simplistic approach to constructing a
> complete geometry of a feature instead of having the client doing all the
> work.  I certainly would like to see the ability to incorporate multiple
> vector file formats, since I believe we have at least 2 formats which are
> well supported.
> Thanks,
> Adam
>
>
> On 2018-06-30 04:00 PM, Jeff Yutzler wrote:
>
> Adam,
> In response to your questions:
>
> >  1. Why do we need to explicitly describe what the min and max zoom
> level is for a layer? ... to describe multiple layers inside of a vector
> tile?
>
> Yes
>
> > 2. Why can we not reuse the gpkg_data_columns table? Is it because if
> we have multiple layers inside of a tile then we cannot actually reference
> a TABLE name?
>
> Yes. According to http://www.geopackage.org/spec/#extension_schema
> gpkg_data_columns points to specific tables and columns thereof. We could
> weaken the requirements, but having a separate data model in the vector
> tiles is such a departure from the way things are normally done that I
> don't think this would make anyone's lives easier.
>
> > 3. You are going for a Google Protocol Buffer. Couldn't we support
> multiple formats GeoJSON or GPB based on the data-type of the gpkg_contents
> table?
>
> Maybe. In the Tiled Gridded Coverage Extension
> <http://docs.opengeospatial.org/is/17-066r1/17-066r1.html#CoverageAncillaryTableDefinition>,
> there is just one new gpkg_contents.data_type value (2d-gridded-coverage)
> and the encoding is determined by gpkg_2d_gridded_coverage_ancillary.datatype.
> (BTW, why weren't we consistent? datatype vs data_type...) At this time, we
> don't have a logical place to put a similar column.
>
> > 4. Does it make more sense to have a tile composed of multiple layers?
> Or does it make more sense to have a layer by tile basis? Processing would
> require parsing out tile content and doing explicit operations to determine
> things on a per layer basis.
>
> I don't have a strong opinion here. Anyone else?
>
> -Jeff
>
> On Fri, Jun 29, 2018 at 2:36 PM, Adam Parsons via Geopackage <
> geopackage at lists.opengeospatial.org> wrote:
>
>> Hey Jeff,
>>
>>
>> I have already implemented some vector tiles GeoPackages previously for
>> some OGC test bed, though it was in GeoJSON format. From my experience I
>> have some questions/comments.
>>
>> Possibly these questions will arise from now knowing the Protocol Buffer
>> implementation that well.
>>
>> 1) gpkgext_vt_layers Why do we need to explicitly describe what the min
>> and max zoom level is for a layer? Wouldn't this be described in a tile
>> matrix set table just like raster?
>>     - If we do not need this concept, then why would we need a layers
>> table that is different then contents table? to describe multiple layers
>> inside of a vector tile?
>>
>> 2)
>> gpkgext_vt_fields
>>
>> Why can we not reuse the gpkg_data_columns table? Is it because if we
>> have multiple layers inside of a tile then we cannot actually reference a
>> TABLE name?
>>
>>
>> 3) Data type
>>
>>     - You are going for a Google Protocol Buffer. Couldn't we support
>> multiple formats GeoJSON or GPB based on the data-type of the gpkg_contents
>> table?
>>
>> 4) Layer concept
>>
>>     - Does it make more sense to have a tile composed of multiple layers?
>> Or does it make more sense to have a layer by tile basis? Processing would
>> require parsing out tile content and doing explicit operations to determine
>> things on a per layer basis
>>
>>
>> Furthermore, when I first implemented the GeoJSON format for vector
>> tiles, I basically had to not add any auxiliary tables and could use the
>> current GPKG core model and just add a new data-type and some extension
>> entries.
>>
>>
>> Finally, when implemented there were 2 key concepts that I had to
>> introduce for optimization;
>>
>> 1) An 'ANCHOR' tile which held all feature meta-data information in 1
>> single tile (A tile on the highest zoom level for that feature to reduce
>> putting all feature information in 1 tile). All other tiles containing that
>> feature would reference the ANCHOR feature meta-data tile (This was
>> described as an attribute inside of the GeoJSON)
>>
>> 2)A way of describing the CLIP indices for a feature, when it has to clip
>> the geometry based on a tiles boundaries, to ensure a client can easily
>> reconstruct an entire feature geometry from partial tile vertexes for a
>> feature. (This was described as an attribute inside of the GeoJSON)
>>
>>
>> Thanks,
>> Adam
>>
>>
>> On 2018-06-29 11:51 AM, Jeff Yutzler via Geopackage wrote:
>>
>> Based on the feedback I got from this post, I went ahead and drafted a
>> community extension for vector tiles:
>> https://github.com/jyutzler/geopackage-vector-tiles/blob/mas
>> ter/spec/1_vector_tiles.adoc
>> I'd like for this to at least be the starting point for any use of Vector
>> Tiles in GeoPackage, but there is a long way to go before this becomes a
>> standard.
>> -Jeff
>>
>>
>> 2018-06-27 14:53 GMT-04:00 Jeff Yutzler <jeffy at imagemattersllc.com>:
>>
>>> http://geopackage.blogspot.com/2018/06/what-about-vector-til
>>> es-in-geopackage.html
>>>
>>> --
>>> Jeff Yutzler
>>> Image Matters LLC <http://www.imagemattersllc.com/>
>>> Mobile: (703) 981-8753
>>>
>>
>>
>>
>> --
>> Jeff Yutzler
>> Image Matters LLC <http://www.imagemattersllc.com/>
>> Mobile: (703) 981-8753
>>
>>
>>
>
>
> --
> Jeff Yutzler
> Image Matters LLC <http://www.imagemattersllc.com/>
> Mobile: (703) 981-8753
>
>
>


-- 
Jeff Yutzler
Image Matters LLC <http://www.imagemattersllc.com/>
Mobile: (703) 981-8753
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20180705/99741cf4/attachment.html>


More information about the Geopackage mailing list