Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make non-spatial tables discoverable #221

Closed
jyutzler opened this issue Jun 29, 2016 · 7 comments
Closed

Make non-spatial tables discoverable #221

jyutzler opened this issue Jun 29, 2016 · 7 comments
Milestone

Comments

@jyutzler
Copy link
Contributor

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
Copy link
Contributor

rouault commented Jul 1, 2016

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

@jyutzler
Copy link
Contributor Author

jyutzler commented Jul 1, 2016

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
Copy link
Contributor Author

jyutzler commented Jul 5, 2016

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

@jyutzler jyutzler added this to the post-1.1 milestone Aug 2, 2016
@jyutzler
Copy link
Contributor Author

jyutzler commented Aug 14, 2016

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
Copy link
Contributor Author

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 added a commit to jyutzler/geopackage that referenced this issue Oct 4, 2016
jyutzler added a commit that referenced this issue Oct 4, 2016
adding attributes section #221
@jyutzler
Copy link
Contributor Author

jyutzler commented Oct 4, 2016

Fixed by #251

@jyutzler jyutzler closed this as completed Oct 4, 2016
@palmerj
Copy link

palmerj commented Feb 13, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants