Meeting #2454

Proposals for discussion topics for MIG-T meetings

Added by Michael Lutz almost 2 years ago. Updated over 1 year ago.

Status:NewStart date:19 Jun 2015
Priority:NormalDue date:
Assignee:Michael Lutz% Done:

0%

Category:-
Target version:-

Description

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, ...).

History

#1 Updated by Alex Ramage almost 2 years ago

Michael,

We need to remind MIWP ownerfs to update their status prior to the MIG-T meetings.

Alex R

#2 Updated by Michael Lutz almost 2 years 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.

I have used two errors pointed out recently by DG ENV on the data specifications on EF and SU as examples to test a possible implementation for such a corrigendum page using the Redmine issue tracker.

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.

#3 Updated by Marc Leobet almost 2 years ago

Thanks Michael for that good proposition.

We think it would be a pragmatic way to warn developpers without waiting a long time (specially for IR).

#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):

Should they be logged as issues in this platform (Redmine)?

Jordi

#5 Updated by Darja Lihteneger over 1 year ago

Dear all,

 

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.

 

Kind regards,

Darja

 

#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.

#7 Updated by Christian Ansorge over 1 year ago

@Christina: I am preparing the agenda and discussion points for tomorrows MIG-T webconf. As you mentioned that you cannot attend tomorrow I would suggest to keep this issue for the next MIG-T (in October). Is this ok, or is it that urgent?

#8 Updated by Christina Wasström over 1 year ago

No, Christian, it´s not urgent. We can keep it for the next meeting.

#9 Updated by Christina Wasström over 1 year ago

Dear all,

I would like to discuss how to proseed with the action "Synchronize och verify changes done in Update of TG Metadata with other TGs" at our meeting in Rome (Task #2408).

#10 Updated by Michael Lutz over 1 year ago

In one of the upcoming virtual MIG-T meetings, the ARE3NA team would like present the work planned on AAA in 2016 and discuss possible involvement of the MIG-T in the planned work. 

Also available in: Atom PDF