Open heidivanparys opened 3 years ago
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 ).
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 thegml: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
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 tablegml:id
attribute is of typeID
, meaning it must start with a letter, underscore or colon, and it must not occur more than once in a GML instance documentThis situation is different from the GeoJSON alternative encoding rule, where the
gml:id
is mapped to the GeoJSONid
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.
oruuid_
. One option could therefore be to add a columnGML_ID
to each feature and attribute table.What are the advantages and disadvantages? Other options?