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

Adam Parsons aparsons at compusult.net
Tue Jul 3 13:42:18 EDT 2018


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 
> <mailto: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/master/spec/1_vector_tiles.adoc
>>     <https://github.com/jyutzler/geopackage-vector-tiles/blob/master/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 <mailto:jeffy at imagemattersllc.com>>:
>>
>>         http://geopackage.blogspot.com/2018/06/what-about-vector-tiles-in-geopackage.html
>>         <http://geopackage.blogspot.com/2018/06/what-about-vector-tiles-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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20180703/a4a28cb0/attachment.html>


More information about the Geopackage mailing list