Logistics
Date: Monday/Tuesday, 17-18th of December 2018
Location: Rooms Leonardo/Michelangelo, building 26a, Joint Research Centre, Ispra, Italy
Agenda
Time | Agenda item | Document(s) |
---|---|---|
Monday, 17 December 2018 | ||
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)
| |
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) |
Attendees
- Sub-group members:
JRC contractors: Stefania Morrone (Epsilon Italia), Thorsten Reitz (WeTransform)
Draft Notes & actions
Item | Notes / Actions |
---|---|
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:
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:
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 & ThemesThe decision was made to start from concrete examples and to apply these to specific themes. Members of the group presented various examples:
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 CasesThe group also discussed whether to focus on specific use cases such as web applications for this encoding.
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 issuesThe encoding should also resolve specific technical issues that have been problematic when using the default encoding.
|
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:
Specific Rules under discussion
|
Usability Testing | Conclusions
|
Follow-Up Actions |
|
Annex 1: Annotated Examples
Addresses IGN-F 1
{
"type": "FeatureCollection",
"crs": {
"type": "name",
"properties": {
"name": "urn:ogc:def:crs:EPSG::4258"
}
},
"features": [
{
"type": "Feature",
"id": "AD_ADDRESS_FR_IGNF_BDUniGE_Adresses_MET_ADRNIVX_0000000283326117", // added; might add recommendation on patterns to use; should use same pattern of generation as for GML encoding if that is also delivered
// Have the ID for filtering by ID in a download service --> TODO Test this
// Where there is a 1:1 relationship before and after model transformation, we should use the value that would be used to populate gml:id
// do not make a recommendation for cases outside the 1:1 scope
"properties": {
"gml_id": "AD_ADDRESS_FR_IGNF_BDUniGE_Adresses_MET_ADRNIVX_0000000283326117", // should be removed, there is no GML in JSON; but need to add id to feature
"inspireId_localId": "ADRNIVX_0000000283326117", // flattening like this is fine
"inspireId_namespace": "FR_IGNF_BDUniGE_Adresses_MET", // clarify whether to use . or _ or - to indicate different semantics, e.g. as in OCL; clarify whether to keep the typename in the flattened property name; where might this lead to issues?
// Use the common flattening rule for the InspireIdentifier
"position_specification": "http://inspire.ec.europa.eu/codelist/GeometrySpecificationValue/parcel", // how would we add readable text (titles)?
"position_method": "http://inspire.ec.europa.eu/codelist/GeometryMethodValue/fromFeature",
"position_default": true, // this attr is only useful if we have more than 1 point
"locator_designator": [
"698", // Currently two arrays need to be parsed together, should rather group by locator_type (e.g. locator_1 + locator_1_type, locator_addressNumber)
"A"
// Pattern: Type + Codelist promotion
// Pattern: Type promotion
// Pattern: Codelist value promotion
// Pattern: Fieldname + Type promotion
],
"locator_type": [
"http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumber",
"http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumberExtension"
],
"level": "http://inspire.ec.europa.eu/codelist/LocatorLevelValue/siteLevel",
"component": [ // Do we support links to other objects or not? If so, use real links (resolvable?) For this case, rather put them inline instead of referencing them. Do we use specific property names (note - ADMINUNITNAME occurs n times) instead of an array of components? To name those, it might make sense to look at other relevant standardization efforts. Soft typing to hard typing.
"AD_ADMINUNITNAME_FR_IGNF_BDUniGE_Adresses_MET_codeINSEE_FR",
"AD_ADMINUNITNAME_FR_IGNF_BDUniGE_Adresses_MET_codeINSEE_24309",
"AD_ADDRESSAREANAME_FR_IGNF_BDUniGE_Adresses_MET_24309_LABATUT",
"AD_POSTALDESCRIPTOR_FR_IGNF_BDUniGE_Adresses_MET_codepostal_24190"
]
},
"geometry": {
"type": "Point",
"coordinates": [
0.460372,
45.078589
]
}
}
]
}
Addresses IGN-F 2
{
"type": "FeatureCollection",
"crs": {
"type": "name",
"properties": {
"name": "urn:ogc:def:crs:EPSG::4258"
}
},
"features": [
{
"type": "Feature",
"properties": {
"gml_id": "AD_ADDRESS_FR_IGNF_BDUniGE_Adresses_MET_ADRNIVX_0000000283326117",
"inspireId_localId": "ADRNIVX_0000000283326117",
"inspireId_namespace": "FR_IGNF_BDUniGE_Adresses_MET",
"position_specification": "http://inspire.ec.europa.eu/codelist/GeometrySpecificationValue/parcel",
"position_method": "http://inspire.ec.europa.eu/codelist/GeometryMethodValue/fromFeature",
"position_default": true,
"locator_designator": [
"698",
"A"
],
"locator_type": [
"http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumber",
"http://inspire.ec.europa.eu/codelist/LocatorDesignatorTypeValue/addressNumberExtension"
],
"level": "http://inspire.ec.europa.eu/codelist/LocatorLevelValue/siteLevel",
"component": [ // In-Place encoding will be a case by case decision; In this case it makes sense for usability; might want to get rid of components and instead directly use fields like adminUnitName_2nd, adminUnitName_3rd, ...; If there is a short list of soft types, it could be transformed/promoted to a set of properties which are hard types each and which indicate specific types by their name (derived from the codelist value?)
// If we use a reference instead of in-place encoding, display value/name and de-referencable URI; Does a certain style of reference indicate the (media) type of the linked resource? Do we use $ref JSON references? We could also look at JSON-LD when including a object linking mechanism into the encoding.
// --> Use name/label and simple, resolvable link
// 3 types of "links" - between objects, to codelists, to external resources (e.g. in citations), Identifiers/URIs
// "nativeness:ref"/nativeness_link, ...Id, ...
{
"gml_id": "AD_ADMINUNITNAME_FR_IGNF_BDUniGE_Adresses_MET_codeINSEE_24309",
"inspireId_localId": "codeINSEE_24309",
"inspireId_namespace": "FR_IGNF_BDUniGE_Adresses_MET",
"status": "http://inspire.ec.europa.eu/codelist/StatusValue/current",
"name_language": "fra",
"name_nativeness": "http://inspire.ec.europa.eu/codelist/NativenessValue/endonym",
"name_nameStatus": "http://inspire.ec.europa.eu/codelist/NameStatusValue/official",
"name_sourceOfName": "BD TOPO®",
"name_spelling_text": "Neuvic", // strip down GN to just the name text when the data sets in monolingual? For multiple languages, how to indicate which name is in which language if it it would be a simple array or multiple members? In XML, additional info can be put into attributes on the tag (e.g. LocalisedCharacterString?)
// always provide "default/official" name in "first" national language? Additional info and names can go into more fields?
// diff names by language code in property name? name_en? No, provide a flattened list (name_1) with the additional info in extra members (name_1_status, name_1_lang, name_1_...)
// make it a content negotiation issue between client/service - if you request one language the names will be in that language
"name_spelling_script": "Latn"
},
{
"gml_id": "AD_ADDRESSAREANAME_FR_IGNF_BDUniGE_Adresses_MET_24309_LABATUT",
"inspireId_localId": "24309_LABATUT",
"inspireId_namespace": "FR_IGNF_BDUniGE_Adresses_MET",
"status": "http://inspire.ec.europa.eu/codelist/StatusValue/current",
"name_language": "fra",
"name_nativeness": "http://inspire.ec.europa.eu/codelist/NativenessValue/endonym",
"name_nameStatus": "http://inspire.ec.europa.eu/codelist/NameStatusValue/official",
"name_sourceOfName": "BD ADRESSE®",
"name_spelling_text": "Labatut",
"name_spelling_script": "Latn"
}
]
},
"geometry": {
"type": "Point",
"coordinates": [
0.460372,
45.078589
]
}
}
]
}
Open Actions
Task report
Looking good, no incomplete tasks.