Latitude and Longitude Order in Frontend-oriented Applications

Long story short, geospatial software has no «correct» coordinate order.

Latitude and Longitude of the Earth (original image source).

In my current project, there was considerable debate within the development team about the coordinate order: Latitude, Longitude — as used by several internal and external APIs, or Longitude, Latitude — as a client-side JavaScript library Mapbox GL JS does.

There are cons for each variant:

Latitude, Longitude:

• Latitude, Longitude order follows the ISO 6709 standard;
• All real-world maps represent coordinates in the Latitude, Longitude order — it is a maritime, navigational, geographical, and cartographical tradition;
• People learned to determine latitude (through celestial observations) much earlier than longitude so that it may take precedence due to historical and «discovery» reasons;
• Since latitude represents north-south positioning, looking at the first coordinate value (latitude) allows for a rough estimation of an object’s distance from the equator — this is relatively convenient.

Highlights from the ISO standard:

• Latitude comes before longitude;
• North latitude is positive;
• East longitude is positive;
• Coordinate values (latitude, longitude, and altitude) should be delimited by spaces;
• Latitude and longitude should be displayed using sexagesimal fractions (i.e., minutes and seconds).

For example: 44°41′45.5″N 20°30′52″E 511m

Longitude, Latitude:

• Longitude, Latitude order is used in the GeoJSON format, which follows the RFC 7946 standard;
• Longitude, Latitude is a conventional order in mathematics, where the horizontal (X) coordinate (Longitude) precedes the vertical (Y) coordinate (Latitude) (see explanation in Cartesian and spherical coordinate systems);
• The ISO standard specifies the representation and input of coordinates but does not dictate how software applications store them — therefore, data can be stored in any convenient format;
• Most databases (MySQL, PostGIS, Oracle, Redis) store points as Longitude, Latitude (X, Y).

Highlights from the RFC:

• A position is an array of numbers;
• The first two elements are longitude and latitude (or easting and northing), precisely in that order and using decimal numbers. Altitude or elevation may be included as an optional third element;
• The coordinate reference system for all GeoJSON coordinates is a geographic coordinate reference system using the World Geodetic System 1984 (WGS 84) datum, with longitude and latitude units in decimal degrees.

For example: [44.695972, 20.514444]

To make an informed decision on which coordinate order is «better», I collected data on how different geospatial software represent coordinate order. The selected projects reflect only my domain area: frontend development, JavaScript APIs, and JS libraries.

Due to the lack of a table editor in Medium, check out a copy of this article with a properly formatted table and links to the documentation for all listed items.

Standards and formats

URLs

JavaScript APIs

In Yandex JavaScript API, developers can set a preferred order setting: [latitude, longitude] or [longitude, latitude], but the first one is the default.

Among other SDKs, Apple MapKit (for iOS) and Google Maps SDK (for Android) both use Latitude, Longitude order.

Libraries

Most JavaScript libraries (except Leaflet) use the GeoJSON format, which provides remarkable consistency within the JavaScript ecosystem.

Looking at the tables above, some identifiable patterns emerge in the use of coordinate order:

• In URLs, it’s better to use the Latitude, Longitude order. In fact, for all human-readable presentations and coordinate inputs, Latitude, Longitude is preferable;
• If the application relies on APIs and libraries based on the GeoJSON format, it is more pragmatic to use the Longitude, Latitude order;
• In other cases, the choice is up to you — there is no «correct» way. It depends on the application’s context.

However, the problem runs deeper. Should coordinates be represented as an ordered pair (like [44.69, 20.51]) or as an object (like {lat: 44.69, lng: 20.51})? Regardless of the choice, due to the use of multiple APIs and libraries with different coordinate notations, we will still need to convert coordinates.

«If using multiple libraries or a different combination of software in a GIS workflow, this may lead to mistakes and frustration.» Lat Lon or Lon Lat?

In my current project, we chose the {lat: 0, lng, 0} object format for several reasons:

• The lat and lng (or lon or long) keys in JSON explicitly indicate the position, eliminating the need for developers to think about coordinate order;
• Object keys are commutative, unlike an ordered pair in an array, reducing the risk of mixing up coordinates;
• Coordinates stored as keys can be used within extended objects, not just as a pair;
• Since we frequently convert coordinates between different third-party APIs and libraries, it’s better to store intermediate data in a convenient, explicit, and human-readable format to minimize errors.

To prevent errors when converting, receiving, or transferring coordinates, tests should verify the following:

• Latitude ranges between -90 and 90 degrees, inclusive;
• Longitude ranges between -180 and 180 degrees, inclusive;
• Coordinates 0, 0 is a valid point, known as Null Island.

Read further:

• Latitude, Longitude, and Coordinate System Grids;
• Lon lat lon lat and longitude, latitude is the right way by Tom MacWright;
• Lon Lat Lon Lat (Hacker News discussion);
• Preferred order of writing latitude & longitude tuples in GIS services (Stack Overflow discussion);
• Displaying coordinates and inputs as LatLon or LonLat (GIS Stack Exchange discussion);
• Latitude and Longitude;
• Longitude: The True Story of a Lone Genius Who Solved the Greatest Scientific Problem of His Time by Dava Sobel.