Relation between GPKG integer primary keys and gml:id's

[heidivanparys]

This is a general comment, also applicable for the European Noise Directive UML-to-GeoPackage Encoding Rule.

What is the relation between the GeoPackage primary keys and gml:id? How should the gml:id attribute be filled out based on GeoPackage data?

According to the proposed approach for alternative encodings of INSPIRE data, a mapping to the default INSPIRE encoding (XML) should be made available.

The challenge here is that

• GeoPackage features/attributes tables have an INTEGER PRIMARY KEY, see also https://www.geopackage.org/spec130/#r29 and https://www.geopackage.org/spec130/#r119, so an integer key that uniquely identifies the row within its table
• the gml:id attribute is of type ID, meaning it must start with a letter, underscore or colon, and it must not occur more than once in a GML instance document

This situation is different from the GeoJSON alternative encoding rule, where the gml:id is mapped to the GeoJSON id property, being a JSON string or number.

So how do we ensure that compliant INSPIRE GML encoded data can be derived problem-free from a GeoPackage file?

Many data providers already have a strategy for constructing valid gml:id's, some of them following the approach described in https://www.wetransform.to/news/2018/02/12/best-practices-for-inspire-ids/, and others taking an identifier (e.g. integer, UUID) from the dataset and prefixing it with e.g. id. or uuid_. One option could therefore be to add a column GML_ID to each feature and attribute table.

What are the advantages and disadvantages? Other options?

[thorsten-reitz]

Another option might be to derive the gml:id from the inspireId localId, where it is present. We usually try to keep these consistent anyway, and the inspireId is part of most tables in the END schemas (Exception: MajorAirportSource; that type is not derived from an INSPIRe feature type ).