European Commission logo
INSPIRE Community Forum

TN-Air: Should AerodromeNode be a TransportNode or a TransportPoint

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 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?

  • Klaus Gäbler

    We confirm, that we have the same issue. Until now we are denying the result from the validator until a solution will be issued.

  • Klaus Gäbler

    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.

  • Johanna Ott

    Some more information on three different FeatureTypes inheriting from TransportNode that cannot be connected to links for the data of the Deutsche Flugsicherung.

    1. 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.
    2. 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).
    3. 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.