Testbed-12 FIXM GML Engineering Report

Using the following elements from GML as well as ISO/TS 19139:2007 GCO would not provide any benefits, neither for FIXM itself nor for interoperability. Also, these would impose additional complexity on the FIXM model and increase the size of FIXM documents. So it is recommended not to introduce these into FIXM:

The following element from GML is not recommended for FIXM, because the GML system for units of measurements is not as fine grained as the UOM system of FIXM:

However, if a future version of the GML standard would develop a UOM system more suitable for FIXM, this recommendation should be reconsidered. Using a common set of UOM types throughout all GML application schemas (AIXM, FIXM, WXXM, …​) would provide an interoperability benefit on its own, especially with regard to generic GIS clients or generic GIS processing tools.

During integration of the FIXM GML compliant WFS with the data broker, a data usability issue was raised. The issue stemmed from the concepts described in Section 7.7 and Section 7.8, and highlights a use case for implementing the related change requests.

The FIXM standard permits a point to be represented using one of multiple encodings: (1) by bearing, distance and reference point (fb:IntersectionType), (2) by latitude-longitude coordinate pair (fb:PositionPointType), or (3) by reference point (fb:DesignatedPointOrNavaidType).

The original FIXM data sourced for the Testbed 12 scenario represented different points within a single flight route using either approach 2 or 3. The use of referenced points led to issues when visualizing and querying the data. For example, a user requesting the aforementioned FIXM data would be unable to visualize or spatially query the data without resolving the points to latitude-longitude coordinate pairs. Compounding the issue is the fact that fixes representing points are not globally unique. Therefore, in order to resolve reference points to latitude-longitude coordinate pairs, resolution must be done in context of the preceding and/or following points if using a global lookup table of reference points.

Change requests contained within Section 7.7 and Section 7.8 discuss encoding points using a combination of the aforementioned representation approaches. For example, a point may be represented using both the reference point and also a latitude-longitude coordinate pair. Using this approach a user is able to spatially locate the data whilst maintaining the point reference without incurring the complexities of referenced point resolution.

The following changes are recommended for FIXM. These are to be submitted as change requests (CR) for approval by the FIXM Change Control Board (CCB). The change requests are numbered with a "TB12" prefix (TB12.1, TB12.2, …​) to facilitate referencing these change requests during the process through the FIXM CCB.

By default, the object-property model is instantiated by UML to GML Application Schema (UGAS) tools such as Interactive Instruments ShapeChange^[3] or inbuilt Enterprise Architect GML Application Schema output functionality.

These UGAS tools are typically built upon standard encoding rules (see GML 3.2.1 Annex E) that specify the mapping between an ISO 19109 conformant UML model to a GML application schema. In general, UML to GML application schema encoding rules are based on the concept that UML class definitions are mapped to type and element declarations in XML schema.

Interactive Instruments ShapeChange UGAS tool was used in OGC Testbed 10 to output the FIXM GML XSDs from an ISO 19109 conformant FIXM 2.0 UML model. Using this standard approach, the outputted GML application schema was subject to the GML object-property model which lead to additional XML nesting in the data. This XML nesting lead to data bloating, for example:

Example of FIXM 2.0 Encoding:

Example of GML Conformant FIXM 2.0 Encoding:

The above examples demonstrate the GML conformant FIXM version introduces object levels inspired by the GML object-property model (for example, RouteSegment and RoutePoint). This increased XML nesting is undesirable to FIXM stakeholders who want an efficient and compact XML encoding. Therefore, during Testbed 12 the decision was made to maintain a compact encoding and not adopt this approach of instantiating the GML object-property model.

This can be achieved by adding another element foo to the meta structure which is similar to "object", but has a more compact XML encoding. Of course, foo then will not have certain properties which "objects" usually have:

Using off-the-shelf UGAS tools, this approach is not possible due to the deviation from standard UGAS encoding rules. Custom development would be required to support such additional encoding rules and functionality. Due to the development required coupled with the limitations above, this approach was not adopted in Testbed 12.

By discarding the use of the object-property model, data bloating concerns are negated. This can be achieved by providing minimal modification to the existing FIXM XML schemas to allow them to function with existing WFS implementations.

