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

Pepijn Van Eeckhoudt pepijn.vaneeckhoudt at luciad.com
Mon Nov 10 10:01:26 EST 2014

> On 09 Nov 2014, at 21:52, Robert Coup <robert.coup at koordinates.com> wrote:
> Hi all,
> On Mon, Nov 10, 2014 at 5:09 AM, Whittington, Reed <rwhittington at burnsmcd.com <mailto: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*.

Not really an oversight imo. The GeoPackage spec covers encoding spatial data in SQLite databases. We considered anything non-spatial out of scope for v1.0. You’re free to encode that type of data however you like.
The recurring example that we used most of the time was routing networks. This was out of scope for 1.0 and people are free to encode that however they like.
> > 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

The danger of applying it globally is in the last bullet point. If an implementation doesn’t support gdal_aspatial, it will ignore the entire database; not just the datasets to which the extension actually applies. That includes any additional datasets that may not be part of the GeoPackage yet when it was created.

I’m not saying that you should absolutely not do this. It’s just that the extension spec that Even linked to states that you should use ‘NULL’ as the table name. I was question whether that was intentional or not. I personally think it’s excessively broad to state that in an extension spec.

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

As always, it depends (see http://queue.acm.org/detail.cfm?id=1999945 <http://queue.acm.org/detail.cfm?id=1999945> and http://www.tbray.org/ongoing/When/200x/2004/01/11/PostelPilgrim). For read-only purposes, that’s one possible strategy, but not without downsides.
If you delay reporting errors, things may go wrong at some seemingly random point during the execution of a program. If, for instance, you page in data as the user pans across the globe, you might all of a sudden hit an unsupported geometry and present an error out of the blue.
If you choose to skip over unsupported data then there might be safety issues to take into account. Silently discarding data is a bad idea in many cases. You might be discarding mission critical data which could have catastrophic effects.

In a read-write scenario things get a bit tickier. Suppose I don’t support the rtree extension and soldier on anyway. Then you’ll end up getting an error for the first geometry write that you attempt. It seems nicer to the user to simply be able to disable writes to the dataset in question when this situation is detected. You could also imagine cases where you end up accidentally corrupting a dataset because you’re not taking the rules of some particular extension into account when writing to a dataset.

gpkg_extensions exists to give people the choice to abort when something unsupported is detected. You don’t have to do this, but the option is there and you’re ignoring a red flag if you choose to continue anyway.

Best regards,

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

More information about the Geopackage mailing list