Overview

The action defined alternative encoding rules (mainly for the purpose of viewing/analysis in mainstream GIS systems) for a number of selected application schemas and a template and procedure for proposing and endorsing additional encoding rules in the future.

Specifically, it carried out the following tasks:

1. Develop concrete proposals for alternative encodings
   1. In collaboration with thematic communities (through the Thematic Clusters platform and MIWP-14 sub-group), collect proposals for alternative encodings. These can be based on existing examples and/or on specific use cases and requirements. The proposals can be cross-cutting (i.e. cover all INSPIRE themes) or specific for one or several related themes.
   2. In agreement with the MIG-T, prioritise the collected examples and select a small number of proposals, for which alternative encodings will be developed by the action.
   3. For the selected examples, develop encoding rules that explain how (and/or under which conditions) the proposed encoding meets the requirements of the IRs. The action should also consider the potential loss of information for certain encodings and discuss whether such "lossy" encodings are meeting the IR requirements.
2. Define a template and procedure for proposing and endorsing additional encoding rules
   1. Based on the work on (1a), elaborate a template for proposals for additional encoding rules. The template should cover the actual encoding rule (including possible approaches for explicitly documenting mappings in UML), but also target use cases, expected benefits, known limitations and tools for conformity testing & validation.
   2. Develop a procedure for how additional encoding rules can be proposed using the template and checked/endorsed by the MIG, and how these are referred to from the existing data specification TGs.
   3. Develop a proposal for the update or maintenance of endorsed encoding rules.
   4. Create a repository of additional encoding rules that have been endorsed by the MIG.
   5. Develop a proposal for documenting the used encoding rules in data set/service metadata.
3. Give recommendations on an update of D2.7 Encoding Guidelines (for future work)

The full action mandate is attached: MIWP-2017.2_Alternative_encodings_Action_mandate_endorsed.pdf

Results

The outputs of the Action are made available on GitHub. 

The results include the following:

• A glossary for alternative encodings.
• Generic model transformation methods that reduce complexity in encoded INSPIRE data.
• Definition of an INSPIRE UML-to-GeoJSON encoding rule.
• Theme-specific transformation rules for Addresses and Environmental Monitoring Facilities.
• Sample GeoJSON data instances following the encoding rule.
• A template for proposal of additional encoding rules for INSPIRE data.
• Recommendations and lessons learnt for other alternative or additional encoding rules.

Meetings

Regular virtual meetings took place on Fridays from 10:00-11:30 CE(S)T

• Webinar "INSPIRE good practices – Alternative Encodings" 2019-05-07 15:00-16:30
• 2017.2 meeting #7 2019-03-29
• 2017.2 meeting #6 2018-12-17/18 (face-to-face, Ispra)
• 2017.2 meeting #5 2018-11-30
• 2017.2 meeting #4 2018-11-09
• 2017.2 meeting #3 2018-09-28
• 2017.2 meeting #2 2018-08-31
• 2017.2 Kick-off meeting 2018-07-04

Background & context

The current data specification TGs define (complex) xml schemas based on GML as the default encoding for all INSPIRE spatial data themes. Many existing (web and desktop) applications and tools have difficulties in consuming and/or fully making use of data shared according to these schemas.

The INSPIRE xml schemas are complex, because they are generated automatically from the conceptual UML model (according to the normative UML-to-GML encoding rules described in the GML standard and INSPIRE Technical Guidelines D2.7 Encoding Guidelines) and therefore reflect all the complex structures present in the conceptual model. In contrast, most existing clients, including the popular GDAL/OGR open source library (that is underlying most OS and proprietary client solutions) consumes and writes flat data structures, where e.g. each attribute can only have at most one value and attributes can have only simple types (e.g. integer, string, boolean) and not complex ones. This means that, while INSPIRE data encoded according to the current schemas can be downloaded and viewed, simple use (visualisation, simple joins, visual overlays, spatial search, …) is difficult in standard GIS clients.

One way to address this gap is to create alternative encodings for basic data exchange and direct visualisation in standard GI tool (another one is to encourage better support for consuming INSPIRE data by vendors – this solution was investigated in Action 2017.3).

Proposals already exist for alternative encodings, mainly for simplified XML schemas (this approach is often also referred to as "flattening" of the existing xml schemas and has been applied e.g. in the ELF project or the example presented by DK in the 2nd 2016.1 meeting and is already implemented in tools, e.g. ShapeChange), but also for RDF vocabularies or ESRI geodatabase structures. Alternative encodings could also be based on other standards such as JSON or GeoPackage.

According to Art. 7 of the IRs on data interoperability, alternative encodings can be used as long as an encoding rule is publicly available that specifies schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used. Such an encoding rule would need to include cross-cutting aspects (e.g. how to flatten recurring complex structures such as geographical names) as well as theme-specific aspects.

Organisational set-up

The work was carried out by a temporary MIG sub-group, coordinated by JRC and supported by a contractor. The call for participation is available here.

The temporary sub-group carried out its work in several meetings during 2018 and 2019 and via electronic exchange. Meeting minutes are kept in this wiki space. Discussions, examples and the Good Practice documents are held on Github.