AIXM 5 Design Concepts

1. AIXM 5 Design Concepts

2. AIXM 5 Design Methodology • Build upon lessons learned from AIXM 4.x • If possible incorporate industry and international standards • ICAO • ISO • RTCA/EUROCAE • ARINC

3. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

4. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

5. Definitions • Feature identification • How do we uniquely identify an important aeronautical entity • KJFK Aerodrome • Taxiway N • Feature relationships • How do we associate one feature with another • Runway 25 is at Airport MXAB • AML Navaid is the starting Point on a Procedure Segment Leg

6. Feature Identification and RelationshipsA safety critical issue • Safety critical applications • NOTAMs indicating a change in operating environment • Avionics updates – FMS, Electronic Flight Bag, Situational Awareness • Must ensure positive feature identification

7. Feature Identification and RelationshipsReview of AIXM 4.x • Natural keys • Groups of feature properties and relationships used to identify features From AIXM 4.x

8. Feature Identification and RelationshipsIssues with Natural Keys • Unnamed aeronautical features • Runway markings, Procedure Legs, Gatestands • Natural keys based on geography • NAVAIDs identified by location • Different projections, precision • Overloaded purpose • Natural keys are also feature properties • Changes to natural key properties is awkward • For example, Navaid AML is now called MAL

9. Feature Identification and RelationshipsAlternatives Alternative 1 Store x3234 Alternative 2 Match by ID, location and number of runways • Artificial identifiers • Keys provided by the data supplier • Feature identification • User may need to use business rules to reconcile data with their system • Or store data supplier keys in their database. Aerodrome x3234 My Aerodromes My System Data Supplier

10. Feature Identification and RelationshipsRecommendation Approach • Flexible use of artificial or natural identification • Support global registry if it becomes a reality • Eliminate problem of property overloading • Allow data supplier to provide natural key encoding rules

11. Feature Identification and RelationshipsDesign Approach • Combination approach • Support natural and artificial identifiers • Queries to indicate relationships Global Identifier Property Flexible query for relationships

12. Feature Identification and RelationshipsExample Alternative 1 RunwayDirection uses Runway where identifier = 3939 RunwayDirection uses Runway where designator = 20L/02R and on AerodromeHeliport where codeID = MABC RunwayDirection uses Runway where identifier = 3939 or uses Runway where designator = 20L/02R and on AerodromeHeliport where codeID = MABC Alternative 2 Alternative 3

13. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

14. GeometryIn AIXM 4.x • Based on aeronautical domain • Custom construction • 2 ½ D • Horizontal boundary • Properties for upperand lower limits.

15. GeometryRecommendations • Standardize geometries using ISO19107 Spatial Schema • GM_POLYGON • GM_LINE • GM_POINT • Consistent with GML (ISO19136) • Augment with aeronautical properties where needed

16. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

17. TemporalityRequirements • Aeronautical Features have • Start of Life and End of Life • Feature properties can change with time • Classify changes • Temporary – like NOTAMs • Permanent – like AIRAC Cycle NDB NDB Version 1 Version 2 Version 3 Version 4 … NDB Property A = Property B = … NDB Property A = Property B = … NDB Property A = Property B = … NDB Property A = Property B = … Commissioned Decommissioned

18. Temporality Model • Definition • A model that incorporates the concept of time • AIXM Temporality Model • Relates features to the time extent in which they are valid • Provides various means to describe the time extent

19. Temporality Model (continued) • Operational changes are modeled as deltas • Deltas can be permanent or temporary: • Permanent delta: A set of properties that have changed or will change permanently. The permanent delta will result in a new baseline. • Baseline:The state of a feature and all of the feature properties as a result of a permanent delta. The Baseline state of a feature also exists when the feature is initially created. The Baseline state lasts until the next permanent delta. • Temporary delta: A set of values for one or more feature properties that are effective for a limited time. The result is a temporary change to an underlying feature version. • Version:The state of a feature and all the feature properties during the time period between two changes. This is a conceptual temporal model that can be implemented in many ways

20. TimeSlice Model Abstract AIXM Feature Identifier Start of Life End of Life TimeSlice ( s ) validTime Interpretation = Baseline sequenceNumber correctionNumber Property 1 … . Property n • Extended TimeSlice data content model from GML • Valid time period • Interpretation • Baseline • Version • Temporary Delta • Permanent Delta • Sequence Number - tracks TimeSlices for a given feature from a particular feature provider • Correction Number – tracks corrections to a previously transmitted TimeSlice

21. TemporalityConceptual Model

