[AIXM-603] Add PointUsage to SignificantPointInAirspace

Description

A new PointUsage object is added under the SignificantPointInAirspace with properties related to usage roles, ATC reporting and flight level restrictions.

Rationale for change

See https://aixmccb.atlassian.net/browse/AIXM-381, https://aixmccb.atlassian.net/browse/AIXM-180

In the current model, the type of ATC report may be specified for a DesignatedPoint only when it is used as SignificantPoint, through the SegmentPoint. This means that it is not possible to specify the ATC report on a point in isolation, outside the route structure.

There are an increasing number of situations where the ATC report can be specified outside the route structure. In the US airspace, the ATC reporting information may be specified to the point itself, without relating it to a particular route.

In Europe, due to the Free Route Airspace (FRA) concept, the ATC reporting (Compulsory or On request) is specified directly on the point, typically on the en-route maps. The type of report can change with the direction of the flight, especially for boundary points, when a compulsory report might be required when entering the airspace but not when exiting. In addition, because the FRA concept may be applicable only in the upper airspace, the ATC report might be limited to a certain level band. In addition, a significant point may play a certain role, such as entry/exit, arrival/departure connection for an airport, etc. On the same occasion, other point roles such as military point, VFR point, might become necessary to code.

In order to allow the coding of the information discussed above as property of the point itself, this change proposal introduces a new <<object>> PointUsage under the SignificantPointInAirspace, which contains the necessary attributes and associations to cover the model gaps and improvements discussed above.

Impact assessment

[FWD_MAP_1:1] Data mapping is possible and no data loss occurs when data is exchanged from a system (A) that uses AIXM 5.1.1 for output towards a system (B) that uses AIXM 5.2 for input.

[BWD_MAP_LOSS] Data mapping is possible, but some data would be lost (or converted into Notes) when data is exchanged from a system (B) that uses AIXM 5.2 for output towards a system (A) that uses AIXM 5.1.1 for input.

Change Proposal details

In the AIXM UML Model

• Rename the <<codelist>> CodeAirspacePointRoleBaseType into CodePointUsageBaseType and adjust its list of values as follows:
  • redefine ENTRY = “An initial significant point through which an aircraft may pass upon entering the associated airspace.”
  • redefine EXIT = “A final significant point through which an aircraft may pass when leaving the associated airspace.”
  • redefine ENTRY_EXIT = “An initial or final significant point through which an aircraft may pass upon entering or leaving the associated airspace.”
  • add INTERMEDIATE = “A significant point within the associated airspace through which an aircraft may pass when flying through.”
  • add ARRIVAL = “A significant point through which an aircraft may pass when flying through the associated airspace and planning to land at a specified airport/heliport ”
  • add DEPARTURE = “A significant point through which an aircraft may pass when flying through the associated airspace after departing from a specified airport/heliport ”
  • add OCEANIC_ENTRY_EXIT = “A significant point through which an aircraft may pass when entering or leaving the associated airspace and leaving or entering an oceanic area”
  • add EN_ROUTE = “The significant point is used in the route structure within the airspace”
  • add TERMINAL = “The significant point is used in a terminal area within the airspace”
  • add MILITARY = “The significant point is used by military flights within the airspace”
  • add VFR = “The significant point is used by VFR flights within the airspace”
• Rename the <<Datatype>> CodeAirspacePointRoleType into CodePointUsageType
• In the SignificantPointInAirspace class:
  • delete the type attribute
  • in the definition of the relativeLocation attribute remove the last part: “A code indicating the location of a significant point in relation to airspace. Description: Ex: In, Out, On Border”
• Add a new <<object>> PointUsage class, as follows:
  • PointUsage is a specialization of the PropertiesWithSchedule
  • Definition = “Information about the operational role of the significant point in the context of the associated Airspace.”
  • Attributes:
    • role of type CodePointUsageType, definition = “An indication of how the point is used by flights operating in the airspace”
    • reportingATC of type CodeATCReportingType, definition = “An indicator of the type of position report (e.g., compulsory or on request ) required by an ATC Unit”;
    • cardinalDirection of type CodeCardinalDirectionType, definition = “The direction of the flight for which the ATC report is required, if applicable, expressed as a cardinal point”
  • Associations:
    • SignificantPointInAirspace has PointUsage, composition, navigable towards PointUsage
      • 0…* PointUsage with “usage” role name, definition = “Details, such as role, ATC reporting, etc. that define the point use in the context of the airspace”
    • PointUsage isSpecifiedFor AirspaceLayer, , navigable towards AirspaceLayer
      • 0…* AirspaceLayer with “levels’ role name, definition = “The level band or the individual levels for which the point usage is specified”
    • PointUsage isReferringTo AirportHeliport, navigable towards AirportHeliport
      • 0…* AirportHeliport with “referenceAirportHeliport’ role name, definition = “The airport/heliport for which the point usage role is specified”

The following UML class diagram indicates the new/changed elements

Mapping AIXM 5.1.1 to AIXM 5.2 (forward)

The following algorithm shall be applied:

• [MAPC-01] For each SignificantPointInAirspace that has a type child element
  • add a PointUsage child element
  • copy the value of the type into the PointUsage.role element

delete the type element

Mapping AIXM 5.2 to AIXM 5.1.1 (backward)

The following algorithm shall be applied:

• For each SignificantPointInAirspace that has only one PointUsage child element with only the role, reportingATC and/or cardinalDirection elements (no referenceAirportHeliport, no levels)
  • [MAPC-01] insert a type child element and copy the value of the PointUsage.role element as follows:
    • replace INTERMEDIATE with OTHER:INTERMEDIATE
    • replace ARRIVAL with OTHER:ARRIVAL
    • replace DEPARTURE with OTHER:DEPARTURE
    • replace OCEANIC_ENTRY_EXIT with OTHER:OCEANIC_ENTRY_EXIT
    • replace EN_ROUTE with OTHER:EN_ROUTE
    • replace TERMINAL with OTHER:TERMINAL
    • replace MILITARY with OTHER:MILITARY
    • replace VFR with OTHER:VFR
  • [MAPC-02] From the three backward mapping options available in this case, the first two (discard the value or use an extension) are straightforward and do not need any further details. The 3rd option (backward mapping into a Note) is detailed in order to provide a complete description of this case and its conversion option. The following mapping into Note algorithm is proposed:
• Remove the reportingATC and cardinalDiorection elements, as applicable
• Add an annotation.Note associated with the SignificantPointInAirspace class having
• purpose=“OTHER:BACKWARD_MAPPING”;
• LinguisticNote.note=”reportingATC: <value of reportingATC>, cardinalDirection: <value of cardinalDirection>”

• [MAPC-99] For each SignificantPointInAirspace that has more than one PointUsage child element and/or referenceAirportHeliport and/or levels descendants, the new information is too complex to be mapped back into Note. In this case, the EAD ADR extension can be used.

Mapping example

(Note: for mapping test data see: https://github.com/aixm/mapping_52_511/tree/master/AIXM-xxx) 

AIXM 5.2	AIXM 5.1(.1)