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.

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 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 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 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 Relationships A 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 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 Relationships Review of AIXM 4.x Natural keys –Groups of feature properties and relationships used to identify features Natural keys –Groups of feature properties and relationships used to identify features From AIXM 4.x

8 Feature Identification and Relationships Issues 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 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 Relationships Alternatives 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. 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. My System My Aerodromes Data Supplier Aerodrome x3234 Alternative 1 Store x3234 Alternative 2 Match by ID, location and number of runways

10 Feature Identification and Relationships Recommendation 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 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 Relationships Design Approach Combination approach –Support natural and artificial identifiers –Queries to indicate relationships Combination approach –Support natural and artificial identifiers –Queries to indicate relationships Global Identifier Property Flexible query for relationships

12 Feature Identification and Relationships Example RunwayDirectionusesRunway where identifier = 3939 RunwayDirectionusesRunway 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 1 Alternative 2 Alternative 3

14 Geometry In AIXM 4.x Based on aeronautical domain Custom construction 2 ½ D –Horizontal boundary –Properties for upper and lower limits. Based on aeronautical domain Custom construction 2 ½ D –Horizontal boundary –Properties for upper and lower limits.

15 Geometry Recommendations Standardize geometries using ISO19107 Spatial Schema –GM_POLYGON –GM_LINE –GM_POINT –Consistent with GML (ISO19136) Augment with aeronautical properties where needed Standardize geometries using ISO19107 Spatial Schema –GM_POLYGON –GM_LINE –GM_POINT –Consistent with GML (ISO19136) Augment with aeronautical properties where needed

17 Temporality Requirements 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 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 Property A = Property B = … NDB Property A = Property B = … NDB Property A = Property B = … NDB Property A = Property B = … Version 1Version 2Version 3Version 4 … NDB 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 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. 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 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 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 Abstract AIXM Feature Identifier Start of Life End of Life TimeSlice(s) validTime Interpretation=Baseline Property1 …. Property n sequenceNumber correctionNumber

21 Temporality Conceptual Model

22 Synchronization and the Temporality Model T1 P1T2 T3 B: Baseline P: Permanent Change T: Temporary Change V: Version B1 B2 V1 V2 V3 V4 V5 V6 V7 V8 V9 V10 T4 V1 = B1 V2 = B1 + T1 V3 = B1 B2 = B1 + P1 V4 = B2 B n = B n-1 + ∑PΔ ¡ V5 = B2 + T2 V6 = B2 V7 =B2 + T3 V8 = B2 + T3 + T4 V9 = B2 + T4 V10 = B2 V m = V m-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 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 Procedural Aspects of Permanent Changes 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 T1 P1 B1 B2 V1 V2 V1V3

26 Data Model Extensibility Requirements 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 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 Extensibility Advantages 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 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 Extensibility Issues AIXM 4.x – and 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 AIXM 4.x – and 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

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 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 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 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 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 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 Elements example Example of the structure of an AIXM message including only the mandatory metadata elements proposed in this AIXM metadata profile (Beginning of AIXM message) 2006-05-15T17:00:00Z Christian Grothe Research Assistant at FSR/TUD, responsible for compiling sets of aeronautical data to AIXM messages distributor This AIXM message only contains an obstacle timeslice of type “baseline”, valid from 01 Jan 1985 en Example of the structure of an AIXM message including only the mandatory metadata elements proposed in this AIXM metadata profile (Beginning of AIXM message) 2006-05-15T17:00:00Z Christian Grothe Research Assistant at FSR/TUD, responsible for compiling sets of aeronautical data to AIXM messages distributor This AIXM message only contains an obstacle timeslice of type “baseline”, valid from 01 Jan 1985 en

36 Mandatory Metadata Elements example continued AIXM message example selected is the encoding of an obstacle with point- type geometry (no mandatory elements in this portion of the profile) <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"> EA001 1985-01-01T00:00:00 AIXM message example selected is the encoding of an obstacle with point- type geometry (no mandatory elements in this portion of the profile) <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"> EA001 1985-01-01T00:00:00

37 Mandatory Metadata Elements example continued 2006-05-12T12:00:00Z Institute of Flight Systems and Automatic Control (FSR) Institute at Technische Universität Darmstadt (TUD)surveying and supplying aeronautical data originator Baseline timeslice for obstacle with point-type geometry – the Donlon antenna xNOTAM study 2006-05-10T17:00:00Z revision 2006-05-12T12:00:00Z Institute of Flight Systems and Automatic Control (FSR) Institute at Technische Universität Darmstadt (TUD)surveying and supplying aeronautical data originator Baseline timeslice for obstacle with point-type geometry – the Donlon antenna xNOTAM study 2006-05-10T17:00:00Z revision

38 Mandatory Metadata Elements example continued 1985-01-01T00:00:00 BASELINE …. (end AIXM message) 1985-01-01T00:00:00 BASELINE …. (end AIXM message)

39 Metadata wrap-up Metadata Profile white paper available at www.aixm.aero www.aixm.aero Validating the model using tools such as MetaModel Integration Bridge kim.w-ctr.barnette@faa.gov Metadata Profile white paper available at www.aixm.aero 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 > stereotype Geometry –2 ½ D with aeronautical properties Temporality –Versions and Deltas –Implement with GML’s TimeSlice Data and Message Extensibility Metadata Feature Identification and Relationships –Include artificial identifier –Use > 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. 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 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 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 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

51 Citation and Responsible Party Information Metadata

52 Similar to ISO19115 Class ResponsibleParty is essentially the same as the CI_ResponsibleParty class from ISO19115 except we add a new data element systemName as a place to describe the responsible system, i.e., database or repository that transmitted or compiled AIXM information. ISO19115 class maps data element contactInfo to the class CI_Contact, whereas the AIXM version of the responsible party class maps data element contactInfo to the class Contact. –Contact class contains less information than the ISO19115 CI_Contact class –Data element address is the same as in ISO19115 which maps to the CI_Address class –Data element phone maps to the class Telephone, whereas the ISO19115 phone points to CI_Telephone –UML class diagram reflects the restricted associations between Contact and CI_Contact, and Telephone and CI_Telephone. Class ResponsibleParty is essentially the same as the CI_ResponsibleParty class from ISO19115 except we add a new data element systemName as a place to describe the responsible system, i.e., database or repository that transmitted or compiled AIXM information. ISO19115 class maps data element contactInfo to the class CI_Contact, whereas the AIXM version of the responsible party class maps data element contactInfo to the class Contact. –Contact class contains less information than the ISO19115 CI_Contact class –Data element address is the same as in ISO19115 which maps to the CI_Address class –Data element phone maps to the class Telephone, whereas the ISO19115 phone points to CI_Telephone –UML class diagram reflects the restricted associations between Contact and CI_Contact, and Telephone and CI_Telephone.

53 Data Quality Information Metadata

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

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.

Similar presentations

Presentation on theme: "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."— Presentation transcript:

Similar presentations

About project

Feedback