12:00 – 13:00

Arrival & buffet lunch

13:00 – 13:15

Welcome and approval of the agenda (JRC)

13:15 – 15:00

Scoping of the GeoJSON Alternative Encoding – INSPIRE themes, INSPIRE requirements (WeTransform)

• Presentation of 3 examples (Sub-group members, 10 mins each)
• Specific Technical problems to be solved and their priority
• Discussion of potential encoding rules based on GeoJSON examples

15:00 – 15:30

Coffee break

15:30 – 17:30

Discussion of open issues (GeoJSON) (all)

20:00

Social dinner (offered by JRC)

Tuesday, 18 September 2018

09:00 – 10:30

Good Practice document on Simplification Rules – Presentation Current Draft (WeTransform)

Discussion of open issues (simplification rules) (all)

10:30 – 11:00

Coffee break

11:00 – 11:30

Good Practice document on GeoJSON – Presentation Current Draft (WeTransform)

11:30 – 12:30

Discussion of open issues (GeoJSON) (all)

12:30 – 14:00

Lunch break

14:00 – 15:30

Presentation of current draft of work on 2017.3

Discussion of data usability testing activities (all)

15:30 – 16:00

Coffee break

16:00 – 16:30

Wrap-up and next steps (JRC, WeTransform)

Welcome and approval of the agenda

The agenda has been approved.

Scoping of the GeoJSON Alternative Encoding

To scope the JSON encoding, the group discussed whether to start with specific examples or whether to start with broad, generally applicable rules.

General requirements and rules:

• Work should be directly usable, so if it requires other parts that are not specified there is less value
• If we only change the encoding, the main issues will still remain, so we need to look at these things (simplification + alternative encoding).
• How is an alternative encoding developed and documented?
• Maintain lifecycle information of INSPIRE features
• Themes can be from Annex I, II and III
• Make implementation of INSPIRE easier
• Do not require special software, often complexity is the issue, not so much the encoding
• This group will NOT discuss the conceptual models.

Alternative/Additional Encoding?

One major question is whether this encoding can be an alternative to providing INSPIRE GML for the themes in scope, or whether it is always to be provided in addition. If it is an additional encoding, do providers need to go via the default encoding or can they deliver the alternative encoding (with a simpler model) directly? Key points from the discussion:

• alternative only if there is no information loss
• "This encoding complies to the IR if your source data only has..."
• Clarification must go to the terminology or into final report ("DS have to potentially uploaded to clarify relationship"). Will there still be a default encoding?
• Relation between the alternative encoding and the data specification
• Relation from Data specification to Alternative Encoding provided in 9.3.x

Conclusion:

Within this work, we will define an alternative encoding that can be used instead of the default encoding for simple data, where there is no information loss.

Examples & Themes

The decision was made to start from concrete examples and to apply these to specific themes. Members of the group presented various examples:

• GN: +++  --
  • Is used in a lot of places in other themes
  • If we define rules for GN, would they be applicable to AD as well?
• AD: +++++++
  • Address Size issue, e.g. for gazetteer usage as in the French case?
  • Very valuable, but currently hard to use
  • Many use cases, extensively used also by non-GIS communities
  • Good template case to develop generic rules as well as specific rules
  • A working encoding is achievable in this group
  • In the JRC example: very long names (how to cut), simplifications on the GN, no lifecycle, removed id
  • Issue with presence of multiple geometries: GeoJSON doesn't allow semantic for geometries, you have to provide an extra property which tells you the semantics.
•  O&M: ++++++++
  • used by several themes, important environmental use case
  • Can be extended to more challenging aspects such as profiles and 3D geometries
  • Use EMF as context theme for O&M; makes this data more accessible to environmental user communities +++
  • EMF would include references to legal resources
  • GE - Boreholes as potential second context
  • Add Atmospheric Conditions as third context
  • NOTE: there are lots of efforts on how meteorological info looks like on the web (e.g. as JSON) already
  • NOTE: For sensorthings, there is a JSON encoding proposal; Feedback to OGC should be provided
