Correct way of representing SIGMET polygons that cross the dateline

[borisburger]

Hello,
has there been any discussion regarding GML polygons that cross the dateline? Both EPSG:4326 and EPSG:3395 that are the most commonly mentioned projections in context of IWXXM have bounds that range from -180 to +180 with central meridian at 0 degrees longitude:

• https://epsg.io/4326
• https://epsg.io/3395

Take for example this SIGMET in New Zealand Oceanic FIR (ICAO: NZZO) that crosses the dateline (pardon the crude drawing):

For TAC SIGMET output, we store the 4 latitude/longitude coordinates in CW order (plus the 5th one to close the polygon), e.g. WI S4700 W17400 - S5400 W17600 - S5400 E17600 - S4600 E17800 - S4700 W17400. Annex 3 does not really say, which particular parametrization of Mercator should be used to connect the points (i.e. which central meridian to use). The assumption likely is that the end-user or software used for display is clever enough to deduce that this is a polygon that spans the dateline and interpret it as the forecaster meant.

IWXXM/AIXM/GML however are much more precise in the usage of projections, so in the case of EPSG:4326 or EPSG:3395 the projection bounds or central meridian are a part of the CRS definition.

Our software would store the above polygon in EPSG:4326 like this (potentially wrong, but we are not sure):

<aixm:Surface gml:id="uuid.ae8ce712-798d-418c-8bcc-4662b4d2d98a" srsDimension="2" axisLabels="Lat Long" uomLabels="deg deg" srsName="http://www.opengis.net/def/crs/EPSG/0/4326">
  <gml:patches>
    <gml:PolygonPatch>
      <gml:exterior>
        <gml:LinearRing>
          <gml:posList>-46.00 178.00 -54.00 176.00 -54.00 -176.00 -47.00 -174.00 -46.00 178.00</gml:posList>
        </gml:LinearRing>
      </gml:exterior>
   </gml:PolygonPatch>
  </gml:patches>
</aixm:Surface>

GML requires for exterior rings to be in CCW order. The above points are arguably not CCW - assuming that the CCW rule is relative to the specified CRS, and the above is not really CCW in EPSG:4326, strictly speaking.

If one shifted the longitudes by 180 or 360 to the east, then it would be really counter-clockwise. Or if we used longitude 184 in place of -176, then it would be more clear and CCW. But the problem with such shifted polygons is they would be out of the bounds of EPSG:4326 that end at 180.

If the polygon is written like the above within the -180 to 180 bounds of EPSG:4326, a lot of GIS software would probably interpret the polygon like this:

