AIXM 4.5 and 5.1 Reading, Writing and Validation - EU Airports Demo

Introduction

AIXM is the Aeronautical Information Exchange Model format. FME supports reading and writing AIXM version 4.5 (XML) and AIXM version 5.1 (GML). AIXM 5.1 writing requires FME 2014 or newer. Each of these versions is described below. An example of writing AIXM5 AirportHeliports is also included.

AIXM 4.5 XML

AIXM 4.5 is a complex XML based format designed to support Aeronautical Information Services (AIS). AIXM 4.5 contains no explicit geometry but rather has is built on relationships between non-geometry features and those with geoLong and geoLat attributes. Given the complexities of the schema and the way that geographic information is stored, data conversions between typical GIS data and AIXM 4.5 involves many transformation steps and usually requires the assistance of FME experts and experts familiar with the intricacies of the AIXM data models. Reading AIXM 4.5 is straightforward, but only yields non-geometry features and point features derived from the geoLong and geoLat attribute values. Linear and area features that could be derived from parent object relationships are not generated.

AIXM 5 GML

AIXM 5 supersedes AIXM 4.5 and is GML based. As such it is best thought of as a completely different format than 4.5. It also means that all the geometries are composed of valid GML constructs. GML objects can be read and written with existing GML libraries. This dramatically simplifies the process of working with AIXM data and converting between GIS and AIXM data structures. AIXM5 is still a very complex schema and so writing to this format will still require the support of experts familiar with the AIXM standard. Reading AIXM 5.1 is a simple matter of selecting the source dataset and choosing the AIXM5 reader. Note that both AIXM 5.0 and 5.1 versions are supported.

Reading AIXM5 GML

Reading AIXM typically just involves pointing at the source data and choosing the AIXM format. You may need to choose axis order if it is not oriented correctly. You may also choose to map complex properties as XML Fragments and then use flattening options (substitute empty string for list braces) to make it easier to map from multiple, nested elements to a relational structure such as in GIS. To preserve the XML structure leave it with the default reader setting of Map Complex Properties as 'Nested Attributes'. For schema Show Feature Types from: 'Dataset only with attributes merged from schema' typically yields the best results.

AIXM5 GML Writing

To write AIXM5 data, add an AIXM5 writer and select the themes you want to write to. FME places those destination feature types on the workspace, based on the AIXM schemas. Then its a matter of FME data restructuring and schema mapping to support that destination AIXM schema. Your first step will be to decide which destination feature types you want to write to. Its usually a good idea to start simple and choose a few element types. For example, if you are trying to create an airport AIXM dataset, you could start with runways, and the feature types required to support it. To do this, you need to add the AIXM writer, and then import all the feature types associated with runways. So you could start with writing to Runways, RunwaysTimeslice, plus AIXMBasicMessage which is the document container. Note that you cannot create user defined fields or feature types. You must import the destination schema and restructure your data to precisely match that.

To successfully accomplish this transformation, you need to understand the AIXM schema requirements in terms of required fields, IDs, parent / child relationships, nillable fields etc. Typically AttributeCopiers are used to do schema field mapping, AttributeCreators are used to define default values, and AttributeValueMapper for value mapping. SchemaMapper can do all of this across multiple feature types using external crosswalk tables stored in csv or excel tables. Then there is the challenge of constructing the correct geometry structures. GeometryPropertySetters are used to set the correct geometry names, traits such as gml_ids, and Aggregators to assemble the complex geometry aggregates. See the attached EU airports writing example. A workspace that reads AIXM5 data and writes it back out needs exactly 0 transformers. The AIXM5 reader / writer supports all the complexities required for AIXM such as embedded geometry traits (for ids material types etc), multiple geometries per feature, nested features, repeating elements, nillable elements. We have also streamlined the GUIs and workspace parameters to make them easier to use. Note that, if there is a new draft schema you wish to use, you can override the FME shipped one with the updated one, or just use the GML writer. Note that the GML reader will examine the namespaces on any given GML file and use that to determine which reader to use, so the GML reader can be used to read AIXM data as well. FME's AIXM reader / writer also supports AIXM extensions which are implemented by add-on application schemas typically from a major aviation authority (e.g. FAA or EUROCONTROL). These add-on schemas can be referenced under the application schema parameter, and should themselves reference and be compatible with the AIXM parent schemas.