• TN: +++++
  • Properties attached to Networks
  • Support for visualisation, some themes such as TN are currently not suited for that

The group then decided whether to include these in the scope, or not (+ / - on the items above).

Conclusion:

The draft Alternative Encoding encompasses the INSIRE themes Addresses (including GeographicalName properties) and Environmental Monitoring Facilities (including O&M properties).

Use Cases

The group also discussed whether to focus on specific use cases such as web applications for this encoding.

• Data sharing / exchange / transfer of vector information
  • towards non-domain experts
  • towards developers who do not know much about geo standards
  • towards GIS users (desktop, mobile, web)
  • explorative work with transient features (from client object lifecycle perspective)
  • Consume the data in the most commonly used clients +++
  • Load and visualise the data in common GIS easily +++
  • Think in terms of delivery via APIs
• At OS, requests for JSON are mostly from non-GIS people
• Select relevant parts from JSON for their own analytics and tools
• Usage of environmental data in environmental and scientific communities
  • Make it easy for DG ENV officer to analyse / visualise data
• Change detection
• Quality Assurance/Validation: Would have been done before, GeoJSON is a publishing format
• Each theme has a list of specific (business) use cases, need to investigate these as a validation step

Conclusion:

The draft Alternative Encoding shall be optimized for the following use cases: Viewing and analysing in mainstream GIS clients. This means that no generally unsupported features such as JSON References are to be used.

Specific technical issues

The encoding should also resolve specific technical issues that have been problematic when using the default encoding.

• See findings in https://github.com/INSPIRE-MIF/2017.2/issues/48
• For ArcGIS: https://github.com/INSPIRE-MIF/2017.2/issues/18
• Abstract geometry types for an object (mixed geometry types in a FeatureCollection)
• Be able to display types on map, e.g. date/time, xlinks, coded values and codelists ...

Model Simplification Rules

The initial draft of the best practice paper simply collects those rules found in the examples. After discussion, the group decided to change the it from a catalogue of examples to a list of patterns / best practices. The current template used for each pattern was discussed and should be amended as follows:

• reference where the pattern/rule has been used
• have at least those rules needed for the themes
• Add UML class diagram to the description of each rule
  • Have both UML models (Conceptual Model -> Implementation Model)
• When should the rule be used, when should it not be used?
• Under which conditions there is no information loss?
• As far as possible, rules should be independent from the encoding
• Flag rules specific to an encoding, e.g. Geometry in GeoJSON → specific rules can go to GeoJSON doc?
• Examples as primary driver of the how-to; should examples use a homogeneous encoding? Yes.

Specific Rules under discussion

• How to deal with the same local names being used by members from different namespaces
• Voidable properties:
  • Make a simplification rule that takes any property that has the stereotype <<voidable>> and makes it optional (0..)
  • result: nilReason dropped, not bijective, change in semantics (empty/nil values)
  • corresponding instance transformation rule:
    • Omit the member if its value is empty
    • make it an optional rule to drop unpopulated members

Usability Testing

Conclusions

• Do not focus on producer/server side
• Concentrate on client-side issues        

Follow-Up Actions

• WE/TR: Timeline for next deliveries

• • 2nd draft for 29.01.2019 (originally scheduled 15.01.2019), includes EMF (which includes O&M) and AD (which uses GN)
  • Meeting to consolidate open issues around end of February/earliest March
  • Final draft for 15.03.2019 -> will be sent to MiG

• WE/TR: Clarify base types usage / simplification
  • GN, Identifiers, Citations
• WE/TR: Plan communication towards Community
• BRGM/Marie: FR BRGM has Borehole INSPIRE GML example using O&M - Marie will ask/provide links
• JRC/ML: Determine how to reconcile NilReason Model Transformation Rule with the requirements in the IR --> "You shall provide a value of ... or document ..."