I was looking at the OGC Use of Geography Markup Language (GML) for Aviation Data (https://portal.opengeospatial.org/files/?artifact_id=62061) but this best practices document does not seem to address the dateline issue.

In the following ESA document https://wiki.services.eoportal.org/tiki-download_wiki_attachment.php?attId=653&usg=AOvVaw3ol5sRYun_Pbb1HvCyyjN5 the same issue with GML and dateline is mentioned in section 3.3
ENCODING RULES FOR GEOMETRIES TO AVOID DATELINE ISSUE from page 24 onwards. They offer some alternative solutions:

1. Forbid dateline crossing polygons - so for example in our case (e.g. EPSG:4326 or EPSG:3395) this would mean splitting polygons that cross dateline into two separate exterior linear rings. We have seen this practice used in for example FIR Shapefile maps where the New Zealand Oceanic FIR is encoded as two separate polygons. I do not have other examples at hand but have definitely seen this practice multiple times.
2. Represent the polygon in another CRS that does not have the issue - one where the central meridian is not the Greenwich meridian... I am not sure if there are any EPSG/CRS codes for suitable geodesic or Mercator projections that are rotated e.g. 180 degrees though...
3. Specify coordinates outside the normal value range - e.g. using longitude 184 instead of -176, but I think then such coordinates would be outside of EPSG:4326 bounds.
4. Store the coordinates within EPSG:4326 bounds (as in the aixm:Surface example code above) but declaring a convention that if the points are close to each other on the WGS84 ellipsoid, than the software should be clever enough to figure out what is going on.

From these solutions I have a strong feeling only the first two are correct in terms of the GML specification strictly speaking (splitting the polygon in two, or using a CRS which is rotated by e.g. 180).

Any guidance on this subject is really appreciated.

Boris

[blchoy]

This is not a new issue and we had already have some discussions on this topic (see #217).

If we accept dirty methods, as we can specify CRS for individual geometric objects, the easiest thing we can do is to put objects into CRSs with the same datum/ellipsoid but different meridian (e.g. 0 or 180 degrees longitude) to avoid the dateline issue and let the consuming software decide what to do with these objects. Nevertheless, I am not aware such CRSs exist.

May be @porosnie could give us updates on this topic?

[borisburger]

Perhaps there is no suitable well-known CRS that would represent "EPSG:4326 centered at the anti-meridian", nor anything of the sort. I spent some time looking through PROJ library's database of well known projections and found nothing suitable.

Instead of a reference to a well known CRS we could potentially put a full definition of a CRS in GML, similar to http://www.opengis.net/def/crs/EPSG/8.5/4326 but with a different central meridian. I am not really a fan of custom CRS definitions, because it would greatly increase the burden on the side of IWXXM consumers who would have to be able to fully interpret these CRS definitions. That is not an easy task. Surely with the right combination of PROJ/GDAL/other packages one should be able to construct the projection equations, but it seems like an overkill.

There still remains the workaround with splitting the polygons at the date line, and storing 2 or more LinearRings. If I am not mistaken, this would not be a valid IWXXM 3.0. But is there any other option (besides defining a custom CRS) that would conform to all the standards?

[borisburger]

Small update. @jkorosi found out that there are projections that have central meridian elsewhere:

• EPSG:8858 Equal Earth Americas http://www.opengis.net/def/crs/EPSG/0/8858 (https://epsg.io/8858)
• EPSG:8859 Equal Earth Asia-Pacific http://www.opengis.net/def/crs/EPSG/0/8859 (https://epsg.io/8859)

That being said, I believe (and Jan agrees) that the data consumers would be taken completely off-guard by use of such CRS.

In GeoJSON, the specification authors originally considered allowing any CRS to be specified, but finally settled on CRS 84 to be used for everything, and they also explicitly suggest to split any features that cross the antimeridian. There are some interesting explanations of the reasoning behind this in the GeoJSON spec https://tools.ietf.org/html/rfc7946.

Section 4:
The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system, using the World Geodetic System 1984 (WGS 84) [WGS84] datum, with longitude and latitude units of decimal degrees. This is equivalent to the coordinate reference system identified by the Open Geospatial Consortium (OGC) URN urn:ogc:def:crs:OGC::CRS84.

Note: the use of alternative coordinate reference systems was specified in [GJ2008], but it has been removed from this version of the specification because the use of different coordinate reference systems -- especially in the manner specified in [GJ2008] -- has proven to have interoperability issues. In general, GeoJSON processing software is not expected to have access to coordinate reference system databases or to have network access to coordinate reference system transformation parameters. However, where all involved parties have a prior arrangement, alternative coordinate reference systems can be used without risk of data being misinterpreted.

3.1.9. Antimeridian Cutting

In representing Features that cross the antimeridian, interoperability is improved by modifying their geometry. Any geometry that crosses the antimeridian SHOULD be represented by cutting it in two such that neither part's representation crosses the antimeridian.

We definitely agree that the processing software might not have access to CRS databases, or to a library that is able to interpret the CRS down to the real equations for converting between lat/lon and the given CRS. Full blown GIS software might be able to do that, but not all IWXXM consumers will have such sophisticated tools at hand.

BTW the GeoJSON spec also describes what @jkorosi seems to call "Choy's bounding box trick", the thing that you suggested in the SWXA thread: https://tools.ietf.org/html/rfc7946#page-14 section 5.2 The Antimeridian (in Section 5 Bounding Box).