Consider adopting "Use of GML for Aviation Data" as an IWXXM convention

[braeckel]

The OGC Best Practices paper (https://portal.opengeospatial.org/files/?artifact_id=62061) specifies many best practices for using GML to specify geospatial information for both generic GML constructs (like ArcByCenterPoint) as well as AIXM-specific constructs like Airspace and how points should be specified. This is quite mature and other than needing to be generalized slightly for non-AIXM data is an excellent set of practices for geospatial data. The adoption of this document as an IWXXM practice may suggest that #52 and #53 should be closed or merged into this issue. This issue should be expanded upon to include the specific changes to examples and other documents that would be required for IWXXM adoption.

[blchoy]

Thanks Aaron for the article and I am sure we could use this as a basis for representation of weather objects. Note, however, that an originator may only be able to create weather objects in Mercator projection (they could be using a pen, a ruler and a Mercator projection map) or has software limitation, especially for smaller NMHSs with less advanced facilities than those in WAFCs.

The original intent of #52 and #53 are to make sure that weather objects in IWXXM are adequately represented with respect to the projection they are prepared. #54 relates to how these weather objects should be prepared. I think once the underpinning model of IWXXM and examples supports #52 and #53 we should close them accordingly. But for #54 since it involves a possible change in existing State practices we may want to raise this in the upcoming WG-MIE meeting for ICAO's consideration.

[braeckel]

I would like to note that the points don't necessarily need to be expressed in Mercator for the lines between points to be interpreted in Mercator. The points could be expressed in any coordinate system and the software that displays it would then draw/calculate the lines in between.

The implications of this approach would be that there may be an extra coordinate system transformation for getting the points into a Mercator projection so that the lines can be calculated. In other words consumers would have to be able to transform from IWXXM CRSs to the Mercator CRS of their choice to calculate a polygon.

From the referenced document, Section 6.3:
'According to ICAO Annex 15, all “published aeronautical geographical coordinates (indicating latitude and longitude) shall be expressed in terms of the WGS-84 geodetic reference datum”'

Further down in this section states a requirement for data that "complies with the WGS-84 ICAO Standard":

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

Given the Annex 15 requirement and AIXM best practices I suggest that we adopt a similar approach. We could adopt the document as-is and put a specific recommendation to use EPSG:4326 in most cases into our documentation (perhaps the TAC to XML Guidance document). If so we could then close #52 and #53.

[blchoy]

I agree with your suggestions but how about the latter part of my proposal in #52, viz the use of EPSG:3395 (only) for SIGMET objects until ICAO lifted the requirements that the lines connecting the coordinates should be in Mercator projection? I have no further questions for closing #53 as it is well understood, thoroughly discussed and will be followed up in this thread.

[braeckel]

With regards to EPSG:3395, it looks like it may be broadly useful choice for Mercator but may not be appropriate in all cases. This specific projection does not extend to the poles (only includes latitudes between 80°S and 84°N), and is centered on 0° longitude. For use with air traffic between Asia and the Americas it may not be the best choice as can be seen in http://spatialreference.org/ref/epsg/wgs-84-world-mercator/, due to the choice of central meridian.

For use with points it is clear that EPSG:4326 (and likely EPSG:4979 for 3-D points) should be used. However, after reading the section on surfaces and polygons again I must retract my earlier comment about the points and lines being in different CRSs. When an srsName is declared it appears to apply to both the points and the lines drawn between the points. I suggest that we contact a few geodesy experts to be sure we fully understand how ArcByCenterPoint, Surface, and Polygon should be defined based on the contents of these best practices.

[blchoy]

I think this is not a matter of choice but a regulatory requirement in Annex 3 as mentioned in #52; we only faithfully reflect this in the IWXXM representation for VA advisory and SIGMET objects which is not obvious in their TAC counterparts. As you mentioned in previous posts, the rendering software needs and should understand this information and render the line between the points appropriately in the target projection. This rendering requirement should also apply for lines on EPSG:4326; if the target projection is Mercator and the lines are neither meridians nor parallels, they may not be a straight line on the target projection.

No doubt that we need advise on whether ArcByCenterPoint, etc. works as we think, but who can we ask?

[braeckel]

A critical question would be whether we should provide guidance on how polar routes should be handled. EPSG:3395 and EPSG:4326 may not be suitable for this case

[marqh]

in reply to @braeckel
#54 (comment)

I would like to note that the points don't necessarily need to be expressed in Mercator for the lines between points to be interpreted in Mercator. The points could be expressed in any coordinate system and the software that displays it would then draw/calculate the lines in between.

The implications of this approach would be that there may be an extra coordinate system transformation for getting the points into a Mercator projection so that the lines can be calculated. In other words consumers would have to be able to transform from IWXXM CRSs to the Mercator CRS of their choice to calculate a polygon.

From the referenced document, Section 6.3:
'According to ICAO Annex 15, all “published aeronautical geographical coordinates (indicating latitude and longitude) shall be expressed in terms of the WGS-84 geodetic reference datum”'

I think some caution is valuable here. It is a strong principle in geographic information software and standards that if a 'line' is defined by a start point and end point in a particular coordinate reference system, then the line is the shortest distance between those points in that coordinate reference system.

To define a line as the shortest distance between two points, once those points have been converted to a different coordinate reference system is a potentially problematic process, that could lead to significant issues for software and human interpretation.

A characteristic of the Mercator projection is that it is an angle preserving projection. This specifically means that straight lines in a Mercator projection are Rhumb Lines (https://en.wikipedia.org/wiki/Rhumb_line)

So a straight line drawn in a Mercator projection is not a straight line drawn in geographic space, a great circle
(https://en.wikipedia.org/wiki/Great_circle
https://en.wikipedia.org/wiki/Great-circle_distance)
(https://gisgeography.com/great-circle-geodesic-line-shortest-flight-path/)

Thus, the polygon in example
https://github.com/wmo-im/iwxxm/blob/master/3.0.0RC2/examples/sigmet-A6-1a-TS.xml#L90
is a polygon defined by a set of points with respect to the WGS84 datum and ellipsoid (epsg:4326) and the straight lines between those points as defined within that geographic coordinate system.

These lines are great circles. In a Mercator projection they will not be straight lines, they will be curved.

Similarly the circle defined in
https://github.com/wmo-im/iwxxm/blob/master/3.0.0RC2/examples/sigmet-A6-2-TC.xml#L94
is a circle as drawn on the WGS84 ellipsoid.
If it is represented on a Mercator projection, or any other projection, I would expect software to project the shape and represent it with the appropriate distortions.

I am concerned that defining a polygon by a set of points in one CRS but having the 'straight lines' defined in another projection may not be supported by GML, by design, and hence it will never will be supported.

However, after reading the section on surfaces and polygons again I must retract my earlier comment about the points and lines being in different CRSs. When an srsName is declared it appears to apply to both the points and the lines drawn between the points.

I agree.

The requirement in #52 that lines are defined in a Mercator projection would lead me to want to encode the points defining that line in the same Mercator projection. This in turn would lead me to want to ensure that if #120 limited the choice of srsname that an appropriate Mercator projection was included in that list.

As already observed, there are multiple Mercator projections defined within EPSG, many using WGS84 as the base CRS, with different central meridians and with different limited extents

The document
Use of Geography Markup Language (GML) for Aviation Data
OGC# 12-028r1
https://portal.opengeospatial.org/files/?artifact_id=62061&version=2
discusses this topic in section 8

but it is not clear to me how the encodings relate to the core GML definitions and principles. In particular the statements:

8.2.2. Parallels
In the AI domain, if an Airspace border has two consecutive points at the same geographical latitude, it is assumed that the line between the two points is “along the parallel”. This shall be encoded in AIXM/GML using “linear” GML elements in combination with a geodetic CRS, such as EPSG:4326.

in the particular case where one wants to express a rhumbline whereas the two consecutive latitudes are different, a gml:LineStringSegment with a "Mercator" CRS like EPSG:3395 may be used. However, this is a theoretical discussion since no real world aeronautical data like is known to require the use of arbitrary rhumblines.

OGC 12-028r1 Copyright © 2016 Open Geospatial Consortium

give me cause to pause and worry.

This is likely to be a topic of interest for the review and updating of this paper planned within the OGC Aviation Domain Working Group over the coming months

notify: @porosnie for your information and interest