Page tree

Logistics

Date: Friday, 30th of November 2018, 10:00-11:30 CET

Connection details:

Agenda

TimeAgenda itemDocument(s)
10:00-10:05

Welcome and approval of the agenda


10:05-10:15Minutes of previous meeting and open action items
10:15-11:00Draft ToC for the GeoJSON alternative encoding and encoding template
11:00-11:15

Status of encoding examples & use cases

  • GeoSciML Light / JSON (James)
  • O&M (Ilkka)
  • Borehole-related observations (Clemens, TBC)
  • O&M example based on data for the Air Quality Directive (Pawel)
  • Addresses (Marie)
  • Area Management (Heidi)
  • Addresses, Administrative units, invasive alien species (JRC)
11:15-11:25Preparation of the face-to-face meeting
11:25-11:30

Open questions & AOB

  • Face-to-face meeting

Attendees

  • Sub-group members: Karin Wannemacher (AT), Marie Lambois (FR), Heidi Vanparys (DK), Nathalie Delattre (BE), Tom Ellett von Brasch (NO), Clemens Portele (DE), Ilkka Rinne (FI), Robert Tomas, Michael Lutz, Marco Minghini (JRC)
  • JRC contractors: Stefania Morrone (Epsilon Italia), Thorsten Reitz (WeTransform)

Draft Notes & actions

ItemNotes / Actions
Welcome and approval of the agendaThe agenda was approved without changes.
Minutes of previous meeting and open action itemsThe minutes were approved with a minor change (Clemens Portele will not be able to provide a Borehole example within the time frame of the action). While some work is on-going, most actions on examples are still open.
Draft ToC for the GeoJSON alternative encoding and encoding template
  • The general structure of document should be kept
    • Evaluate later if specific rules e.g. per theme should go to separate documents
    • To comply with the IR article 7, an "encoding rule used to encode spatial data" needs to be added to the document. The rule "shall conform to EN ISO 19118. In particular, it shall specify schema conversion rules for all spatial object types and all attributes and association roles and the output data structure used."
  • Scope:
    • Start out with limited scope in terms of use cases and INSPIRE themes
    • The focus is on making (some) INSPIRE data usable in current client software, not in making an INSPIRE GeoJSON that is then also not fully usable.
    • Many of the D2.7 requirements describe how a data specification needs to be defined, not how an encoding needs to be specified or what rules it needs to fulfill.
  • Normative References:
    • Add the data specifications that this alternate encoding will address.
    • Add JSON schema if the group will use that for ETS definition.
  •  General Encoding rules: no comments
  •  Terminology/Glossary: To be kept as a separate document; to be integrated later.
    • Thorsten to start a stand-alone glossary document, based on the discussions in the group
  •  Conformance classes:
    • The action will focus on a single core conformance class, but prepare for the addition of conformance classes by others who want to extend the specification for other scopes
    • It would be possible to define a conformance class per theme to handle specific rules about how to encode individual type structures
    • CRS support in WFS 3 handled via request parameter - if client requires projected CRS, service should deliver it, assuming that client will be able to properly consume projected data
  • Mapping from the default encoding to the alternate encoding: Wording needs to be changed to describe the requirement better;
  • ETS/ATS definition of encoding:
    • GeoJSON: The JSON schema is defined at https://github.com/geojson/schema.
      • However, it is currently not common to define JSON schemas on top of it, that is for "application schemas". This is consistent with the GeoJSON approach, which has no feature type concept.
      • Also JSON Schema is typically not used for validating JSON files (contrary to XML schema). However, it could well be used in an ETS for a GeoJSON encoding.
    •  There is work-in-progress to reference schemas in other schema languages from OpenAPI ("alternative schemas"), see https://github.com/OAI/OpenAPI-Specification/issues/1532. This is very useful for WFS 3.0, but it is questionable whether OpenAPI should be used for defining test suites for alternative encodings.

  • Thorsten to Include feedback to deliver updated draft of GeoJSON encoding for discussion in 2017.2 meeting in Ispra
Simplification Rules
  • How should the simplification rules be used and connected to the alternate encoding document?
    • Evaluate and select a subset, or...
    • Mix and match simplification rules for a specific use case
  • Thorsten to draft best practice document with 1-2 of the examples included, for discussion at the 2017.2 meeting in Ispra
Status of encoding examples & use cases
  • GeoSciML Light / JSON:  James provided examples on Github
  • O&M: Ilkka will update the current example using the new template
  • O&M example based on data for the Air Quality Directive: no news
  • Addresses: Marie has collected several examples and suggests to include a section on data sources / providers in the template
  • Area Management: Work is on-going
  • Addresses, Administrative units, invasive alien species: no news
Preparation of the face-to-face meeting
  • The meeting should focus on the following points:
    • decide on use cases and optimisation goals (scope)
    • decide on what aspects / themes to include and exclude (scope)
    • discuss criteria for a successful encoding
    • describe examples in more details
  • JRC and contractors to prepare an agenda for the Ispra meeting
Open questions & AOB

Open Actions

Task report

Looking good, no incomplete tasks.