Plate 01Latitude first, or longitude first
The coordinate pair looks simple until you realise two conventions are in wide use — and they disagree about which number comes first.
A satirical sheet of Europe. No map states which of the pair was written first — the file has to say so itself.
Photo: Satirical map, L’Europe en Ce Moment · Wikimedia Commons
The axis swap that breaks data quietly
Mathematically, a position needs two numbers: one for north-south, one for east-west. The question is which you write first. Geography inherited the latitude-longitude order from printed navigation tables and the tradition of "how far north or south, then how far east or west." That order — latitude, then longitude — is how most cartographers still think, and it appears in ISO 6709, in most datum specifications, and in the way field surveyors report positions.
Software inherited a different instinct. Computational geometry treats coordinates as (x, y), and on the globe x maps naturally to east-west — that is, longitude — and y to north-south — latitude. So the order flips: longitude first, latitude second. GeoJSON, for instance, mandates longitude before latitude, following the (x, y) convention. WKT geometry does the same.
The result is that two perfectly accurate numbers can land a point in the wrong place, symmetrically swapped across the diagonal where latitude equals longitude — which on the globe is a line running through the Gulf of Guinea, Libya and Turkey. A point meant for [51.5 N, 0.1 W] becomes [51.5 E, 0.1 S] if the parser and the source disagree: somewhere in the Indian Ocean off Somalia instead of central London.
The failure is especially treacherous because it is silent. The coordinates parse without error. The point appears on the map. It is simply somewhere else — and if the destination country or ocean feels plausible, nobody notices immediately. The Gulf of Guinea problem — coordinates defaulting to 0, 0 — gets attention because the point lands in the ocean and looks obviously wrong. The axis-swap failure looks fine.
Plate 2Line weight was a physical choice before it was a style rule — one nib, one width, and the hierarchy came from the set.
Photo: Thirdman / Pexels
Fixing it requires knowing the convention of every data source you consume and every sink you write to, and converting explicitly at the boundary, not assuming. Pipe a latitude-first CSV into a longitude-first geometry engine and you have introduced an error with no warning.
There is no universal resolution. The ISO standard and the GeoJSON RFC disagree, and both are authoritative within their domains. Some APIs document their convention clearly; many do not. The safe habit is to treat every coordinate pair as ambiguous until the source documentation confirms the order, and to label columns or fields — lat and lon, or x and y — so the intent survives any downstream shuffle. A header row costs nothing; a silently transposed dataset can cost a great deal.
Also in Datums & Coordinates