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

Rob.
-- 

*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