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

Robert Coup robert.coup at koordinates.com
Thu Nov 13 13:49:39 EST 2014

Hi Pepjin,

On Thu, Nov 13, 2014 at 11:02 PM, Pepijn Van Eeckhoudt <
pepijn.vaneeckhoudt at luciad.com> wrote:

> On 10 Nov 2014, at 18:17, Robert Coup <robert.coup at koordinates.com> wrote:
> Under 'Extension Name or Template’ the spec currently states


To me that basically says this is literally what I should do which imo is
> too broad. You’re telling people that this should always be applied
> globally to the entire database.
> I would replace that with something less explicit that lists the
> extension_name, definition and scope values. Leave it up to users of the
> extension to apply it on specific tables or the entire geopackage.

IIRC it was modelled off the existing extensions/template which had a SQL
statement in that section.

> 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.

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.

> Is the source of that document under version control somewhere? I can make
> a patch with suggested tweaks if you like.

It's in the GDAL codebase, but there's an implementation of it which will
need to be updated as well.

The spec is in

Rob :)

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20141114/45ab8d83/attachment.html>

More information about the Geopackage mailing list