5 AIS-AIMSG/2-SN No.

12

ANNEX
It is proposed that the following guidance material is included in the ICAO AIS Manual in order to support States with an aeronautical conceptual and data exchange model.

- DRAFT 1. INTRODUCTION

1.1 The Aeronautical Information Exchange Model (AIXM) provides a formal definition of the aeronautical information published by the States, in the form of a conceptual model. It applies the Unified Modelling Language (UML) conventions, which is the most common modelling language in use. Language. This is meant to support the States in the automation of their AIS processes. The content of Aeronautical Information Publication, including Amendments and Supplements, Circulars and NOTAM can be extracted from a database structured according to this conceptual model. 1.2 AIXM also includes a data exchange format, which is based on the Extensible Markup Language and, more precisely, on the Geography Markup Language (GML). GML is an ISO Standard (ISO 19136) for the encoding of geographical information. This data exchange format enables the States to exchange their aeronautical information in digital format. 1.2.1 AIXM 5.1 has been designed to meet the latest requirements for aeronautical information exchange: a) alignment with the ISO 19100 series of standards for geospatial information, including the use of the Geography Mark-up Language (GML); b) use of the Unified Modelling Language (UML), the widest used modelling standard, for the definition of the conceptual model; c) inclusion of a temporality model at feature level, which enables the model to describe the history, the current status and the future changes, for each feature; d) support for the latest ICAO and industry requirements for aeronautical data, including obstacle databases, terminal procedures and airport mapping; e) modularity and extensibility. 1.2.2 One of the most important aspects of AIXM 5.1 is that the temporality mechanism at feature level can provide "digital NOTAM" capabilites. Basically, a digital NOTAM eliminates the free form text contained within a NOTAM and replaces the text with a series of structured facts about the affected the aeronautical feature concerned. The xNOTAM concept and its benefits are further explained in a separate information paper.

6 AIS-AIMSG/2-SN No. 12 2. SCOPE 2.1 The AIXM scope is based on the ICAO Annex 15 requirements for provision by the Member States of the data necessary for the safety, regularity and efficiency of international air navigation. However, the model goes beyond the strict ICAO Annex 15 requirements, by also taking into consideration existing industry standards and emerging data needs. The complete model is provided as guidance material in order to facilitate the implementation of local solutions that might need to exceed the ICAO SARPS. 2.1.1 The AIXM 5.1 specification includes the following: a) a core Conceptual Model (UML), which describes the aeronautical information features and their properties, associations, values and validation rules; b) a Temporality Concept, which enables capturing the evolution of the properties of an aeronautical information feature over time, from the start of its life until its permanent withdrawal. In particular, this model enables the provision of digital NOTAM; c) a data Encoding Specification (XML/GML Schema) , which implements all the classes defined in the conceptual UML model; d) an extension mechanism, by which groups of users can extend the properties of existing features and add new features, which are for local interest in that group and that are not relevant for global standardization; e) additional documentation that explains the model and its intended usage. 2.1.2 A high-level introduction of these elements is provided in this section. The core AIXM components (UML Model, Data Dictionary, XML Schema, Sample data, etc.) are provided on a CDROM attached to the Manual. Their provision in printed format is not necessary, as most of the material is intended for software developers who are better served by the electronic version. 2.1.3 Additional AIXM documentation is freely and openly available on the www.aixm.aero Web site and through the on-line AIXM discussion Forum, which is accessible from the same Web site. In particular, this includes an AIXM Wiki, which further explains and guides the users of the model. 3. CONCEPTUAL MODEL

3.1 The AIXM Conceptual Model provides a formal description of the aeronautical information items, using UML class diagrams, a standard data modelling language. It uses classes, attributes and associations in order to describe aeronautical features such as airports, runways, navaids, obstacles, routes, terminal procedures, airspace structures, services and related aeronautical data. It also details the business rules that help define aeronautical information. As such, it can be used as the basis for the design of an AIS database. 3.2 The content of AIXM Conceptual Model is available in the form of a Data Dictionary, built according to the ISO 19110 Standard. It also includes the most representative UML class diagrams for each area of the model. An extract from the Data Dictionary is included in section 9. 3.3 An exhaustive explanation of the UML language is available from the creators of the UML Specification, the Object Management Group (OMG): http://www.uml.org/. UML tutorials and

