Closed JohannaOtt closed 2 years ago
sMorrone
commented
2 years ago @JohannaOtt definition of AerodromeNode as TransportPoint (instead of TransportNode) should become a change proposal in the https://github.com/INSPIRE-MIF/application-schemas repository, where it can be tackled according to the procedure for the governance of change proposals to INSPIRE artefacts.
JohannaOtt
commented
2 years ago @fabiovinci As you originally came up with the proposed changes: do you want to create the change proposal in the application-schemas repository?
fabiovinci
commented
2 years ago Dear @JohannaOtt,
since you are proposing changes also to other feature types and you are the proposer of the change, I would kindly ask you to open the issue in the application-schemas repository, so that the procedure for a possible endorsement can start. I could then support you later in creating the relevant pull request, should the proposal be endorsed.
JohannaOtt
commented
2 years ago I created https://github.com/INSPIRE-MIF/application-schemas/issues/61 for it
sMorrone
commented
2 years ago Dear @JohannaOtt could we consider this issue in the generic helpdesk closed? Your proposal will now follow the correct iter in the application schema repository.
JohannaOtt
commented
2 years ago Yes, ok with me.
This subject was discussed in this thread in the INSPIRE Forum back in the days but did not lead to any conclusion. Happy for any input.
Content:
"When validating TN-Air data containing AerodromeNodes, the ETF validator detects an error mentioning that they should be connected to a TransportLink. This is correct as an AerodromeNode is a TransportNode and is therefore not allowed to exist as free node. (IR Requirement - Annex II, Section 7.9.3 - Theme-specific Requirements – Geometry representation: 2. In a Transport Networks data set which contains nodes, these nodes shall only be present where Transport Links connect or end.) When looking at Figure 40 of the Data Specification, it looks like AerodromeNodes are allowed to exist at different places than where TransportLinks connect or end. Fabio Vinci proposes in this issue https://github.com/inspire-eu-validation/community/issues/113 to define AerodromeNode as TransportPoint (instead of TransportNode) in order to exclude it from the Geometry representation restrictions. Are there already any plans to do so or how do you handle AerodromeNodes in your data?"
"We confirm, that we have the same issue. Until now we are denying the result from the validator until a solution will be issued. Furthermore it is important to know, that the same problem will arise with designated points used in Free Route Airspace as to the fact there are no more routes used and published and the aircraft is directed from point to point at the availability of airspace and is a decision of the air traffic controller."
"Some more information on three different FeatureTypes inheriting from TransportNode that cannot be connected to links for the data of the Deutsche Flugsicherung. I can confirm the issue concerning DesignatedPoints that Klaus reported. It will also occur for the data of Deutsche Flugsicherung where the implementation of Free Route Airspace has already started and will increase gradually within the next years. This means AirRouteLink objects will not exist anymore between all of them and DesignatedPoints can therefore exist at the end/start of AirRouteLink objects as well as without connection to AirRouteLink objects as freeNodes. Concerning AerodromeNode objects, I think all information is available in my original post. As Figure 40 of the Data Specification is showing, there is no TransportLink objecs connected to them (as NetworkConnections are directly inheriting from NetworkElemenets and therefore are no TransportLinks). RunwayCentrelinePoint objects are supposed to be located at the end/beginning of InstrumentApproachProcedure/StandardInstrumentDeparture objects. Both of these (as well as StandardInstrumentArrival objects) don't exist in the database of Deutsche Flugsicherung. Therefore, RunwayCentrelinePoint objects will also occur as freeNodes in the German data. As suggested by Fabio Vinci in the linked GitHub issue, we would support to change the model in a way, these three FeatureTypes are inheriting from TransportPoint and not TransportNode in order to be able to deliver conformant data."