Closed pvgenuchten closed 4 years ago
Have you considered to create a feature (e.g. inspire_resource
) with the fields uuid
, geom
, time
, language
, title
and abstract
, populate them with data extracted from the metadata stored in gpkg_metadata
and then link in gpkg_metadata_refererence
each row in the feature with the corresponding source metadata record (row
reference scope in gpkg_metadata_refererence
)?
To echo @pvgenuchten on the requirement, if an application adds columns to a gpkg_metadata
table, would this break supporting GeoPackage proper? In various metadata implementations (pycsw, pygeoapi) it would be great to use the gpkg metadata mechanism along with application-specific extensions (i.e. like SQLite's FTS, etc.).
R93 states that gpkg_metadata
table definition is normative.
If you need to add an additional column, you must define a GeoPackage Extension that specifies it. The closest example to your proposal is the extension WKT for Coordinate Reference Systems that defines an additional column to the gpkg_spatial_ref_sys
table. You may propose an extension to add this additional column and if it gets widespread adoption it could become an official extension.
Thank you @fjlopez, linking a metadata record to a feature in an alternative collection would solve this indeed. I did not consider that option. Thinking about it. Having a new collection with features for each dataset is an undesired artifact, users will wonder what the collection is about. I'd go for the extension mechanism. Thanks you for that pointer to the coor-ref-extension.
@pvgenuchten When I look at this information, I do not see any role for the metadata extension. The purpose of the metadata extension is to hold metadata about GeoPackage contents. In your example, the metadata records are the content. From this perspective, the records are features - they have a geometry and properties. If the metadata documents all have the same metadata standard URI, then that URI could be declared as part of the schema or metadata for that feature table.
If this answers your question, then let's close this issue.
@jyutzler, correct this was the aspect i was struggling with myself, if it makes sense to use the metadata table for things outside the geopackage. Thanks for your thoughts, closing this.
In the scope of pygeoapi/ogc-api-records research, we came up with this use case: use a geopackage as a source for a collection of metadata records. In order to be able to define queryables by location, time, title, language, but without the need to dive into the actual metadata content. It would be interesting to define a number of additional fields on the gpkg_metadata extension. The most interesting one would be geometry (to allow spatial queries) and time (start-end or last-modified queries).
Some questions:
An example for such a geopackage is attached to the issue. Looking forward to hear your thoughts.
inspire-protected-sites.gpkg.zip