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

Robert Coup robert.coup at koordinates.com
Sun Nov 9 15:52:47 EST 2014

Hi all,

On Mon, Nov 10, 2014 at 5:09 AM, Whittington, Reed <
rwhittington at burnsmcd.com> wrote:

> other data models like FME represent non spatial features with a null
> geometry field.

A table without a geometry is conceptually different from a table with some
manufactured null geometry... all we actually want to do is expose normal
SQLite database tables for what they are. Seemed like a big oversight in
the original spec (and easily fixed by editing 21.5), but *shrug*.

> > Le vendredi 07 novembre 2014 17:26:10, Pepijn Van Eeckhoudt a écrit :
> >> Cool, that's the first public extension in the wild that I know of.

Our use case is having a group of related database tables in a GeoPackage,
where a subset of tables have a spatial/geometry component.

> >>
> >> Even, is it the intention that this gets applied to the entire
> >> geopackage (table_name == NULL)? Or should it be applied only to the
> >> aspatial tables themselves (and perhaps any feature tables that have a
> >> foreign reference to the aspatial table)?
> >> Applying a read-write extension to the entire geopackage means that
> >> applications that don't recognize the extension will most likely reject
> >> the geopackage as a whole; not just the tables that aren't supported.

Seemed redundant to repeat it for every single table, so the intention is
to apply it to the entire geopackage.

Our logic was, for a GeoPackage parser author:
 - you'd look in gpkg_extensions for extensions you *do* support (optional
if you only support features/tiles)
 - you'd look in gpkg_contents for data_types you *do* support (ie.
features, tiles)
 - you'd ignore things you don't support

When writing a parser, surely being defensive (ie. take what I can, ignore
what I can't) is always the best approach, rather than halting at the first
sign of anything slightly unusual? Or, as Postel put it:

> In general, an implementation should be conservative in its sending
behavior, and liberal in its receiving behavior. That is, it should be
careful to send well-formed datagrams, but should accept any datagram that
it can interpret (e.g., not object to technical errors where the meaning is
still clear).

Yes, yes, I realise developers aren't always that pragmatic. Though Even's
initial GDAL implementation worked exactly like that, so that's one
datapoint ;)


*Koordinates*PO Box 1604, Shortland St, Auckland 1140, New Zealand
Phone +64-9-966 0433 koordinates.com <https://koordinates.com/about>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geopackage/attachments/20141110/e5e0cb9c/attachment.html>

More information about the Geopackage mailing list