22. Synchronization and the Temporality Model B: Baseline P: Permanent Change T: Temporary Change V: Version T4 T1 P1 T2 T3 B1 B2 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 V1 = B1 V2 = B1 + T1V3 = B1B2 = B1 + P1 V4 = B2 Bn = Bn-1 + ∑PΔ¡ V5 = B2 + T2 V6 = B2 V7 =B2 + T3 V8 = B2 + T3 + T4 V9 = B2 + T4 V10 = B2 Vm = Vm-1 + ∑TΔi + ∑PΔj

23. Procedural considerations • Systems determine what AIXM temporal capabilities to use • Use baselines only • Use temporary changes only • Provide periodic versions • Disregard difference between temporary and permanent changes • Provide full AIXM temporality model capability

24. Permanent changes can result in a new version or a new baseline Whether a permanent change creates a new baseline or not is a procedural decision. A permanent change could be promulgated electronically Everyone would have important information as soon as possible This could be followed up by a published baseline Procedural Aspects of Permanent Changes T1 P1 B1 B2 V1 V2 V1 V3

25. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

26. Data Model ExtensibilityRequirements • Feature properties • Add a new power for a VOR navaid • Feature relationships • Add a new hasEmergencyAerodrome relationship to Airspace • New features • Create a new Aerial Refueling Track feature

27. Data Model ExtensibilityAdvantages • Increased adoption of AIXM by allowing AIXM to support more applications • Charting with style properties • Design tools with design criteria properties • Decreased pressure on AIXM configuration control board (CCB) • Easy to add custom properties • Use CCB to globalize useful extensions

28. Message ExtensibilityIssues • AIXM 4.x • <AIXM-Snapshot> and <AIXM-Update> insufficient for global exchange • Based on EAD requirements for database updates • Other messages • WFS (Web Feature Service) • xNOTAM • US NOTAMs • Procedure Design packets • Automated charting data packets • Airport Mapping

29. Topics • Feature Identification and Relationships • Geometry • Temporality • Data and Message Extensibility • Metadata

30. Purpose • Purpose of the AIXM metadata analysis was to recommend a metadata model and content for AIXM 5.0 • AIXM 5.0 metadata profile identifies a minimum practical set of desirable elements required to describe information exchanged via AIXM

31. Linkage to ISO19115 : 2003 Geographic Information-Metadata • The structure of the AIXM metadata profile is based on ISO19115 • Not intended to be a substitution for ISO 19115 • Nor does it completely conform to ISO19115

32. Using AIXM Metadata Profile • Within an AIXM message, data producers should include metadata about the message • Within the feature section of the AIXM message, data producers should include metadata for each feature timeslice • The decision to include metadata within the AIXM message is optional • if the data producer elects to send metadata, it must conform to the AIXM metadata profile

33. The AIXM Metadata Profile • The profile includes six models: • Metadata for the AIXM message • Metadata for an AIXM feature • Metadata for an AIXM feature timeslice • Constraint information • Citation and Responsible Party information • Data Quality information

34. Study Approach • Our approach to defining a metadata profile included: • Conducting an extensive review of the proposed features in AIXM 5.0 and of the available literature on metadata • Holding meetings and interviews with metadata subject matter experts • Developing UML (universal modelling language) class diagrams of proposed models of the metadata profile

35. Mandatory Metadata Elementsexample • Example of the structure of an AIXM message including only the mandatory metadata elements proposed in this AIXM metadata profile (Beginning of AIXM message) <MessageMetadata> <dateStamp>2006-05-15T17:00:00Z</dateStamp> <contact> <individualName>Christian Grothe</individualName> <positionName>Research Assistant at FSR/TUD, responsible for compiling sets of aeronautical data to AIXM messages</positionName> <role>distributor</role> </contact> <messageIdentificationInfo> <abstract>This AIXM message only contains an obstacle timeslice of type “baseline”, valid from 01 Jan 1985</abstract> <language>en</language> </messageIdentificationInfo> </MessageMetadata>

36. Mandatory Metadata Elementsexample continued • AIXM message example selected is the encoding of an obstacle with point-type geometry <?xml version="1.0" encoding="UTF-8"?> <FeatureMetadata> (no mandatory elements in this portion of the profile) </FeatureMetadata> <Obstacle xmlns="http://www.aixm.aero" xmlns:gml="http://www.opengis.net/gml" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Xsi:schemaLocation="http://www.aixm.aero AIXM-GML-ObjectTypes.xsd" gml:id="ID000000"> <identifier codeSpace="http://www.aixm.aero/Amswell">EA001</identifier> <gml:validTime> <gml:TimePeriod> <gml:beginPosition>1985-01-01T00:00:00</gml:beginPosition> <gml:endPosition indeterminatePosition="unknown"/> </gml:TimePeriod> </gml:validTime>

