Make non-spatial tables discoverable

[jyutzler]

Reference: http://ogc.standardstracker.org/show_request.cgi?id=380

The request calls for supporting non-spatial tables in a GeoPackage . An Extended GeoPackage includes elements that are outside the GeoPackage Core Specification. This is perfectly appropriate, and in many cases encouraged. There is nothing keeping the GeoPackage producer from adding additional tables (whatever the reason) and calling the output file an Extended GeoPackage.

The real issue is discoverability. Some applications do not know how to find these tables inside a GeoPackage. It may be possible for the user to open them manually, but that is unreasonable if there are a large number of tables. A better solution would be to make those tables discoverable.

A simple extension such as the following would support this.

gpkg_extensions column	value
table_name	(actual table name)
column_name	NULL
extension_name	gpkg_non_spatial
definition	TBD
scope	read-write

If desired, this extension could also work with the Schema Extension.

[rouault]

FYI, there is http://www.gdal.org/geopackage_aspatial.html supported since GDAL 2.0 that does the same thing

[jyutzler]

In addition, such a table could get a row in gpkg_contents as follows:

gpkg_contents column	value
table_name	actual table name
data_type	non-spatial
identifier	NULL or any unique name
description	text or NULL
last_change	date formatted as %Y-%m-%dT%H:%M:%fZ
min_x	NULL
min_y	NULL
max_x	NULL
max_y	NULL
srs_id	NULL

This approach would allow clients familiar with the extension to discover the data quite easily. The gpkg_extensions row (from the parent message) would allow a client or power user not familiar with the extension to understand what is going on.

[jyutzler]

It turns out this topic was discussed a while ago http://lists.opengeospatial.org/pipermail/geopackage/2014-June/000022.html

[jyutzler]

Based on SWG discussions, I think we probably will not end up doing what is suggested above. Instead, we are leaning towards the following:

• We might add a clause allowing the use of a datatype of non-spatial in extended GeoPackages to make non-spatial data with no clear semantic meaning easier to discover
• We will recommend that extensions only be used for data that has a clear semantic meaning.

This will probably be resolved at the next TC.

[jyutzler]

At the TC, we agreed on the approach presented by @KRyden which is similar but not identical to the GDAL approach. I am leaving the issue open until I can complete the PR.

[jyutzler]

Fixed by #251

[palmerj]

Hi @jyutzler I see that 1.2 is out for public comment.

Can you please explain why the approach of using "attributes" for the data_type rather than the already in use "aspatial" from the http://www.gdal.org/geopackage_aspatial.html extension?

Functional the approaches are for all intensive purposes the same. The proposal in 1.2 will likely make more effort for software implementations already in play and also mean that dataset will have be re-created. Note our NZ main geospatial portal https://data.linz.govt.nz has been using this aspatial extension for about 2 years.

Regards
Jeremy