7 AIS-AIMSG/2-SN No. 12 related resources are widely available in both printed and on-line format. In order to facilitate the understanding of the AIXM Conceptual Model, a minimal description of the UML notation is provided in this document. 3.4 3.4.1 Diagram types Two types of diagrams are used in the model: a) Class diagrams Used to represent the features, properties, relationships and inheritance between features; b) Package diagrams Used to split the model into modules and identify dependencies among sets of classes. 4. Stereotypes

4.1.1 The classes are distinguished by their stereotypes. Stereotypes are used to further define and extend standard UML concepts. The main stereotype are <<feature>>, <<object>>, <<choice>>, <<datatype>>, <<enumeration>> and <<codelist>>. 4.1.2 Features

4.1.3 Features describe real world entities and are fundamental in AIXM. AIXM features can be concrete and tangible, or abstract and conceptual and can change in time. Features are represented as classes with a stereotype <<feature>>. Examples include Runway and AirportHeliport. 4.1.4 AIXM features are dynamic features. Timeslice objects are used to describe the changes that affect the AIXM feature over time. Timeslice objects and temporality are discussed extensively in a separate AIXM Temporality document.

8 AIS-AIMSG/2-SN No. 12 5. Objects 5.1.1 Objects are abstractions of real world entities or, more frequently, of properties of these entities, which do not exist outside of a feature. An object is created for two reasons in AIXM: When a property or set of logically grouped properties has a multiplicity greater than one (such as the city served by an AirportHeliport), or

The object has its own attributes that are reused throughout the model, such as ElevatedPoint. 5.1.2 In both cases, the property is represented as an object with the proper UML composition relationship as shown below.

5.1.3 5.1.4

Properties Properties are the attributes and relationships that characterise a feature or object. In the UML:

Attributes are used to describe simple properties of a feature or object; Relationships are used to describe associations to features or objects. Whenever a property has a multiplicity greater than one, it is described using a UML relationship with cardinality. Attributes Simple properties of cardinality one are shown as attributes in the UML diagram. An attribute has the following format: Visibility / stereotype name : type multiplicity For AIXM 5 the following values are used:

6. 6.1.1 6.1.2 6.1.3 6.1.4

Visibility Public / - not used Stereotype not used

9 AIS-AIMSG/2-SN No. 12 Name name of the property Type property type

Multiplicity usually not specified; for reasons related to the AIXM Temporality model, an implementation should assume that all properties are optional, [0..1] 6.1.5 To illustrate, the Runway feature has several simple properties e.g. designator and type. These properties are assigned a datatype; for example, the designator attribute is of type TextDesignatorType.

6.1.6

DataTypes

6.1.7 The UML model lists the datatypes that are used throughout the AIXM. These are given one of three stereotypes: <<datatype>> This is basic data type that specifies a pattern to use. <<enumeration>> This codes a fixed list of values. The OTHER value is important for mapping future changes to the list. If a value is added in the future and is not recognised by the current enumeration, it is mapped to the OTHER value. <<codelist>> This is similar to an enumeration in that it is used to indicate a list of possible values. However, the list can be expanded, which means that the codelist is a union between the explicitly enumerated values and free text.

6.1.8 In addition, certain <<datatype>> might have an associated Unit Of Measurement. This is indicated in the model by the inclusion of a uom attribute in the definition of the <<datatype>> class. The type of the uom attribute is typically an <<enumeration>> class, as shown below:

10 AIS-AIMSG/2-SN No. 12

6.1.9

Relationships

6.1.10 Relationships to Objects 6.1.10.1 Relationships to objects are depicted by the standard UML composition (aggregation by value) association. Composition is a form of aggregation with strong ownership and coincident lifetime of the parts by the whole. The part is removed when the whole is removed.

