[Geopackage] gpkg_contents when type is not 'feature' or 'tiles'

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Fri Nov 14 11:19:21 EST 2014

> IIRC it was modelled off the existing extensions/template which had a SQL statement in that section.
AFAICT there aren’t any.

> The applicability section can state that this extension can be applied to individual tables or globally but not to individual columns. It currently states 'applicable to any table with type aspatial’ but that’s kind of a recursive definition. That basically says ’this extension applies to tables that comply with this extension’. I would rephrase that to say that it can be applied to any table that is not ‘features’ or ’tiles’ or something along those lines.
> But it doesn't though - it only applies to tables listed in gpkg_contents with type="aspatial". The only way to extend beyond "features"/"tiles" in gpkg_contents is via extension, which is this attempt. IMO we need to keep driving the index of data from gpkg_contents, not pick up any DB table -- that would unnecessarily constrain other extensions.
> Concept was: Add extension, which allows you to add rows to gpkg_contents with type=aspatial, which allows you to have data tables & metadata support for tables without geometry columns.
On second thought, yes you’re right that this kind of circular dependency is probably unavoidable when introducing a new type.

> I had another look through the spec... I can't see how either "Zoom Other Intervals Extension" or "Tiles Encoding WebP Extension" are conceptually much different - they're both applied at a global level, and the parser which rejects anything even slightly unknown will presumably reject both databases even if it was perfectly capable of reading feature data or non-WebP tiles from those geopackages. In hindsight, a field in gpkg_extensions describing which data types ("features", "tiles", "aspatial", whatever) the extension applies to would make this simpler. All the existing extensions apply only to a single data type, but are specified as global.
Sounds like there’s some work to do on describing how extensions are intended to be used. You’re description is one interpretation, but it’s not what I had in mind when I proposed and wrote the spec :)

The idea behind the extensions table is that you can specifically flag individual tables or columns that colour outside the lines of the base spec. Suppose for instance that you have a geopackage containing two tiles datasets A and B. A is encoded using PNG, B using WebP. A is a standard tiles dataset, B is not. What this should look like in the geopackage is
  A, tiles
  B, tiles

  table_name B, column_name null, extension_name gpkg_webp, scope read-write

This is intended to communicate
  A is tiles; nothing special
  B is tiles; tiles may be encoded using WebP; this affects both read and write access to table B

If you instead put
  table_name null, column_name null, extension_name gpkg_webp, scope read-write

you’re basically saying ‘any tiles data set may contain webp encoded tiles’. If that’s what you’re trying to communicate then no problem, but I would personally advise against it for the reasons mentioned earlier.

I’ll admit that the text on extensions and the extension specs don’t explain this very clearly at the moment. The WebP one for instance says under applicability:
  This extension applies to any table listed in the gpkg_contents table with a data_type of tiles.
Rather saying ‘applies’ that should be ‘can be applied’.

> OT: what's the process for requesting fixes to other bugs in the Spec for future versions? Just start threads on the mailing list with proposed amendments?
I’m still pretty new to OGC policies and procedures. Paul Daisey can answer this better than I can.


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

More information about the Geopackage mailing list