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
Comments
FYI, there is http://www.gdal.org/geopackage_aspatial.html supported since GDAL 2.0 that does the same thing |
In addition, such a table could get a row in
This approach would allow clients familiar with the extension to discover the data quite easily. The |
It turns out this topic was discussed a while ago http://lists.opengeospatial.org/pipermail/geopackage/2014-June/000022.html |
Based on SWG discussions, I think we probably will not end up doing what is suggested above. Instead, we are leaning towards the following:
This will probably be resolved at the next TC. |
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. |
Fixed by #251 |
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 |
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.
If desired, this extension could also work with the Schema Extension.
The text was updated successfully, but these errors were encountered: