Elevation in Elevated Point

[marqh]

This issue is a follow up on #108, but with a focus on information encoding, not the effect of change on parsing IWXXM.

The 3.0RC1 proposes adoption of aixm:ElevatedPoint within IWXXM3 and the definition of an srsname attribute within the aixm:ElevatedPoint element. This opens up the opportunity for elevation to be expressed in multiple ways within the same aixm:ElevatedPoint instance.

Many coordinate reference systems explicitly mandate that 3-tuples of coordinates are provided, including elevation with respect to a particular, pre-defined datum. This can be significantly different from an elevation value defined with respect to another datum.

My organisation has concerns about the opportunity to specify elevation in multiple ways, that may be inconsistent.
We are also aware that elevation with respect to a particular datum needs careful calculation. It is often a significantly different value from the locally accepted value for elevation.

Given the vital nature of elevation within aviation, it is crucial that we do not exacerbate problems with specification in the move from IWXXM2.x to IWXXM3.x

An example snippet of a problematic IWXXM2 message we have seen from the UK:

      <gml:Point gml:id="obs-point-EGVN" uomLabels="deg deg m"
        axisLabels="Lat Lon Altitude" srsDimension="3"
        srsName="http://www.opengis.net/def/crs/EPSG/0/4979">  
       <gml:pos>51.76 -1.58 81</gml:pos>
      </gml:Point>

The point is expected to be at ground level, in the UK. The elevation is defined with respect to the WGS84 datum, explicitly defined by the CRS: epsg:4979. The difference between this datum and the local 'height above mean sea level' is ~45-50m in this region.

80m is a reasonable ground elevation at this location, with respect to the OSGB Datum used to define sea level (Newlyn datum, ODN height).

This example looks like an encoding error, where a local height value has been provided, but defined with respect to a different datum, the WGS84 datum defined within the epsg:4979 definition.
It is likely that the value that should have been encoded in this case is ~130m, but further calculation is required for each location, as this difference is different depending where in (x, y) position the point is.

In IWXXM2.x this would be handled as an error in the encoded data, if it was identified at all.
We have seen mistakes of this form in encoded data.
It is not clear to me whether the expectation in the aviation community is for altitude with respect to a globally defined datum such as WGS84 or for altitude with respect to a locally defined datum, closely approximating to local mean sea level, such as ODN, the UK Ordnance Survey Datum at Newlyn.

In IWXXM3 there is a proposed change that aixm:ElevatedPoint be adopted.
This means that a CRS, such as EPSG:4979, could be used, mandating that elevation with respect to WGS84 be provided within the gml:pos element.
The elevation could also be supplied, using the elevation and verticalDatum attributes on the aixm:ElevatedPoint element.
If the aixm:ElevatedPoint elevation is defined using metres above locally specified mean sea level, with respect to the local mapping agency's datum, and the gml:pos elevation is also defined, as mandated by the use of epsg:4979 then two significantly different elevation values would need to be supplied.

In the UK example case I provided, these 2 value would be of the order of 50m apart, with that difference varying dependent on location and choices of datum.

