Skip to end of metadata
Go to start of metadata

Friday, 31st of August 2018, 10:00-11:30 CEST

Connection details:

Recording:  Streaming, Download


TimeAgenda itemDocument(s)

Welcome and approval of the agenda (JRC)

10:05-10:15Minutes of previous meeting and open action items
10:15-10:45Detailed work plan (JRC)
10:45-11:15Discussion of examples, glossary items and open issues
11:15-11:25Next steps

Open questions & AOB

  • Reglar meeting slot



The minutes summarise the main conclusions and actions from the meeting. Actions are indicated in the minutes using checkboxes and are tracked in the "Open actions" section below.


Peter Parslow (UK); James Passmore (UK); Paul Janssen (NL); Nicolas Hagemann (DE); Clemens Portele (DE); Karin Wannemacher (AT); Pawel Soczewski (PL); Jouni Vuollo (FI); Tom Ellett von Brasch (NO); Nathalie Delattre (BE); Ilkka Rinne (FI); Heidi Vanparys (DK); Robert Tomas (JRC); Michael Lutz (JRC)

Welcome and approval of the agenda

The agenda was approved without changes.

Minutes of previous meeting and open action items

The minutes of the previous meeting were approved without comments.

  • Sub-group members that could not participate in the kick-off meeting should inform Michael Lutz about their planned contribution to the sub-group (see "Round-table of sub-group members").

Detailed work plan

The proposed work plan (see below) was agreed, with the following comments/actions:

  • The schedule is ambitious. It will therefore be important to limit the scope to a small number of examples, themes and use cases.
  • The role of the editor to focus the discussions and work towards achieving consensus will be crucial. There is a risk that the overall work will be delayed if the contract will be launched late.
  • The main role of the editor should be to work on the 2 Good Practice documents. This could include some UML modelling work and including some examples in the text (for illustration). Developing the examples should not be his/her main task.

Date/ meeting

GP: GeoJSON encoding rule

GP: Simplification Rules




  • Collect examples
  • Choose INSPIRE theme(s) and use cases (could be different ones for GeoJSON and Simplification rules)
  • Collect glossary items
  • Detailed workplan



  • Analyse examples à extract GeoJSON encoding & simplification rules to be included in GP
  • Develop GeoJSON/simplified encoding example(s) for chosen theme(s)
  • Launch editor contract



  • 1st draft encoding rules / simplification GP
  • Test and refine examples (using client tools)
  • Prepare status report for the MIG meeting (incl. recommendations for possible continuation)


  • Internal review


Week of

  • Discuss open issues


  • 2nd draft
  • Launch MIG/MS review (until 4-Jan)



  • Discuss review comments


  • Final draft
  • Launch GP procedure
  • Organise GP webinar

Discussion of examples, glossary items and open issues

  • An initial glossary page is available at This page will be updated during the lifetime of the group.
  • The GeoJSON and simplification examples were presented. It was agreed to further analyse them to identify the simplification approaches and encoding rules used. Where possible, we should focus on examples that can be mapped to INSPIRE data models.
    • Michael LUTZ Add a section on the underlying conceptual model to the issue templates.
    • All to further analyse and discuss the proposed examples.
  • It was agreed not to discuss the relationship of alternative encodings (in particular GeoJSON) and download services.
  • On the issue of the default GeoJSON CRS (CRS84) (see, it was agreed that ideally, geometries should be expressed using the default geometry property and in CRS84, because other solutions (e.g. based on "prior arrangements" - see section 4 in may be misinterpreted by clients. Other approaches discussed in the issue should still be tested for the level of support in existing client tools.
  • Overall, the following questions should be discussed when analysing the examples further:
    • Should the simplification rules / GeoJSON encoding rule include profiling (i.e. providing only sub-sets of the INSPIRE properties)?

    • Should the simplification rules include extensions?

    • Should we focus on generic rules (for all/most themes) or specific ones (for a small number of themes)? Which themes/use cases should be used to prototype and test the simplification rules / GeoJSON encoding rule?

    • Should we include simplification based on UML implementation models?

    • Should the GeoJSON encoding rule include simplification rules?

    • Michael LUTZ Add these questions as Github issues for further discussion in the sub-group.

Open questions & AOB

  • The next virtual meetings will be on Fridays 10:00-11:30 CE(S)T on 28/9, 26/10 and 11/1/2019.

Open Actions

DescriptionDue dateAssigneeTask appears on
  • WE/TR: Plan communication towards Community
2017.2 meeting #6 2018-12-17/18
  • JRC/ML: Determine how to reconcile NilReason Model Transformation Rule with the requirements in the IR --> "You shall provide a value of ... or document ..."
2017.2 meeting #6 2018-12-17/18
  • Thorsten to start a stand-alone glossary document, based on the discussions in the group
2017.2 meeting #5 2018-11-30
  • Michael to investigate possible OF/O&M data sources with the MSFD community at the TG Data meeting in December.
2017.2 meeting #4 2018-11-09
  • Pawel to devlop an O&M example based on data for the Air Quality Directive
2017.2 meeting #4 2018-11-09