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

<snip>

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
https://github.com/OSGeo/gdal/blob/trunk/gdal/ogr/ogrsf_frmts/gpkg/geopackage_aspatial.md

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
amendments?
-------------- 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