Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • The work plan should also include testing of the resulting data with different client applications (desktop, web) and how to serve the data (in alternative encodings) through download services.
  • There should be a close link to action 2017.3 on improved client support for INSPIRE data.
  • Simplification in the mapping from the conceptual model to the target data structure should not only include flattening of complext structures, but also specific (pre-defined) mappings for certain complex types (e.g. GeographicalName) and/or profiling, e.g. selecting only certain properties and types that are relevant for a specific purpose (e.g. addresses for postal delivery).
  • Simplification may need to be done differently depending on the theme and/or purpose. It may not (always) be possible to do simplification only by applying automatic rules, but can require as a first step the mapping from the conceptual to a (simplified) implementation model (see also the minutes from the Paris meeting in 2014).
  • There are issues with existing simplification/flattening procedures, and these are carried out using different combinations of (homegrown) rules. It is therefore important to come up with a common set of rules (and maybe combinations of rules).
  • Additional resources / background reading for this action include:
  • Alternatives encoding might fulfil all (legal) requirements specified for INSPIRE, or also only some of them. In the former case, they could be used as the only encoding to meet one's INSPIRE obligations, in the former case only in addition to another, fullt INSPIRE cocompliant encoding. Such possible limitations should be clearly stated in the encoding, but also when proposing it for endorsement by the MIG.

The participants indicated their planned contributions to the the tasks of the sub-group, as follows: