use gpkg as a light weight catalogue storage

[pvgenuchten]

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:

• Does the spec allow to create additional records in gpkg_metadata, without any linkage to other gpkg tables.
• Do you agree that having a geometry and time field makes sense on gpkg metadata
• If a geometry column would be added, references to that geometry column would need to be added to geopackage_geometry_columns?

An example for such a geopackage is attached to the issue. Looking forward to hear your thoughts.

inspire-protected-sites.gpkg.zip

[fjlopez]

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)?

[tomkralidis]

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.).

[fjlopez]

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.

[pvgenuchten]

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.

[jyutzler]

@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.

[pvgenuchten]

@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.