37. Mandatory Metadata Elementsexample continued • <timeSlice> • <FeatureTimeSliceMetadata> • <dateStamp>2006-05-12T12:00:00Z</dateStamp> • <contact> • <organizationName>Institute of Flight Systems and Automatic Control • (FSR)</organizationName> • <positionName>Institute at Technische Universität Darmstadt (TUD)surveying and supplying aeronautical data</positionName> • <role>originator</role> • </contact> • <featureIdentificationInfo> • <abstract> Baseline timeslice for obstacle with point-type geometry – the Donlon antenna</abstract> • <citation> • <title>xNOTAM study</title> • <date>2006-05-10T17:00:00Z</date> • <dateType>revision</dateType> • </citation> • </featureIdentificationInfo> • </FeatureTimeSliceMetadata>

38. Mandatory Metadata Elementsexample continued <ObstacleTimeSlice gml:id="ID000002"> <gml:validTime> <gml:TimePeriod> <gml:beginPosition>1985-01-01T00:00:00</gml:beginPosition> <gml:endPosition indeterminatePosition="unknown"/> </gml:TimePeriod> </gml:validTime> <interpretation>BASELINE</interpretation> …. …. …. </ObstacleTimeSlice> </timeSlice> </Obstacle> (end AIXM message)

39. Metadata wrap-up • Metadata Profile white paper available at www.aixm.aero • Validating the model using tools such as MetaModel Integration Bridge • kim.w-ctr.barnette@faa.gov

40. Summary of AIXM 5 Design Recommendations • Feature Identification and Relationships • Include artificial identifier • Use <<query>> stereotype • Geometry • 2 ½ D with aeronautical properties • Temporality • Versions and Deltas • Implement with GML’s TimeSlice • Data and Message Extensibility • Metadata

41. Thank you

42. Additional metadata slides

43. Metadata to include about the AIXM message

44. Two new metadata elements • cyclicRedundancyCheckMessage is the value or string of alphanumeric characters usually generated by a cyclic redundancy check (CRC) algorithm. • Best practice recommends that the algorithm consider all tags and data content within the AIXM message. When the data receiver applies a CRC algorithm to the message, a different CRC indicates that a tag or data content within the message has been changed since the sender generated the original CRC. • noteCRCMessage is included to provide the ability to relay information to the data receiver if necessary about the CRC calculation. • Using this data element, the sender can document the tags and data content considered in the cyclic redundancy check.

45. Constraint Information Metadata

46. Two new constraint roles • messageConstraintInfo describes any restrictions on the access and use of the AIXM message • If any of the features within the message have attributes with classification codes such as restricted, confidential, top secret, etc., the classification code for the feature captures the highest classification code among the attributes • messageConstraintInfo captures the highest classification code among the features • metadataConstraintInfo describes any restrictions on the access and use of the metadata for the AIXM message • Classification code for this role is determined by the sender or data producer • Both messageConstraintInfo and metadataConstraintInfo are similar to the role metadataConstraints relating MD_Metadata to MD_Constraints in ISO19115

47. Metadata to include about an AIXM feature

48. Three new metadata elements • dataIntegrity as a degree of assurance that an aeronautical data element and its value has not been lost or altered since the data origination or authorized amendment • the dataIntegrity value for an error rate of 5 errors in 10000 is equal to 1 – (5/10000) = 0.9995 • cyclicRedundancyCheckFeature is the value or string of alphanumeric characters usually generated by a cyclic redundancy check (CRC) algorithm. • Best practice recommends that the algorithm consider all tags and data elements within the feature data. • When the data receiver applies the CRC algorithm to the feature data, a different CRC indicates that a tag or data element within the feature data has been changed since the sender generated the original CRC • noteCRCFeature provides the ability to relay information to the data receiver if necessary about the CRC calculation. • Using this data element, the sender can document the tags and data elements considered in the cyclic redundancy check

49. Metadata to include about an AIXM feature timeslice

50. Three new metadata elements • measureClass gives information about how any measurements within the feature timeslice data were captured • contains the string from class-codelist MeasureClassCode • measEquipClass is where the sender can describe the equipment used to capture any measurements within the feature timeslice • dataStatus under IdentificationFeature gives the status of the source of the feature timeslice data • This element is similar to ISO19115 status which maps to the codelist MD_ProgressCode referenced in Annex B.5.23 of ISO19115. • We include this data element due to AirMAT-AICM metadata harmonization