Skip to content

Latest commit

 

History

History
37 lines (25 loc) · 2.94 KB

encoding-gp-procedure.md

File metadata and controls

37 lines (25 loc) · 2.94 KB
Raw

Procedure for alternative encodings of INSPIRE data (DRAFT)

Scope

This procedure describes the approach to be followed for encoding INSPIRE data in accordance with the Implementing Rules on interoperability of spatial data sets and services (IR ISDSS) through the use of alternative encodings, i.e. different from the default encoding - XML, but at the same time meeting all the legally-binding obligations of the IR ISDSS.

Open Questions: are (i) additional encodings and (ii) extended INSPIRE models in scope?

Approach

Principles

Adhereing to the following principles will facilitate the encoding of data under INSPIRE.

  • A stepwise approach is envisioned for encoding the data. The steps to be followed are provided below.
  • Should there be different proposals for the encoding of data for the same data model or data theme, the changes are discussed (i) between the proposers, ideally on GitHub, and if needed (ii) within the context of the temporary sub-group 2.3.1 'Governance of INSPIRE Artefacts'.

Envisioned Steps

Step 1. Data encoding

Data should be encoded through the alternative encoding (e.g. GPKG or GeoJSON) by following the provisions of the INSPIRE UML models and/or Application schemas. When encoding the data the following should be consulted:

  1. Model transformation rules that are encoding-agnostic, and
  2. Encoding-specific rules developed per each data encoding (e.g. for GeoJSON, GeoPackage, etc.)

Step 2. Describe the mapping to the default encoding

Once the data instances prepared in accordance with Step 1. are generated, mapping to the default INSPIRE encoding (XML) should be made available together with an example excerpt of a dataset on GitHub through at least one of the following means:

  1. Executable transformation script, incl. software-specific approaches that can be replicated.
  2. INSPIRE Matching tables. Ideally, this should be done on the level of physical/format level, e.g. through mapping of xpaths versus jsonpaths, e.g.:
GML GeoJSON
Ad:Address/inspireId/localId $.properties.inspireId_localId
Ad:Address/inspireId/namespace $.properties.inspireId_namespace
... ...

Step 3. Data validation

Confirming the approach through the INSPIRE reference validator can be achieved through deriving and validating GML instances based on the mapping performed in Step 2. The GML instances and the test report from the INSPIRE reference validator (html) should be made available.