6.1.10.2Relationships to Features 6.1.10.3 Relationships to features are described with a standard UML association. All of the associations are navigable in only one direction. This shows that the two classes are related but only one class knows that the relationship exists. In the example below the Runway feature knows about the AirportHeliport but the AirportHeliport does not know about the Runway.

6.1.10.4

Naming

6.1.11 Feature, Object and Choice names are written in UpperCamelCase e.g. NavaidEquipment. 6.1.12 Simple property names (i.e. attributes) are written in lowerCamelCase e.g. widthShoulder. Relationship names are written in lowerCamelCase but as present tense verbs e.g. isSituatedAt. Relationship Role names are also written in lowerCamelCase and they are nouns that express the role played by the class in the association. 6.1.13 Datatype names are written in UpperCamelCase and end with Type e.g. CodeAircraftType.

11 AIS-AIMSG/2-SN No. 12 7. TEMPORALITY CONCEPT 7.1 Time is an essential aspect on the aeronautical information world, where change notifications are usually made well in advance of their effective dates. Aeronautical information systems are requested to store and to provide both the current situation and the future changes. The expired information needs to be archived for legal investigation purposes. 7.2 For operational reasons, a distinction is usually made between: permanent changes (the effect of which will last until the next permanent change or until the end of the lifetime of the feature) and temporary status (changes of a limited duration that are considered to be overlaid on the permanent state of the feature). 7.3 A temporary change includes the concepts of overlay and reversion. The temporary change is overlaid on the permanent feature state. When the temporary change ends, the temporary changes no longer apply and we revert back to the permanent feature state. 7.4 7.5 Note that, from an operational point of view, temporary status also includes the concept of temporary features. However, from the AIXM point of view, temporary features are in no way different from normal features. The feature is created and withdrawn, just that the life span is shorter than usual. 7.6 In order to satisfy the temporal requirements of aeronautical information systems, AIXM must include an exhaustive temporality model, which enables a precise representation of the states and events of aeronautical features. In particular, this shall enable the development and the implementation of digital NOTAM. By digital NOTAM we mean replacing the free text contained in a NOTAM message with structured facts, which enable the automated processing of the information. 7.7 In order to describe the feature properties during states and events, the time varying properties of every feature are encapsulated in a container called Time Slice. The history of the feature is described with state Time Slices, each containing the values of the time varying properties between two consecutive changes (events). Each Time Slice has maximum one value for each property and one specified validity period. 7.8 The following Time Slice types are used in the AIXM: BASELINE = a kind of Time Slice that describes the feature state (the set of all features properties) as result of a permanent change. For example, the information contained in AIP Amendments is typically represented as baseline information; PERMDELTA = A kind of Time Slice that describes the difference in a feature state as result of a permanent change. A PERMDELTA contains only those properties that have changed value. TEMPDELTA = a kind of Time Slice that describes the overlay of a feature state during a temporary event. The typical example of information encoded as TEMPDELTA is a NOTAM (navaid unserviceable, closed route, etc.)

12 AIS-AIMSG/2-SN No. 12 SNAPSHOT = A kind of Time Slice that describes the state of a feature at a time instant, as result of combining the actual BASELINE Time Slice (valid at that time instant) with all eventual TEMPDELTA Time Slices that are effective at that time instant. For examples, applications that display the actual status of an airport will show the data in a snapshot. 7.9 The UML model contains a set of abstract AIXM classes that are used as templates for the features and objects defined in AIXM. When applying the Time Slice concept, as described in the previous paragraphs, this triggers the split of every UML class that represents a feature into a main class and a FeatureTimeSlice class, as shown in the following diagram.

7.10 The UML diagram shows how each and every <<feature>> inherits from the abstract AIXMFeature class. The concrete features are described by TimeSlices which are composed of properties. The TimeSlice inherits from the abstract AIXMFeatureTimeSlice class. 7.11 The diagram also shows that each AIXM Feature is described by FeatureMetadata and each TimeSlice is described by FeatureTimeSliceMetadata. Finally, each TimeSlice may contain an Extension. The Extension mechanism allows each user of AIXM 5 to define and use his own specific attributes and classes, in addition to the core AIXM ones.