Following the results of GML integration into FIXM during OGC Testbed 10^[4], FIXM stakeholders investigated integration of GML without object-property model implementation. The Testbed 12 sponsor provided the XML schema produced from the aforementioned investigation. This provided a starting point for the Testbed 12 requirement - the XML schema was based on FIXM 3.0.1, with specific modifications to include GML elements only where needed.

Producing such an XML schema with discarded object-property model from UML requires a custom UGAS tool that does not fully implement UML to GML Application Schema encoding rules. Producing such a custom tool during Testbed 12 was beyond the remit, therefore, this was achieved by applying XML schema modification directly.

To process FIXM with common GML tools, such as serving FIXM through a WFS, all FIXM feature types must be marked as GML feature types. That means:

Currently FIXM defines many feature types that are not intended to be used as stand-alone features - therefore, should not be converted to GML features. For each FIXM feature converted to GML features, two modifications would be encountered:

These modifications contradict the desired compactness of FIXM. To prevent the above complications, there should be a few feature types in FIXM as possible. That is, only the central fx:FlightType should become a feature type. For fx:FlightType to be realised as a GML feature, the following changes have been applied:

Note that this adds a new required XML attribute, gml:id, on the fx:Flight element. It also requires the following attributes directly defined in fx:FlightType to be converted to XML elements:

In summary, the following FIXM document:

is changed to:

While this increases the size of FIXM documents by a few bytes, this is a one-time increase per <fx:Flight> feature. Moreover, this affects only datasets where these properties are actually set.

Alternatively, it is also possible to introduce a new property element that carries the attributes flightType and remarks.

This leads to the following FIXM change requests:

Because the xsi:type attribute explicitly asserts an element’s type, some tools cannot match the name of the type instead of the name of the element – in this case knowing the element name and the context in which it occurs is not enough to process the XML. Conversely, a “type-aware” application can process XML containing xsi:type attributes – therefore, for an application processing FIXM being “type-aware” would be a requirement.

Schema modifications to remove the xsi:type attribute were discussed during Testbed 12, however lead to increased XML nesting. In summary, following investigation use of the xsi:type attribute within a GML conformant FIXM was deemed acceptable.

This ICAO designator, KATL, identifies a specific aerodrome, Hartsfield-Jackson Atlanta International Airport. A consumer of this data may want further information about the referenced feature, for example to visualize this data a consumer would need to resolve this ICAO designator to a geographic location.

To harmonize FIXM with AIXM and allow consumers to locate additional information for referenced features, the use of XLink in FIXM was investigated. By using XLink, internal or external links can be added to XML documents in a standardized format.

For example, the below example presents the same departure aerodrome as the previous example, however uses the xlink:href attribute to reference an external location. In this example, the external location is a WFS endpoint.

The use of XLink also offers the opportunity to add human-readable descriptions using the xlink:title attribute. In the example below, the name attribute has been replaced with xlink:title.

This change request is a preparation for the change requests TB12.2 and TB12.3. It ensures that the scope of these change requests is limited as much as possible, which vastly reduces the total number of required changes to the FIXM XML Schema.

The current FIXM 4.0 draft defines many feature types that aren’t actually meant to be used as stand-alone features. When switching to GML feature types as of TB12.2, this would impose restrictions on these types as described in TB12.3. Moreover, this would add a required gml:id attribute to all these types, contrary to the desired compactness of FIXM.

To prevent these complications, the following types should no longer be feature types. That is, these types should no longer extend from fb:FeatureType and their elements should be removed from the substitution group fb:Feature:

The single remaining feature type is fx:FlightType, which is the only real feature type in FIXM.

Note that in particular, fb:ExtensionType should no longer be a feature type. Otherwise, all future extension types would have to take care of the restrictions as described in TB12.3. This is in line with the FIXM documentation, which clarifies that the extension type is meant to be used for objects, not features:

This also fits well with the current use of fb:ExtensionType in existing FIXM extensions. For instance, the FIXM NAS extension does not define its feature type nas:NasFlightType to extend from fb:ExtensionType, but instead from fx:FlightType, which is perfectly in line with this change request.

None. This issue has already been addressed in the latest FIXM 4.0 draft.

