Logistics
Date: Friday, 9th of November 2018, 10:00-11:30 CET
Connection details:
Agenda
| Time | Agenda item | Document(s) |
|---|
| 10:30-10:35 | Welcome and approval of the agenda |
|
| 10:35-10:45 | Minutes of previous meeting and open action items | |
| 10:45-11:15 | Discussion of examples, glossary items and open issues | |
| 11:15-11:25 | Next steps |
|
| 11:25-11:30 | Open questions & AOB |
|
Attendees
Discussion items & actions
| Item | Notes / Actions |
|---|
| Welcome and approval of the agenda | - The agenda was approved without changes.
|
| Minutes of previous meeting and open action items | - No comments on the minutes of the previous meeting.
|
| Discussion of examples, glossary items and open issues | - Glossary proposals (#29 and #32)
- The notions of profile, extension, simplification and flattening should be clearly defined, in order to avoid misunderstandings
- We should base ourselves on definitions from existing standards, where possible, e.g. from ISO (https://www.iso.org/obp/ui/) and OGC, but also W3C, IETF or other relevant standardisation bodies.
- It is important to state the context, e.g. a "data model profile" may differ from a "standards profile" or an "XML schema profile", and "data model extensions" may differ from "extensions of base standards"
- "Flattening" is only one possible aspect of simplification, but it is often used synonymously. We therefore should have a clear definition of "flat" (vs. "nested" or "complex"), even if we ultimately decide not to use the term.
- The GML Simple Features Profile defines a number of simplification rules on 3 levels (SF-0, -1 and -2) for GML and should be considered as an important source/inspiration for the Simplification Rules GP document.
- Creating flat structures does not necessarily mean simplification, at least when the same information is represented in the flat structure. The Simplification GP document should also discuss possible information loss when representing data in simplified encodings.
- Even in simple encodings, the may be the need to have properties with a cardinality >1, e.g. for classifications.
- Decoding rules (#28)
- How to provide information about recurring values or values that are not maintained in the data set without having to provide them (or a void value) for every object, so that the relevant values can be obtained when decoding the encoded data in a client application?
- If certain restrictions can be applied to all data sets in a theme, it would be possible to have translation rules between a simple and the default data encoding in a theme
- Could mechanisms like default values in XML schema be used for this purpose?
|
| Next steps | - The development of the Good Practice papers on GeoJSON encoding and simplification rules and further discussions in the sub-group should be supported by selecting and developing alternative encodings for example data sets (#31)
- The descriptions of these alternative encoding examples should highlight the use case they support and the approach for GeoJSON and/or the simplification rules used.
- James to propose GeoSciML Light as a simplification example and GeoSciML JSON encodings as a GeoJSON example on Github.
- Ilkka to develop an O&M example
- Michael to investigate possible OF/O&M data sources with the MSFD community at the TG Data meeting in December.
- Pawel to devlop an O&M example based on data for the Air Quality Directive
- Marie to provide example AD data together with a use case
- Heidi to develop an AM example
- JRC to develop examples on AD (ELISE gazetteer work), AU and possibly SD (invasive alien species)
- The examples should include spatial object types that use the complex GeographicalNames type (from GN)
- The examples should be documented on Github and each should have an associated issue for its discussion.
- JRC to propose a structure for documenting examples.
|
| Open questions & AOB | - All members were reminded to inform JRC if they are planning to attend the face-to-face meeting on 17-18 December in Ispra. Invitations will be sent out shortly.
- The contract to support actions 2017.2 and 2017.3 has been awarded to a consortium of WeTransform (mainly working on 2017.2) and Epsilon Italia (mainly working on 2017.3). The kick-off meeting is planned for 16/11.
|
Open Actions
Task report
Looking good, no incomplete tasks.