13 AIS-AIMSG/2-SN No. 12 7.12 The diagram above is quite complex. If applied to the whole set of AIXM classes, it might undermine the readability of the UML diagrams. Therefore, a simplified UML model is provided, without visible inheritance of all features from the abstract AIXMFeature and without visible SomeFeatureTimeSlice classes. However, the split and into SomeFeatureTimeSlice classes is assumed to exist, when converting from the UML model to the XML Schema of AIXM. 7.13 Example

7.13.1 The figure below illustrates the temporal model by showing a transmission frequency change for a navigation aid (VOR AML, from 112.0 MHz to 113.2 MHz). Normally, this change should occur at an AIRAC cycle date. Usually, the change requires the navaid to be out of service for a certain time, then to be on test on the new frequency. The temporary status is communicated at present through NOTAM messages.

7.14

Based on this diagram we can identify the following temporal components: The diagram shows two BASELINE Time Slices. The first baseline has a NAVAID frequency of 112.0 MHz and is valid since some time in the past; the second baseline has the new frequency of 113.2 MHz and is valid starting from the AIRAC cycle date. A PERMDELTA can be used to describe the permanent state change, which is the AML VOR frequency change. For completeness sake, the previous PERMDELTA that has preceded the first BASELINE (1) is also shown. Each transitory event can be expressed as a TEMPDELTA that changes the Operational Status of the navaid and eventually the frequency. Based on the PERMDELTA and the TEMPDELTA delta Time Slices shown in the diagram, four different versions for the current status of the feature may exist. Each current status version begins and ends at the boundary of a Permanent or Temporary Delta and may be presented as a Time Slice of type SNAPSHOT.

14 AIS-AIMSG/2-SN No. 12

8.

XML SCHEMA

8.1 The AIXM exchange model is an XML exchange standard based on a subset of the Geography Markup Language (GML). Essentially: AIXM Features are GML features; AIXM Objects are GML objects; AIXM follows the GML object-property concept. 8.2 The GML object-property model explains some of the complexity of the AIXM UML to XSD mapping. It means that no GML object may appear as the immediate child of a GML object. Consequently, no element may be both a GML object and a GML property. 8.3 The object-property model prohibits the encoding of an object directly inside a feature. Instead, in a compliant GML application schema, an association between two features (or a feature and an object) is implemented over a property of the feature, e.g. <AirportHeliport> <!-- feature --> <hasReferencePoint> <!-- property --> <ElevatedPoint> <!-- object -->

8.4 The direction of the association arrow from the UML diagrams (the navigability) dictates which of the two association partners has the property that associates the other. In the AIXM XML Schema, the object-property model is encoded by declaring a type and then assigning properties (attributes and relationships) to that type. The type defines the object.

