aixm 5 design concepts

1

AIXM 5 Design ConceptsAIXM 5 Design Concepts

2

AIXM 5 Design MethodologyAIXM 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

TopicsTopics

• Feature Identification and Relationships

• Geometry

• Temporality

• Data and Message Extensibility

• Metadata


• Geometry

• Temporality


• Metadata

4

TopicsTopics


• Geometry

• Temporality


• Metadata


• Geometry

• Temporality


• Metadata

5

DefinitionsDefinitions

• 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 RelationshipsA safety critical issue

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

• 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

Feature Identification and RelationshipsReview 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 RelationshipsIssues with Natural Keys

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

• 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

Feature Identification and RelationshipsAlternatives

• 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 2Match by ID, location and number of runways

10

Feature Identification and RelationshipsRecommendation Approach

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

• 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

-identifier-property_1-property_2-...-property_n

«feature»Feature1


«feature»Feature2-having

<<query>>

«query»having_Feature2 with identifier = value_1

«query»having_Feature2 with property_1 = value_1 and property_2 = value_2 and property_4 = value_4

'Natural" "Artificial"


«feature»Feature1


«feature»Feature2-having

<<query>>

«query»having_Feature2 with identifier = value_1

«query»having_Feature2 with property_1 = value_1 and property_2 = value_2 and property_4 = value_4

'Natural" "Artificial"

Feature Identification and RelationshipsDesign Approach

Feature Identification and RelationshipsDesign 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

identifier = 3924designator : string = 20L

«feature»20L : RunwayDirectionidentifier = 3939designator : string = 02R/20Llength : float = 5000width : float = 230

«feature»02R/20L : Runway

identifier = 3432codeICAO : string = MABCreferencePoint : GM_POINT = <<geometry>>elevation : float = 323

«feature»MABC : AerodromeHeliport

-has

1

-uses

*

-has

1

-on

*

Feature Identification and RelationshipsExample

Feature Identification and RelationshipsExample

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 1

Alternative 2

Alternative 3

13

TopicsTopics


• Geometry

• Temporality


• Metadata


• Geometry

• Temporality


• Metadata

14

GeometryIn AIXM 4.xGeometryIn 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

GeometryRecommendations

GeometryRecommendations

• 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

CircleSector

+ arcDirection : codeArcDirection+ fromAngle : valAngleBrg+ toAngle : valAngleBrg+ angleType : codeTypeAngleBrg+ angleDirectionReference : codeDirRef+ innerDistance : valDist+ outerDistance : valDist+ upperLimit : valDistVer+ upperLimitReference : codeDistVer+ lowerLimit : valDistVer+ lowerLimitReference : codeDistVer

(from Shared)

<<object>>

16

TopicsTopics


• Geometry

• Temporality


• Metadata


• Geometry

• Temporality


• Metadata

17

TemporalityRequirementsTemporality

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

NDBNDBProperty A = Property B = …

NDBProperty A = Property B = …



Version 1 Version 2 Version 3 Version 4 …

NDB

Commissioned Decommissioned

18

Temporality ModelTemporality 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) 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 ModelTimeSlice 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 FeatureIdentifierStart of LifeEnd of Life

TimeSlice(s)validTimeInterpretation = Baseline

Property 1….Property n

sequenceNumber correctionNumber

21

TemporalityConceptual Model

TemporalityConceptual Model

AIP: NAVAID = AMLStatus = Operational, Freq = 126.00MHz


Status = Offline for upgrades

Status = OnTestfor upgrades

Version 1 Version 2 Version 3 Version 4

Frequency upgrade

coordinated to be

effective next cycle

Baseline 1 Baseline 2

TemporaryDelta 1

TemporaryDelta 2

Permanent Delta 1

Snapshot n



Status = Offline for upgrades

Status = OnTestfor upgrades

Version 1 Version 2 Version 3 Version 4

Frequency upgrade

coordinated to be

effective next cycle

Baseline 1 Baseline 2

TemporaryDelta 1

TemporaryDelta 2

Permanent Delta 1

Snapshot n

22

Synchronization and the Temporality ModelSynchronization and the Temporality Model

T1 P1 T2 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 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 considerationsProcedural 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 ChangesProcedural 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

• 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 V1 V3

25

TopicsTopics


• Geometry

• Temporality


• Metadata


• Geometry

• Temporality


• Metadata

26

Data Model ExtensibilityRequirements

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

• 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

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

• 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

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

• 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

TopicsTopics


• Geometry

• Temporality


• Metadata


• Geometry

• Temporality


• Metadata

30

PurposePurpose

• 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

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 ProfileUsing 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 ProfileThe 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 ApproachStudy 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 Elementsexample

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>

• 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>

• 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



• <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>

• <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



<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)

<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-upMetadata wrap-up

• Metadata Profile white paper available at www.aixm.aero

• Validating the model using tools such as MetaModel Integration Bridge

• [email protected]

• Metadata Profile white paper available at www.aixm.aero

• Validating the model using tools such as MetaModel Integration Bridge

• [email protected]

http://www.aixm.aero/

http://www.aixm.aero/

40

Summary of AIXM 5 Design Recommendations

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

• 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• Additional metadata slides

43

Metadata to include about the AIXM message

Metadata to include about the AIXM message

44

Two new metadata elements 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 Constraint Information Metadata

46

Two new constraint roles 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

Metadata to include about an AIXM feature

FeatureMetadata

dataIntegrity : valuecyclicRedundancyCheckFeature : character1noteCRCFeature : character1

<<object>>

48

Three new metadata elementsThree 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

Metadata to include about an AIXM feature timeslice

50

Three new metadata elementsThree 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

Citation and Responsible Party Information Metadata

52

Similar to ISO19115Similar 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 Data Quality Information Metadata

aixm 5 design concepts

Documents