Proposals for discussion topics for MIG-T meetings
|Status:||New||Start date:||19 Jun 2015|
|Assignee:||Michael Lutz||% Done:|
Please comment on this issue to propose topics that you would like to discuss at one of the upcoming MIG-T meetings.
Be as precise as possible when describing the issue and include background material (e.g. presentations, documents, ...) and/or proposed solutions where possible.
Please also describe what should be the outcome of the discussion (e.g. a decision, a new MIWP action, an action on the MIG-T, MIG-P, DG ENV, JRC, ...).
#2 Updated by Michael Lutz over 1 year ago
I would like to present in one of the next meetings a proposal for capturing corrigenda for TGs (and potentially IRs).
In order not to have to update all documents and repositories for any such change, we have discussed in the past in the MIG to set up corrigendum pages, where we can collect "known errors" that will be implemented in the next release of the affected documents and repositories.
The issues are logged at #2464 and #2473. The issues can be used to indicate status (new --> [feedback] --> endorsed/rejected --> closed] of a corrigendum and to document when e.g. one of the affected documents/repositories has been updated.
We can also create custom queries (like this one available as HTML or ATOM) to list all corrigenda to a specific document.
#4 Updated by Jordi Escriu over 1 year ago
At the moment INSPIRE Thematic Cluster #3 has identified, discussed and consolidated the following two proposals (published in the TC collaboration platform) to be further discussed (to be endorsed / redefined / rejected) by MIG-T (MIWP-14):
Encoding of the spatial extent of coverages - https://themes.jrc.ec.europa.eu/pages/view/37857/encoding-of-the-spatial-extent-of-coverages
Clarification of the Transverse Mercator projections allowed in INSPIRE - https://themes.jrc.ec.europa.eu/pages/view/38029/clarification-about-the-transverse-mercator-projections-allowed-in-inspire
Should they be logged as issues in this platform (Redmine)?
#5 Updated by Darja Lihteneger over 1 year ago
The EEA project noticed some misalignments in the extensibility of the code lists in INSPIRE Environmental monitoring facilities (INSPIRE EF) between different INSPIRE sources. The question is posted in the INSPIRE Thematic Cluster at: https://themes.jrc.ec.europa.eu/discussion/view/34147/extensibility-of-code-lists-in-inspire-ef
The main difference is that the preview of the UML data models published on INSPIRE web site doesn’t reflect the information from the Implementing Rules or Technical Guidelines. It is helpful to use this preview and it is difficult to re-check it with the UML data models and feature catalogue in the Technical Guidelines.
What will be the procedure and means (INSPIRE Thematic Clusters or MIG-T platform) to collect such misalignments and correct them?
Could indication of the priority of the INSPIRE material to use/follow in the implementation be useful, for example: 1) INSPIRE Directive, 2) Implementing Rules, 3) Technical Guidelines (with UML models and feature catalogue), 4) INSPIRE registry, 5) UML data models on INSPIRE web-site in EA format, 6) HTML preview of UML data models on INSPIRE web-site 7) XML schemas?
I understand that it is very difficult to maintain all those resource in synchronized way, but this would be necessary to support the implementation.
#6 Updated by Christina Wasström over 1 year ago
From the discussions in the thematic cluster for Earth Science a best practice regarding name of layar has been proposed. When there is a need to divide a layer the define layer name will be used for grouping other layers.
“For GE.GeologicUnit there two recommended styles, for lithology and age. However, in a service, layer names have to be unique so should we use GE.GeologicUnit.Lithology and GE.GeologicUnit.AgeOfRocks as the layer names so that each layer can have a single default style? We are not sure if changing the layer name in INSPIRE is permissible or if the layer names are mandatory. If they are mandatory then either we would need to have distinct services for lithology and age or we would have to provide two styles for the GE.GeologicUnit layer and leave it to the client to state which style it wishes to use”
The question is if there is a need to document this best practice in TG and also if this situation is relevant for other themes.