15 AIS-AIMSG/2-SN No. 12 8.5 The full AIXM Schema is provided on the CD-ROM that accompanies the documentation and it is also available for on-line validation on the www.aixm.aero/schema/5.1 Web site. An example of an AIXM-encoded feature is provided below, showing the encoding of some data for an Airport: designator, name, magnetic variations, validity tine, global unique identifier.
<aixm:AirportHeliport gml:id="EADH"> <gml:identifier codeSpace="http://www.aixm.aero/schema/5.0/example">dd062d88-3e64-4a5dbebd-89476db9ebea</gml:identifier> <aixm:timeSlice> <aixm:AirportHeliportTimeSlice gml:id="ahts1EADH"> <gml:validTime> <gml:TimePeriod gml:id="vtnull0"> <gml:beginPosition>2009-0101T00:00:00.000</gml:beginPosition> <gml:endPosition indeterminatePosition="unknown"/> </gml:TimePeriod> </gml:validTime> <aixm:interpretation>BASELINE</aixm:interpretation> <aixm:sequenceNumber>1</aixm:sequenceNumber> <aixm:correctionNumber>0</aixm:correctionNumber> <aixm:featureLifetime> <gml:TimePeriod gml:id="ltnull0"> <gml:beginPosition>2009-0101T00:00:00.000</gml:beginPosition> <gml:endPosition indeterminatePosition="unknown"/> </gml:TimePeriod> </aixm:featureLifetime> <aixm:designator>EADH</aixm:designator> <aixm:name>DONLON/DOWNTOWN HELIPORT</aixm:name> <aixm:magneticVariation>-3</aixm:magneticVariation> <aixm:dateMagneticVariation>1990</aixm:dateMagneticVariation> <aixm:magneticVariationChange>0.03</aixm:magneticVariationChange> <aixm:responsibleOrganisation> <aixm:AirportHeliportResponsibilityOrganisation> <aixm:role>OPERATE</aixm:role> <aixm:theOrganisationAuthority xlink:href="http://www.aixm.aero/schema/5.0/example#xpointer(//aixm:OrganisationAuthority[gml:identifier='74efb6ba-a52a46c0-a16b-03860d356882'])"/> </aixm:AirportHeliportResponsibilityOrganisation> </aixm:responsibleOrganisation> <aixm:ARP> <aixm:ElevatedPoint srsDimension="2" gml:id="elpoint1EADH"> <gml:pos srsDimension="3">-32.035 52.288888888888884 </gml:pos> <aixm:elevation uom="M">18.0</aixm:elevation> </aixm:ElevatedPoint> </aixm:ARP> </aixm:AirportHeliportTimeSlice> </aixm:timeSlice> </aixm:AirportHeliport>

16 AIS-AIMSG/2-SN No. 12

9. 9.1

DATA DICTIONARY SAMPLE This section contains an extract from the AIXM Data Dictionary, which is available in on the CD-ROM attached to the AIS Manual.
Definition A defined area on land or water (including any buildings, installations and equipment) intended to be used either wholly or in part for the arrival, departure and surface movement of aircraft/helicopters. A coded designator for an Aerodrome/Heliport. The rules according to which this identifier should be formed are as follows: 1. If the AD/HP has an ICAO four letter location indicator, then this one will become the CODE_ID for the Aerodrome/Heliport; 2. If the AD/HP does not have an ICAO four letter location indicator, but it has an IATA three letter code, then this one will become the CODE_ID for the Aerodrome/Heliport; 3. If the AD/HP has neither an ICAO four letter location indicator nor an IATA three letter code, then an artificial generated code will be used. This will contain a group of letters and a number. The group of letters could be the 2 letter code of the State being responsible for the Aerodrome/Heliport and the number could be an integer between 0001 and 9999. The full free text name of the aerodrome/heliport. The four letter ICAO location indicator of the aerodrome/heliport, as listed in ICAO DOC 7910. The three letter IATA designator of the aerodrome/heliport. A code specifying the type of aerodrome. For example, aerodrome only, combined aerodrome/heliport or simple landing site. Indicating that the airport is certified according to the ICAO rules. An aerodrome or heliport not open for the public. Only for the use of the owners. The primary organization type in terms of civil or military, which controls the airport. The value of the aerodrome elevation. The vertical distance between the highest point of the landing area of an aerodrome and mean sea level. Note: this might be different from the elevation of the Aerodrome Reference Point. N Maximum Occurance Class DataType Related Class

AirportHeliport Name/RoleName 1 AirportHeliport

designator

CodeAirportHeliportDesignatorT ype

3 4 5 6 7 8 9 10

name locationIndicatorICAO designatorIATA type certifiedICAO privateUse controlType fieldElevation

1 1 1 1 1 1 1 1

TextNameType CodeICAOType CodeIATAType CodeAirportHeliportType CodeYesNoType CodeYesNoType CodeMilitaryOperationsType ValDistanceVerticalType