To process FIXM with common GML tools, such as serving FIXM through a WFS, all FIXM feature types must be marked as GML feature types. That means:

Assuming that TB12.1 is accepted, hence fx:Flight being the only FIXM feature type, these reduce to the following changes:

Note that this adds a new required attribute gml:id on the <fx:Flight> element, more to that in TB12.4.

The WFS standard states that the properties of a feature must be XML elements, not XML attributes. (Here the gml:id does not count as "property".) This means that all features types should have no top-level XML attributes besides gml:id. Otherwise, compliant WFS implementations are allowed to refuse such datasets, or worse, to silently ignore these attributes (except for gml:id). Note that this applies only to XML attributes on feature type level, while sub elements may have XML attributes.

Assuming that TB12.1 is accepted, hence fx:Flight being the only FIXM feature type, this means that only the direct attributes of <fx:Flight> have to be converted to elements.

This affects the following attributes:

In summary, the following FIXM document:

is changed to:

While this increases the size of FIXM documents by a few bytes, this is a one-time increase per <fx:Flight> feature. Moreover, this affects only datasets where these properties are actually set.

As a consequence of TB12.2 and TB12.5, there is a new required attribute gml:id on the <fx:Flight> element and all point geometries. Although this goes slightly contrary to the compactness goal of FIXM, the gml:id is currently unavoidable (as of GML 3.2) and important for a variety of WFS operations, filter expressions and so on. A business rule should be established on how to fill the gml:id. That is, the FIXM standard should state a policy such as the following:

In case TB12.10 is not accepted, replace <gml:identifier> with <fx:gufi> in the above statement.

None. This change request is about establishing an informal policy in FIXM which cannot be expressed in XML Schema.

The use of GML geometries plays a central role in improving the interoperability of FIXM, where gml:PointType is the most relevant for FIXM.

All point geometries in FIXM use or extend from fb:GeographicalPositionType, whose definition is already very similar to gml:PointType. To finish the transition to gml:PointType,

Note that this adds a new required attribute gml:id to all point elements, which is currently unavoidable in GML. However, this slight increase in size can be turned into an overall more compact notation through TB12.7 and TB12.8.

The goal of this change request is to reduce the gap between AIXM and FIXM through the XLink standard, so that FIXM flights have the possibility to reference AIXM features as they see fit.

This is an important improvement in terms of interoperability. Among others, this is the key enabler for automatic link resolving in Web Feature Services (WFS) through the resolveDepth="…​" parameter.

Moreover, using XLink references enables unambiguous references from FIXM flights to basic data. Currently, FIXM links to basic data solely through the use of natural keys, which is sufficent for most use cases, but does not provide referential integrity in the strict sense. For example, the names of designated points are only unique within a certain radius. This is not a problem within a single country, but provides challenges when linking datasets globally.

The following FIXM types would benefit from XLink capabilities:

Adding XLink support means appending the attribute group xlink:simpleAttrs to these types. This adds several optional attributes from the link: namespace, of which xlink:href is the most important one.

The XLink standard does not provide any restriction on the kind of URI to be linked to. Depending on the context, different kinds of links may be appropriate:

The goal of this and the following TB12.8 change request is to make the FIXM XML Schema better suited for usage in generic OGC services such as WFS or WPS, while at the same time making FIXM documents more compact, because the verbose explicit xsi:type="…​" attributes are no longer required for aerodrome (TB12.7) and point (TB12.8) references. So in contrast to the other TB12 FIXM CRs, this is not a trade-off between standards compliance and compactness, but a win-win for both interoperability and compactness.

FIXM is very restrictive in how aerodrome (fb:AerodromeReferenceType) can be specified. These are either:

In particular, it is not allowed to provide the natural key (ICAO designator) and the geometry (aerodrome reference point) at the same time. This is especially problematic since the natural key is provided in a highly FIXM-specific way, meaning these can only be resolved if the receiver has intimate knowledge about:

This is not an issue when two highly specialized systems communicate with each other, but for generic OGC services such as WFS or WPS an important interoperability aspect is that the server is able to resolve these references on behalf of the client, to facilitate displaying of FIXM datasets in generic clients.

For example, a flight from the Hartsfield–Jackson Atlanta International Airport (KATL) can be communicated to the client either as pure natural key:

