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:

enter image description here

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 , 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.

  • 1
    That's a really good question, previously I've used a hand made coordinate system starting at 90 degrees but I was only concerned with a very small area. There really isn't anything to 'wrap around' properly; I'm guessing it's because there's no landmass (of importance) straddling 180 and very few people have to map over it the whole problem receives very little attention. May 4, 2016 at 3:40
  • Great question. I think you are tempting fate with point 4, although in practice there is no reason why coordinates could not extend beyond 360, using mod to recover them. Delta sounds like the most extensible solution, and could even have some benefit in terms of data compression, but, as you say, shifts responsibility to the client. May 4, 2016 at 6:29
  • Some of the comments about GeoJSON are now out of date since the 1.0 RC. One example is that CRS definitions in GeoJSON are deprecated (sgillies.net//2014/08/06/pruning-crs-from-geojson.html). I'll edit this eventually. Sep 26, 2016 at 20:44

2 Answers 2


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

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.

  • 2
    One limitation is that a geography should be no longer/wider than 180º (see advanced FAQ). However, you could just use this rule for the vertexes and do something silly like this: LINESTRING(179.9 -17, 60 -16.9, -60 -16.8, -179.8 -16.7), which sort-of wraps around.
    – Mike T
    May 4, 2016 at 11:15

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 screen shot from Google Earth Pro

  • I don't know much about Google Earth, so I don't know how to enable outline mode. But here you have a valid polygon that spans the antimeridian and in your image we see that Google Earth fails to render it correctly: so how is this evidence that passing the ambiguity to the client application is best practice if Google Earth can't cope with it? Incidentally QGIS gives me rendering issues with this polygon in SRID 4326, but not if I introduce a line at the antimeridian (except... well the line). The original renders brilliantly if I use an Antarctic Stereographic projection. May 7, 2016 at 0:18
  • Fair enough. However, given that kml coordinates are restricted to latitude and longitude, there's nothing that you, the user, can do to help Google Earth in this particular example. The onus is on the Google Earth maintainers to fix this problem on the client side. (Unfortunately, they show little inclination to do so!)
    – cffk
    May 7, 2016 at 0:46

Not the answer you're looking for? Browse other questions tagged or ask your own question.