17 AIS-AIMSG/2-SN No. 12
11 12 13 fieldElevationAccuracy verticalDatum magneticVariation The vertical distance from the stated elevation within which there is a defined confidence of the true position falling. Attribute to take the \"Vertical Datum\" (viz. the tide gauge to determine MSL - for example, \"AMSTERDAM GAUGE\", \"NEWLYN\" etc.). The measured angle between Magnetic North and True North at a given point and at the time reported in dateMagneticVariation. By convention, the measure is expressed as a positive number if Magnetic North is to the east of True North and negative if Magnetic North is to the west of True North. Therefore, magnetic bearing + magnetic variation = true bearing. The following rule of thumb applies: ""variation east-magnetic least, variation westmagnetic best"". The accuracy of the Magnetic Variation in angle degrees. The date on which the magnetic variation had this value. The annual rate of change of the magnetic variation. The value of the reference temperature at aerodrome/heliport. A textual description of the altimeter check locations. an 1 1 1 ValDistanceVerticalType CodeVerticalDatumType ValMagneticVariationType

14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30

magneticVariationAccuracy dateMagneticVariation magneticVariationChange referenceTemperature altimeterCheckLocation secondaryPowerSupply windDirectionIndicator landingDirectionIndicator transitionAltitude transitionLevel lowestTemperature abandoned certificationDate certificationExpirationDate contaminant servedCity responsibleOrganisation

1 1 1 1 1 1 1 1 1 1 1 1 1 1 N

ValAngleType DateYearType ValMagneticVariationChangeTyp e ValTemperatureType CodeYesNoType CodeYesNoType CodeYesNoType CodeYesNoType ValDistanceVerticalType ValFLType ValTemperatureType CodeYesNoType DateType DateType Association Association Association AirportHeliportConta mination City OrganisationAuthorit y

A textual description of the secondary power supply available at the aerodrome/heliport. A textual description of the wind direction indicator (WDI) and its position at the aerodrome/heliport. A textual description of the landing direction indicator (LDI) and its position at the aerodrome/heliport. The value of the transition altitude. The value of the transition flight level. The mean lowest temperature of the coldest month of the year References: PANSOPS 8168, PART III Section 3 Chapter 4 BARO-VNAV Indicating that the airport is no longer in operational use, but it's infrastructure is still present and visible from the air. The date when the airport certification has been issued by the supervising authority. The date when the airport certification will become invalid.

The location that is served by the airport. The Organisation that is responsible for managing the airport. Usually, this indicates that the related Organisation/Authority is responsible for the management of

N 1

18 AIS-AIMSG/2-SN No. 12
the aerodrome/heliport. The concept of 'airport management' is not applicable to all aerodrome/heliports world-wide. In that case, the Aerodrome/Heliport will be associated with the State responsible fot its operations. Airport reference point. Boundary of the airport/heliport used for aviation operations. The altimeter source used by the Airport. The description of the contact address.

31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

ARP aviationBoundary altimeterSource contact availability annotation AirportHeliportAvailability operationalStatus warning usage AirportHeliportCollocation type hostAirport dependentAirport annotation AirportHeliportProtectionArea width length lighting obstacleFree surfaceProperties extent annotation

1 1 N N N N

Association Association Association Association Association Association Realizes (PropertiesWithSchedule) CodeStatusAirportType CodeAirportWarningType Association Class CodeAirportHeliportCollocationT ype Association Association Association Class ValDistanceType ValDistanceType CodeYesNoType CodeYesNoType Association Association Association Class

ElevatedPoint ElevatedSurface AltimeterSource ContactInformation AirportHeliportAvail ability Note

Information about airport/heliport.

the

operational

status

of

the

N 1 1 N N 1 1 1 N N 1 1 1 1 1 1 N

Indicates the availability of the facility for specific flight operations. A reason for caution when operating at the facility. Two aerodromes/heliports may be co-located sharing some or all of their ground facilities. E.g. a civil and a military aerodrome using the same runway. A code indicating the extent of the collocation situation of the two aerodrome/heliports. The host Airport. The airport that is colocated at the host Airport. An area situated in the vicinity of a runway, FATO or TLOF, provided to protect aircraft during manoeuvring, take-off and/or landing operations. The value of the physical width of the protection area. The value of the physical length of the protection area. A textual description of the lighting system on the protection area. Indicates if the protection area is obstacle free. The surface characteristics AirportHeliportProtectionArea. Extent of the protection area. of the

AirportHeliportUsage

AirportHeliport AirportHeliport Note

