39 Copyright © 2012 Open Geospatial Consortium.
the list of reverse associations of a feature is only distinct for a time instant. This implies that only SNAPSHOT time slices can carry reverse associations.
Example: Given
a RadarSystem R an OrganisationAuthority O1
an OrganisationAuthority O2
and the following time slices:
BASELINE 1 RadarSystem R
validTime: May - August associations: office - O1
BASELINE 2 RadarSystem R
validTime: August - December associations: office - O2
BASELINE 3 OrganisationAuthority O2
validTime: January - December BASELINE 4
OrganisationAuthority O1 validTime: January – June
What are the reverse associations of the BASELINEs 3 and 4? There is no answer that is valid for the whole validTime of the requested BASELINE. This breaks the
contract of the meaning of validTime.
The above issues show that the introduction of reverse associations increases the complexity of the AIXM model itself and especially an AIXM data store implementation. Further testing
is needed including the mentioned use cases to test whether this does not outweigh the benefits for clients.
However, the mentioned issues only apply to the introduction of reverse association as a regular property of a feature. If instead only SNAPSHOTs may carry them, they could be
generated on request by the server. The result is well defined.
Some features contain a lot of associations e.g. an AirportHeliport is linked to more than 30 other feature types. To save extra processing time on the server, the client should be enabled
to pass a parameter containing all reverse references required in the response of that specific request.
6.5 Handling non Simple Feature Geometry Types
The Aviation GML Profile defines the geometry types that should be supported by applications supporting AIXM 5.1. A number of non-simple feature geometry types are
defined in this profile: arcByCentrePoint, circleByCentrePoint, geometries containing
40 Copyright © 2012 Open Geospatial Consortium.
references to remote geometry properties. These geometry types do not have a corresponding spatial data type that is supported by any relational databases. This causes an issue for WFS
implementations that rely on querying spatial data types stored in the database when performing spatial queries.
Where this occurs, the service provider must derive a simple feature geometric representation of the geometry to support spatial filtering within the WFS. Two types of approach have been
identified to derive a simple feature geometric representation:
1. Densification: where the original geometry type is transformed into linestring or
surface geometry
2. Bounding Box: where an approximate extent is defined to represent the geometry
Both approaches were implemented by different WFS service providers in the OWS Interoperability Experiments and FAA SAA Dissemination Pilot. Differences in the level of
accuracy of a response to a spatial query were observed. The densification approach being more accurate than the bounding box approach which introduced errors of commission in the
response i.e. more features were returned.
When implementing a solution for deriving the geometry, service providers need to balance the trade off between performance and the accuracy of the response. Performance of spatial
operations is dependent on the complexity of the geometry. A spatial operation will perform faster on geometries containing fewer coordinates, therefore if the derived geometry is less
complex the request can be executed quicker.
Recommendation: A minimum acceptable accuracy level should be defined for a queries performed on non-simple feature geometry types
Eurocontrol and FAA should define a minimum acceptable accuracy level for the response of spatial filters that are performed on derived geometries for non-simple feature geometry types
to ensure consistency in the number of features returned in response to the same query by different service providers.
6.6 Enabling schema validation
