How to provide Environmental Noise Directive (END) major airport information according to INSPIRE TN data theme?

[sMorrone]

Background information
The data models for the reporting of the END spatial data flows have been developed based on the most appropriate INSPIRE data models, by combining specific END reporting requirements and INSPIRE requirements.
In this context, the models for the END major railway and major road sources were developed as extensions of the INSPIRE TN data theme. However, it was not possible to reuse the TN data theme for the reporting of major airport sources, as the identified candidate feature, the AerodromeNode, proved unsuitable for this specific use case.

Issue explanation
As a specialisation of the TransportNode the AerodromeNode can only be used in conjunction with transport link geometries (IR Requirement – Annex II, Section 7.9.3 “In a Transport Networks data set which contains nodes, these nodes shall only be present where Transport Links connect or end “), whereas in the END use case the points representing the airports are the only geometry available.
The lack of an appropriate feature to provide END major airport information according to INSPIRE TN is also relevant for the following.
The END reporting Is an Implementation example of the good practice GeoPackage encoding of INSPIRE datasets and, in accordance with the relevant specification, the EEA is developing executable transformations to obtain INSPIRE GMLs from END GeoPackages and successfully validate them with the INSPIRE Validator. It would be beneficial for country reporters to have such a transformation also available for major airport data, but for the explained reasons this is not possible.

Below are two options discussed by the END team for providing major airport data under INSPIRE TN.

Option 1:
• Use the AerodromeNode with ‘significantPoint’ = false

The significantPoint is an attribute of the AerodromeNode “which indicates whether the air node is or is not a significant point” i.e., a specified geographical location used to define an ATS route, the flight path of an aircraft or for other navigation/ATS purposes

The AerodromeNode could simply represent the aerodrome location (significantPoint = false) or act as transport node for connectivity (significantPoint = true). Transport links should be mandatory only when significantPoint is set to true.
This option would not require a change in the UML model, but only a clarification note in the TG (and related change in the INSPIRE Validator test)

Option 2:
• Amend the TN model creating a dedicated spatial object (e.g., AerodromePoint) as subtype of the abstract TransportPoint (“A point spatial object - which is not a node - that represents the position of an element of a transport network.”) This option would however also require a change in the IR.

In the INSPIRE-MIF application schema repository, a change proposal for the TN data theme asks to amend the current model and derive the AerodromeNode from the TransportPoint instead of the TransportNode. Though this could also be a solution for the END issue above, it should be thoroughly verified whether the proposed change is consistent or not with intended use of the AerodromeNode spatial object in the TN data specification.

Looking forward to a lively exchange!

[sMorrone]

A change proposal related to Option 1 (see INSPIRE-MIF/application-schemas#61 (comment)) was approved by the MIG-T during the 74th MIG-T meeting and then by the MIG (tacit approval after a two-weeks window). The Transport Networks TG (and the INSPIRE Validator behaviour) will be updated accordingly.