SurfaceCharacteristic s ElevatedSurface Note

19 AIS-AIMSG/2-SN No. 12
54 AirportHeliportResponsibilityOrg anisation N Realizes Class (PropertiesWithSchedule), Association Class (AirportHeliport, OrganisationAuthority)

9.2 Below it is an example of an class diagram from the AIXM Conceptual Model. Such class diagrams are available for all areas of the model (airport, airspace, routes, navaids, etc.) and display in graphical format the main components of the model (features/objects), their attributes and their associations. 9.3 In this example, it is visible that an AirportHeliport feature has properties such as name, designator, referenceTemperature, etc. and associations with classes such as OrganisationAuthority, SurveyControPoint, etc. This information is also present in the Data Dictionary, but the UML diagrams such as the one below present it in a more compact form. It is a standard practice in the information technology domain to provide such diagrams as part of a conceptual model documentation.

20 AIS-AIMSG/2-SN No. 12
GM_Point
(from ISO 19107 Geometry)

<<object>> Point
(from Geometry)

horizontalAccuracy : ValDistanceType

<<object>> ElevatedPoint
(from Geometry)

1 +ARP

hasReferencePoint

elevation : ValDistanceVerticalType geoidUndulation : ValDistanceSignedType verticalDatum : CodeVerticalDatumType verticalAccuracy : ValDistanceType 1 +location hasPosition 0..* <<feature>> SurveyControlPoint designator : TextNameType

+associatedAirportHeliport 1

isSituatedAt

<<feature>> AirportHeliport designator : CodeAirportHeliportDesignatorType name : TextNameType locationIndicatorICAO : CodeICAOType designatorIATA : CodeIATAType type : CodeAirportHeliportType certifiedICAO : CodeYesNoType privateUse : CodeYesNoType controlType : CodeMilitaryOperationsType fieldElevation : ValDistanceVerticalType fieldElevationAccuracy : ValDistanceVerticalType verticalDatum : CodeVerticalDatumType +associatedAirportHeliport magneticVariation : ValMagneticVariationType magneticVariationAccuracy : ValAngleType isSituatedAt dateMagneticVariation : DateYearType 1 0..* magneticVariationChange : ValMagneticVariationChangeType referenceTemperature : ValTemperatureType altimeterCheckLocation : CodeYesNoType secondaryPowerSupply : CodeYesNoType 1 +affectedAirport windDirectionIndicator : CodeYesNoType landingDirectionIndicator : CodeYesNoType isLocatedAt transitionAltitude : ValDistanceVerticalType transitionLevel : ValFLType <<feature>> lowestTemperature : ValTemperatureType 0..* AirportHotSpot abandoned : CodeYesNoType certificationDate : DateType designator : TextDesignatorType certificationExpirationDate : DateType instruction : TextInstructionType 0..*

<<feature>> NonMovementArea

serves

utilizes +altimeterSource isContactedAt hasBoundaryForAviationPurposes hasShape hasExtent

+servedCity <<object>> City name : TextNameType

0..* 0..* <<feature>> AltimeterSource isRemote : CodeYesNoType isPrimary : CodeYesNoType

isUnderResponsibilityOf +contact 0..* +area

isAvailableOn +availability 0..* <<object>> AltimeterSourceStatus operationalStatus : CodeStatusOperationsType

<<object>> AirportHeliportResponsibilityOrganisation role : CodeAuthorityRoleType 0..*

<<object>> ContactInformation
(from Address)

name : TextNameType title : TextNameType

+aviationBoundary

0..1

+extent 0..1 0..1

+contact

<<object>> ElevatedSurface
(from Geometry)

+responsibleOrganisation

isContactedAt

elevation : ValDistanceVerticalType geoidUndulation : ValDistanceSignedType ... verticalDatum : CodeVerticalDatumType ... verticalAccuracy : ValDistanceType

<<feature>> OrganisationAuthority <<object>> PropertiesWithSchedule

(from Schedules) (from Organisation)

name : TextNameType designator : CodeOrganisationDesignatorType type : CodeOrganisationType military : CodeMilitaryOperationsType