or as resolved information:

Also note the verbose specification of xsi:type, whose sole purpose is to ensure that exactly one of the two sets of information can ever be provided — the natural key or the resolved information.

A simpler solution, which is at the same time more compact, would be to merge these types.

That way, the previous examples would remain valid, but in addition, a generic service would be able to provide all information it has:

For the sake of backwards compatibility, the types fb:IcaoAerodromeReferenceType and fb:OtherReferenceType should be kept as empty extensions from fb:AerodromeReferenceType, so that documents are still allowed to specify these xsi:type values, even though this is not necessary anymore. Future versions of FIXM may decide to remove these types.

This change request is the continuation of TB12.7, simplifying the various point types in FIXM. This change request may be considered even more important than TB12.7, given that typical FIXM documents contain more point specifications than aerodrome specifications.

FIXM is very restrictive in how points (fb:SignificantPointType) can be specified. These are either:

Similar to the aerodrome case in TB12.7, a generic service is unable to provide all its knowledge to the client:

By merging the point types, a service would be able to provide all information it has to the client.

For the sake of backwards compatibility, the types fb:RelativePointType, fb:PositionPointType and fb:DesignatedPointOrNavaidType should be kept as empty extensions from fb:SignificantPointType, so that documents are still allowed to specify these xsi:type values, even though this is not necessary anymore. Future versions of FIXM may decide to remove these types.

A GML profile is a subset of the GML Schema that is sufficient for a certain domain. Usually, a GML profile is related to one or more GML application schemas. For restrictions that are not expressible with XML Schema, a GML profile may provide additional business rules to further reduce the subset of GML.

For the aviation domain such a GML profile has been developed in Use of GML for aviation data which was developed mainly with AIXM in mind, but may be applicable for FIXM, too. This GML Aviation Profile reduces the set of GML geometries, the allowed coordinate reference systems, and so on.

Since FIXM also just wants to use a subset of GML, it may choose to reuse at least the XML Schema provided by the GML Aviation Profile. This will work flawlessly, because all TB12 change requests introduce only parts of GML that are used by AIXM as well.

An alternative way for FIXM may be to define its own, even more reduced, GML profile. However, this may fragment the efforts to create a GML profile for the whole aviation domain.

FIXM should make use of <gml:identifier> instead of their custom <fx:gufi> field. Both have the same structure and serve the same purpose: identifying a single GML feature through a globally unique identifier. So it is natural to reuse the existing <gml:identifier>. Also, the <gml:identifier> may receive some additional semantics in future WFS versions and related standards (possibly related to generic UUID resolution or other UUID topics). Such improvements would then be inapplicable to FIXM due to its custom <fx:gufi> identifier field.

The <gml:identifier> is already directly available to FIXM through gml:AbstractFeatureType as introduced by TB12.2. So just the <fx:gufi> element needs to be removed. However, its type fb:GloballyUniqueFlightIdentifierType should be kept as it is also used by <diversionRecoveryInformation>.

The existing restrictions on the GUFI should be provided through a business rule or through a GML Application Schema (see TB12.9).

For consistency with AIXM, the attribute value codeSpace="urn:uuid" should be changed to codeSpace="urn:uuid:", that is, with trailing colon.

A FIXM document will change from:

to:

Metadata is nowadays an essential part of data, enabling users to specify information about topics such as data identification, access, usage and quality. A widely used standard addressing such metadata requirements is the ISO 19115 model, together with its XML implementation, ISO 19139. AIXM 5 currently integrates this metadata standard by means of an optional metadata property on the feature collection, feature and time slice level.

The goal of this change request is to introduce a similar metadata property on a FIXM flight feature, enabling users to describe general metadata about the feature. One particular use case revealed in Testbed 12 is the ability to include lineage / provenance information for FIXM features in the Data Broker, to inform users about the origin of flight features in an aggregated flight data set.

The following FIXM type would benefit from an ISO 19115 metadata property:

fx:FlightType

This change request suggests to define a general metadata property in the Base XML Schema, with usage of this property in the Flight XML Schema. Having a general metadata property available in the Base XML Schema makes it easy to integrate metadata in other types in the future, depending on the need - e.g., at the message level, in extensions …​