I have not yet found an example of the specification of elevation using elevation and verticalDatum attributes on the aixm:ElevatedPoint element within the RC1 examples (https://github.com/wmo-im/iwxxm/tree/master/3.0.0RC1/examples)

In summary: this ticket highlights ongoing concerns about the definition and encoding of elevation within IWXXM3

A more tightly controlled, single mechanism for specifying elevation with IWXXM3 may be significantly beneficial.
The proposal within IWXXM3.0RC1 appears to make the specification of elevation potentially more problematic than it was for IWXXM2.x.

[blchoy]

Thank you for providing a detailed description of your concern. I found the following online documentations on coding in AIXM which may give some clues to your question.

As mentioned in the AIXM coding document (see https://ext.eurocontrol.int/aixm_confluence/display/ACG/Coordinate+Reference+System), when encoding aeronautical data that complies with the WGS-84 ICAO Standard, the following Coordinate Reference System (CRS) shall be used in AIXM 5.1:

EPSG:4326 - for data conforming to the usual aviation practice (latitude first, longitude second, angles/bearings measured from the North with positive values clockwise);
OGC:CRS84 - for data conforming to the more “mathematical” practice (longitude as first axis, latitude as second axis, angles measured from the East with positive values counter-clockwise).

Other CRS which could be used can be found here: https://ext.eurocontrol.int/aixm_confluence/display/ACG/List+of+CRS+used+for+Aeronautical+Data

An example of a point coded in the aviation domain following the above practices (i.e. 2.5D instead of 3D) is available at: https://ext.eurocontrol.int/aixm_confluence/display/ACG/Point

I am not too sure if it is absolutely necessary to specify verticalDatum (see https://ext.eurocontrol.int/aixmwiki_public/bin/view/AIXM/DataType_CodeVerticalDatumType); even though vertical measurements in Annex 3 are measured AMSL we never border with the vertical datum so far with TAC.

I share with your concern that the above are just coding practices on paper and we may want to code them in schematron rules to ensure they are properly used?

[marqh]

@blchoy I am much obliged to you for the detailed follow up.

The information provided by EuroControl on IWXXM is informative.

Nowhere in their information suggests that a 3 dimensional CRS with a gml:pos including a height be used.

The examples on
https://ext.eurocontrol.int/aixm_confluence/display/ACG/Point
show use of ElevatedPoint to define the altitude.

The complexities of defining altitude with respect to a datum through gml:point and a particular CRS are significant and easy to get wrong. They are also hard to adapt to other usage. It may not be possible to find a published srsname to link to that provides for a longitude and latitude with respect to WGS84 and an altitude with respect to a local datum.

I think we should consider whether IWXXM should severely limit the choice of srsname.

https://ext.eurocontrol.int/aixm_confluence/display/ACG/Coordinate+Reference+System
states

When encoding aeronautical data that complies with the WGS-84 ICAO Standard, the following Coordinate Reference System (CRS) shall be used in AIXM 5.1:

• EPSG:4326 - for data conforming to the usual aviation practice (latitude first, longitude second, angles/bearings measured from the North with positive values clockwise);
• OGC:CRS84 - for data conforming to the more “mathematical” practice (longitude as first axis, latitude as second axis, angles measured from the East with positive values counter-clockwise).

When encoding aeronautical data that does not comply with the WGS-84 ICAO Standard an appropriate CRS shall be used. A list of CRS that are likely to be used in aeronautical data sets is provided on the page List of CRS used for Aeronautical Data. The use of other CRS falls outside the scope of this guidelines.

Would it be plausible to put in explicit rules for IWXXM3 that mandate the use of one of these 2 CRSs?

What use cases are there for future provision of other CRSs?

What use cases are there for specifying altitude within a gml:pos instead of as part of an elevated position?

Would it be possible to put in explicit rules banning the use of 3D CRSs within an srsname in IWXXM3?

I have found only 1 example using a 3D srsname: https://github.com/wmo-im/iwxxm/blob/master/3.0.0RC2/examples/metar-EDDF-runwaystate.xml#L34
Is this example meeting a particular identified use case?
aside from this example, all others use epsg:4326

If Elevated Position was to be the recommended way to specify altitude, who could assist in expanding the list of recognised datum instances? https://ext.eurocontrol.int/aixmwiki_public/bin/view/AIXM/DataType_CodeVerticalDatumType

[blchoy]

With regard to your questions:

Would it be possible to put in explicit rules banning the use of 3D CRSs within an srsname in IWXXM3?

Yes you can with schematron rules. For example, the SRS names must come from some lists (like code lists on codes.wmo.int in RDF format), gml:pos must be a duplet, etc.

Would it be plausible to put in explicit rules for IWXXM3 that mandate the use of one of these 2 CRSs?

In terms of a guidance document I think so if you are reporting in the aviation domain. Recently we were requested to align with AIRM (see #115) and I believe the idea is to reduce possible confusion when aviation users is consuming the information. I am not too sure AIXM is restricting the use of CRSs with schematron rules though. May be @porosnie could share with us his views on this.

What use cases are there for future provision of other CRSs?
What use cases are there for specifying altitude within a gml:pos instead of as part of an elevated position?

Perhaps other team members could shed some light on these?

I have found only 1 example using a 3D srsname: https://github.com/wmo-im/iwxxm/blob/master/3.0.0RC2/examples/metar-EDDF-runwaystate.xml#L34
Is this example meeting a particular identified use case?

You are right. This does not seem to be a correct example after all the discussions and I think it has to be changed.

If Elevated Position was to be the recommended way to specify altitude, who could assist in expanding the list of recognised datum instances?

Good question. But I think Eddy (@porosnie) is the right one to answer.

[porosnie]

Concerning the srsName allowed values, we restrict it at two levels:

• first, AIXM declares the use of a profile of GML 3.2.1, which is specified in an OGC document - https://portal.opengeospatial.org/files/?artifact_id=62061. See Annex A, which contains a list of the CRS that are in use in the world for aeronautical data.
• second, based on the ICAO Annexes that impose the use of WGS-84, this list is constrained further with AIXM Business Rules (see http://aixm.aero/page/business-rules). The use of any srsName different from EPSG:4326 and OGC:CRS84 is expected to be raised as an error when verifying an AIXM data set. The business rules are expressed in SBVR and their actual verification can be done with Schematron (for most of them) or other languages, but it is not part of the AIXM XML schema.

Concerning the vertical datum (ElevatedPoint.verticalDatum), ICAO requires in Annex 15 that EGM96 is used. In practice, most aeronautical data providers are unable yet to specify the datum used, for historical data it was not traced, even if probably it could be fond out. However, it is more a theoretical requirement for the moment, it is not an operationally critical element. If you need to code a verticalDatum which is not in the AIXM list, it can be done directly with the inline extension mechanism, which means that you can use "OTHER:" followed by the name of the datum in upper case. For example: "OTHER:AMSTERDAM_GAUGE".

[braeckel]

@marqh, thanks for the excellent breakdown of the issues. I fully agree that the current approach using ElevatedPoint exacerbates the ways in which things can be reported incorrectly and probably increases data producer confusion. I will note, though, that we (IWXXM) can make it easier to report the correct information but we can't prevent it from happening.

The OGC document (Eddy's first point) has a lot of situational guidance that Choy and I have previously reviewed, but this is a large document and there are quite a lot of cases to be unpacked and understood. Note that we have an existing issue open to consider adopting this document for IWXXM: #54.

If I understand correctly based on Eddy's second point AIXM appears to effectively be mandating 2-D EPSG identifiers in the srsName to enforce 2.5D representations, where the 2-D is an EPSG code and the vertical components are in the AIXM schemas. Is this correct @porosnie?

[blchoy]

I can see there are two use cases of georeferenced information in IWXXM:

1. Aviation specific entities like iwxxm:aerodrome. Because this is in aviation domain we may want to use common descriptions like aixm:AirportHeliport, aixm:ARP and hence aixm:ElevatedPoint to align with other products in the domain.
2. MET specific entities like iwxxm:SIGMETEvolvingCondition. Here we have some freedom to choose how we make the descriptions, albeit we still need to make reference to some aviation specific descriptions like "flight level".

I think there is not much to argue for (1) so I suggest to remove it from our future discussion. For (2), I agree with @braeckel that we need to have an in-depth study of #54 before we could come up with a conclusion. Should it be the work of TT-AvXML or WG-MIE? We already triggered some discussion within WG-MIE on the projection issue (#44, #52 and #53) since 2017 but we do not have a consensus yet.

[marqh]

in reply to @braeckel
#120 (comment)

If I understand correctly based on Eddy's second point AIXM appears to effectively be mandating 2-D EPSG identifiers in the srsName to enforce 2.5D representations, where the 2-D is an EPSG code and the vertical components are in the AIXM schemas.

This seems consistent with the "Use of Geography Markup Language (GML) for Aviation Data" OGC document 12-028r1
https://portal.opengeospatial.org/files/?artifact_id=62061&version=2
(limited access)

Limiting to a small number of agreed CRSs is a key facet of this profile.

There is some intent in OGC to update this document and push its status to an OGC Best Practice document, following the Aviation meeting at the OGC Technical Committee meeting in Stuttgart in September 2018

I think it would be valuable for IWXXM3 to follow this path and put targeted rules on a limited number of 2D CRSs that may be used.

[blchoy]

This was implemented in IWXXM 3.0.0RC3.