Best-practices for databases and APIs with geographic data spanning the antimeridian [closed]

Question

What is the best-practice for storing geographic features (lines, polygons and their multipart equivalents) when these features span the antimeridian (±180° longitude), and need to be sent to and recieved from client web applications as GeoJSON?

---

I am starting work on a server-side web API with support from a Postgres/PostGIS database to work with historical and forecast tropical cyclone tracks and wind radii. Many cyclones in the Pacific Ocean have the unfortunate tendency to cross the antimeridian, sometimes multiple times in their lifespan:

As a New Zealander living near the antimeridian, I have encountered this problem often enough in regional data to have some coping strategies, but I would like to actually find out what is considered to be best practice. Unfortunately there are no existing questions tagged antimeridian, so it is hard to search for related questions. Those questions that I have seen struggling this problem all seem to be seeking very application-specific advice. This question briefly discusses the antimeridian for the case of an earth-spanning GeoJSON polygon with no boundary. This question is pretty close to what I'm asking.

I need to store historical and forecast cyclones in a spatial database, but I anticipate that there will be issues with the antimeridian. For instance, a line starting at latitude/longitude (0,179) and ending at (0,-179) is ambiguous with respect to its direction: whether it takes the short path across the antimeridian, or "wraps" around the entire planet. How should such a path be stored in a spatial database (specifically I'm working with PostGIS but I hope the solution is generic enough)? Some ideas that I have:

1. Make no change to feature geometries and shift the ambiguity to client applications.
2. Split any feature crossing the antimeridian into a multipart geometry with a break at the antimeridian. (The GeoJSON specification supports named CRSs.)
3. Work with non-global projections for different cyclone basins or oceanic regions that don't have such a discontinuity
4. Exploiting the fact that a cyclone has never been observed to travel around the entire planet, store the coordinates of cyclones starting in the latitude range (90,-90) offset by a 360° phase (keeping the others -180–180°)
5. Exploiting the fact that a cyclone is extremely unlikely south of the southern tip of Africa, use a break at 30° longitude (as in the above map).
6. Allow coordinates to extend beyond the valid range of EPSG 4326, e.g. > 180° and < -180° for any features that pass the antimeridian.
7. Delta encoding, like in TopoJSON (e.g. start at (0,-179) and then next coordinate is -3 latitude west). I have no idea whether or how to implement this when storing data in PostGIS, but this is a great solution for sending data to client applications.
8. Some form of vector notation or polar coordinates. (Seems rather difficult and unusual.)

Of these, I don't like ideas 2–5 because they aren't generic, but I do like them because they make some sense for my particular application. For applications only dealing with data in the Pacific Ocean, they might make a lot of sense, so I don't want to completely discount them as options.

Ideas 6 and 7 were lifted from Tom MacWright's blog, which is worth a read but is not conclusive with respect to the antimeridian.

Idea 4 is used by GeographicaGS' GeodesicLinesToGISPython, which in turn is using fiona.transform.transform_geom with a 360° antimeridian offset. In turn, Fiona is using OGR's -wrapdateline. I suppose that's a very solid precedent and actually rather generic.

In conjunction with the issue of storage, I need to consider how such features should be sent to client applications, and how my application should consider data posted back to it (e.g. a human forecaster changing the forecast track of a cyclone in the Pacific). The interchange format will probably be GeoJSON, but does not have to be.

Unfortunately the GeoJSON specification is not explicit about antimeridian issues. This from Wikipedia:

Many geographic software libraries or data formats project the world to a rectangle; very often this rectangle is split exactly at the 180th meridian. This often makes it impossible to do simple tasks (like representing an area, or a line) over the 180th meridian. Some examples:

• The GeoJSON specification doesn't mention handling of the 180th meridian in its specification, as such, representations of lines crossing the 180th meridian can just as well be interpreted as going around the world.

• In OpenStreetMap, areas (like the boundary of Russia) are split at the 180th meridian.

My reading is that GeoJSON has no particular standard representation of antimeridian-spanning features, and it is deliberately left ambiguous (multi-part geometries would perhaps resolve the issue). Similarly in OpenStreetMap there are geometry divisions at the antimeridian, although I don't know if such split features are multipart or are actually discrete records.

This feels rather problematic, especially from the perspective of making bounding box or other spatial requests that span this line, but also in parsing and sanitising input and any updates to feature geometries. This is why I'm trying to determine a best practice that I can seek to conform to.

Answer 1

Speaking purely from a data storage and analysis perspective, the geography type for PostGIS was designed with the antimeridian in mind (among several design goals). There are several functions specifically designed for the geography type.

For instance, consider a LineString across Taveuni, Fiji (mapped with Great Circle Mapper), which straddles the antimeridian:

SELECT ST_Length('LINESTRING(179.9 -17, -179.8 -16.7)'::geography);

The length of this geodesic is about 46 km. Similarly, ST_Area would work correctly on a Polygon of the island, even with longitude coordinates jumping between +179 and -179.

Casting a EPSG:4326 geometry to a geography type also normalizes the coordinates, for example the longitude of the last coordinate is >180:

SELECT ST_AsGeoJSON('LINESTRING (179.9 -17, 180.2 -16.7)'::geography);

NOTICE:  Coordinate values were coerced into range [-180 -90, 180 90] for GEOGRAPHY
                           st_asgeojson
------------------------------------------------------------------
 {"type":"LineString","coordinates":[[179.9,-17],[-179.8,-16.7]]}

is converted back to the exact same geography type in the first example, but now with GeoJSON output. You can choose to ignore the NOTICE (or e.g. SET client_min_messages TO WARNING;), and convert all sorts of funny-looking geometries as geography types.

---

Showing geography types on maps outside PostGIS is a different story, and hopefully better answers will touch on this aspect.

Answer 2

Surely, the preferred answer is (1), i.e., have clients do the "right thing". A good case to consider is the polygon representing the continent of Antarctica approximated by this kml file

<kml> <Folder> <name>Antarctica</name> <Placemark> <name>Antarctica</name> <Polygon> <tessellate>1</tessellate> <outerBoundaryIs> <LinearRing> <coordinates> -58,-63.1,0 -74,-72.9,0 -102,-71.9,0 -102,-74.9,0 -131,-74.3,0 -163,-77.5,0 163,-77.4,0 172,-71.7,0 140,-65.9,0 113,-65.7,0 88,-66.6,0 59,-66.9,0 25,-69.8,0 -4,-70,0 -14,-71,0 -33,-77.3,0 -46,-77.9,0 -61,-74.7,0 -58,-63.1,0 </coordinates> </LinearRing> </outerBoundaryIs> </Polygon> </Placemark> </Folder> </kml>

Delta encoding or shifting where the longitude break occurs won't help with data like this. Working it a projection specific to Antarctica will work, but this is hardly a general solution.

Amazingly, Google Earth Pro doesn't display this polygon correctly (unless you use "outline" mode). See here