Validation

There is not much point in writing AIXM GML if you can't validate the output. In FME, we use the XMLValidator transformer to do this. This uses the Apache Xerces library for validation, so you know that the results are objective. The easiest way to do this is create a new workspace, add a Creator, then the XMLValidator. Point the XMLValidator at the XML file you want to test and to the XSD file of the AIXM application schema you want to validate against. Connect the output of XMLValidator to Loggers. Run the workspace and review the log to see if your XML is valid. If not you will get a full report listing the problems with your XML related to the AIXM schema. Note that XMLValidator also has a syntax only verification mode.
When building a new workspace you will often get numerous validation errors at first. To help work your way through this, its a good idea to limit your output to one or 2 features.

Some issues to look out for:
- make sure each feature and geometry has a unique id.

- gml_ids must begin with an alphabetic character. A general recommendation is to use a short object type abbreviation to prefix the root feature gml_id. For example if your root id = 101, you could use ah_101 for the airport heliport feature gml_id, ahts_101 for airport heliport time slice gml_id, and aharp_101 for airport heliport time slice ARP point gml_id.

- as above, in most cases, geometries need gml_ids too.
- define the correct parent / child id relationships between AIXMBasicMessage, and whatever elements you are writing.
- uppercase names may be required
- adding any missing / required attributes and geometry traits
- warning messages may say 'element not allowed' when in fact what it means is that you are missing an element that needs to come first, or have failed to write a required parent element.

Examples

Example 1: AIXM to AIXM Round Trip

Test this yourself by taking any AIXM5 dataset of your choice and setting up a workspace that reads and writes it. Open the output in Data Inspector to see that the output has everything in it. Then check to make sure the result validates against AIXMBasicMessage.xsd. Note that if your output doesn't validate, the first thing to check is whether or not your input validates. If your input data is not valid FME will not automatically fix it. Also note that if you want to write to a particular AIXM theme, a good first step still is to get a hold of some sample data. Then you can make an AIXM5 to AIXM5 workspace and log the result. This will show you the structure of the FME feature you need to generate in order to drive your AIXM5 GML writer.

Example 2: INSPIRE Aerodromes to AIXM AirportHeliports

The attached example which shows how to read INSPIRE Transport Network Aerodromes and write AIXM AirportHeliports. The attachment includes the source INSPIRE GML, workspace and output AIXM5 GML, so you can use this to try out the AIXM reader as well.

The workspace illustrates the main transformation steps needed to write AIXM (also described in the AIXM Writing section above):

• Read INSPIRE AerodromeNodes and AerodromeTypes.
• Join both inputs by inspireLocalID in order to add airport type to the aerodrome nodes.
• Generate any required unique IDs
• Create and copy fields according to what is required by the destination AIXM schema (schema mapping)
• Create airport point geometry, including setting the geometry name (ARP) and traits (gml_id gml_object_name)
• Create an aggregate geometry to contain the airport point. Name the geometry 'responsibleOrganisation' and set the traits 'gml_id gml_object_name theOrganisationAuthority.xlink_href' and 'theOrganisationAuthority.owns'
• Branch (copy) the feature stream to populate the three required AIXM destination feature types: AIXMBasicMessage (document container features), AirportHeliport (airport container features), and AirportHeliportTimeSlice (airport geometry features). Most of the data we are interested in goes to the AirportHeliportTimeSlice feature type, but the others are required to comply with the AIXM standard.
• Set the parent / child IDs so that AirportHeliportTimeSlice is a child of AirportHeliport, and AirportHeliport is a child of AIXMBasicMessage. If you fail to do this you will likely see a validation error to the effect 'time slice element not allowed as part of abstract feature type' This is essentially an error warning that you have orphaned features when they should in fact be contained within the appropriate parent feature.
• Create any required list attribute structures using a combination of AttributeCreators and Aggregators.
• Write output to AIXMBasicMessage, AirportHeliport, and AirportHeliportTimeSlice feature types.

Note: In addition to these steps, its important to note that both the source and destination schemas - feature type and attribute data models - are schema driven. That is, the schemas must be selected from the list of available schemas when you create the workspace, or add the reader / writer. You cannot create any user defined fields or attributes since these will not be compliant with the AIXM schema.