Geographic Coordinate Systems: Latitude and Longitude on an Ellipsoid

A geographic coordinate system is the family of coordinate systems that uses latitude and longitude in degrees on an ellipsoidal model of Earth. Every GPS receiver, GeoJSON file, and modern web mapping API stores and transmits coordinates in this family — almost always referenced to WGS84 (EPSG:4326). The /learn/coordinate-systems-overview pillar covers all four families; this article goes deeper on the geographic family specifically.

The geographic-CRS model

Per ISO 19111:2019, a geographic coordinate reference system is built from three layers:

1. An ellipsoid — a mathematical model of Earth's shape. The common ellipsoids are WGS 84, GRS 80 (the basis of NAD83 and ETRS89), and the older International 1924. Each is specified by its semi-major axis (a) and flattening (f); the NGA WGS 84 parameters are a = 6,378,137.0 m and f = 1/298.257223563.
2. A datum — the rules that fix the ellipsoid's position and orientation in space, anchored to physical observations (originally trigonometric stations, now continuously-observed GNSS reference networks). The future article on geodetic datums covers this layer in depth.
3. A coordinate system — the axes and units. For a geographic CRS, the axes are latitude and longitude, and the unit is the degree (with the option of radians or gradians in some formulations).

The combination of an ellipsoid, a datum, and a coordinate system is a coordinate reference system. EPSG codes name full CRSs:

• EPSG:4326 — WGS84 datum + geographic CS in degrees
• EPSG:4269 — NAD83 datum + geographic CS in degrees
• EPSG:4258 — ETRS89 datum + geographic CS in degrees

Components: latitude, longitude, height

A 2D geographic coordinate is a pair: (latitude, longitude). A 3D geographic coordinate adds a height: (latitude, longitude, height). The latitude–longitude part is well-defined within the CRS; the height is more nuanced.

Latitude is the angle, measured at the centre of the ellipsoid, between the equatorial plane and the line from the centre to the point — almost. The /learn/what-is-latitude pillar covers the geodetic-vs-geocentric distinction; the short version is that geodetic latitude (used by every modern CRS) is the angle between the equatorial plane and the normal to the ellipsoid at the point, not the line through the centre. The two latitudes differ by up to ~11 arc-minutes at 45°. Modern GPS, every EPSG geographic CRS, and every web mapping API use geodetic latitude.

Longitude is the angle, measured from the prime meridian, to the meridian passing through the point. Positive east, negative west, in the range [−180, +180].

Height comes in two flavours:

• Ellipsoidal height — the height above the WGS84 (or other) ellipsoid. This is what raw GPS receivers output. The ellipsoid is a mathematical surface that does not match mean sea level; ellipsoidal heights at the same point can differ from sea-level heights by tens of metres.
• Orthometric height — the height above a model of mean sea level (the geoid). Vertical datums like NAVD88 (US), Newlyn (UK), and EGM2008 (global) define geoid models for converting from ellipsoidal to orthometric.

In ISO 19111 terms, the horizontal CRS and the vertical CRS are separable concepts. Many workflows store horizontal-only geographic coordinates and carry vertical references separately. The /tools/elevation tool reports orthometric height (USGS 3DEP or OpenTopoData SRTM30m) alongside the input geographic coordinate.

Common geographic CRSs

The geographic CRSs that account for the overwhelming majority of real-world traffic:

| EPSG | CRS name | Datum | Use | | ------- | --------------------- | --------------------- | --------------------------- | | 4326 | WGS84 geographic | WGS84 (G2139 epoch) | GPS, GeoJSON, web APIs | | 4269 | NAD83 geographic | NAD83 (2011 epoch) | US federal mapping | | 4258 | ETRS89 geographic | ETRS89 | European data (INSPIRE) | | 4267 | NAD27 geographic | NAD27 | Legacy US data (pre-1983) | | 4322 | WGS72 geographic | WGS72 | Legacy GPS data (pre-1987) |

Within the continental US, the WGS84-to-NAD83 difference is approximately 1–2 metres in horizontal position. ETRS89 was originally aligned with WGS84 in 1989 but the two have diverged by roughly 50 cm in mainland Europe owing to continental drift; ETRS89 is intentionally fixed to the Eurasian plate, while WGS84 follows the centre of mass of the whole Earth.

Sub-metre work always carries the specific CRS — “WGS84” versus “NAD83(2011)” versus “NAD83(NSRS2007)” versus “ETRS89” are all distinct, and conflating them costs ~1 m of accuracy in CONUS and similar in Europe.

A worked illustration of the inter-datum offset, using a published NGS coordinate for a survey point near the Washington Monument. In WGS84, the point has longitude approximately -77.0353. In NAD83(2011), the same physical point sits at approximately -77.0353 — visually identical, but the difference at the seventh decimal corresponds to roughly 1 m of horizontal shift between the two reference frames. This shift is real and consistent across CONUS; it is the reason NGS NCAT exists as a transformation service. Datasets that ignore the datum entirely produce results within the GPS-accuracy budget for navigation, and quietly fail at the metre-scale work surveyors and infrastructure engineers care about.

Geocentric versus ellipsoidal forms

Geographic CRSs come in two related forms in ISO 19111 and the EPSG registry:

• Ellipsoidal (the common form) — latitude, longitude, and optionally ellipsoidal height. EPSG:4326 (WGS84 2D) and EPSG:4979 (WGS84 3D) are examples. The coordinates are angles plus optional height; what every web mapping and GPS workflow uses.
• Geocentric (the Cartesian form) — three orthogonal X, Y, Z axes with origin at the centre of the ellipsoid. EPSG:4978 is WGS84 geocentric. Values are in metres along each axis. This form is used internally by satellite-orbit calculations, geodetic transformation arithmetic, and some scientific applications, but almost never surfaced in human-facing or GIS workflows.

Both forms describe the same physical points and are interconvertible by closed-form formulas. The ellipsoidal form is the surface-friendly view; the geocentric form is the satellite-friendly view.

Axis order in practice

Geographic coordinate systems do not all agree on the axis order. ISO 19111 — and the cartographic convention going back centuries — specifies latitude first. GeoJSON (RFC 7946), WKT (OGC Simple Features), PostGIS, and KML specify longitude first. The full treatment is in /learn/why-latitude-comes-first; in short, the order question is settled at every system boundary, never assumed.

In practice, when accepting geographic coordinates as a CRS-tagged pair (with EPSG code), most modern parsers either accept the order specified by the standard's axis-order metadata, or specify which order they expect in the documentation. PROJ versions ≥ 6, for example, follow the EPSG-registered axis order by default — which means EPSG:4326 is treated as latitude-first, contrary to the GeoJSON convention. Code that bridges between the two has to be explicit about which axis comes first at every API boundary.

A concrete example of the contradiction. A GeoJSON Point with coordinates [-73.9857, 40.7484] is the Empire State Building — longitude first, latitude second, per RFC 7946. Loading the same coordinate string into PROJ 6+ and asking for the EPSG:4326 axes returns (40.7484, -73.9857) — latitude first, longitude second, per the EPSG registry. Both are correct for their respective tools. Pipelines that move data from GeoJSON-emitting sources to PROJ-consuming destinations need an explicit swap (or a CRS reprojection that handles the axis swap implicitly). The /learn/why-latitude-comes-first support article walks through the four detection patterns for order-swap bugs.

Units

The default unit of a geographic CRS is the degree — specifically, the decimal degree. The angular formats (/learn/coordinate-formats-explained) DD, DMS, and DDM are all degree-based.

Alternative units occasionally appear:

• Radians — used internally in trigonometric calculations (Vincenty, haversine, projection formulas). Conversion is radians = degrees × π / 180.
• Gradians (gons) — 400 gradians in a full circle, occasionally used in European surveying contexts.

In every exchange format, the unit is part of the CRS specification. EPSG records the unit explicitly for each CRS; deviations from the expected unit are a frequent integration-bug source.

When to use geographic — and when not to

Geographic coordinate systems are the right choice when:

• The data is global or crosses regional boundaries.
• The consumer is a web map, a public API, or a GeoJSON pipeline.
• The data exchanges with GPS, satellite imagery, or geodetic reference networks.
• Display precision (a few metres) is acceptable for the task.

Projected coordinate systems (the sibling /learn/projected-coordinate-system article) are the right choice when:

• Distance and area must be computable directly from coordinates.
• The work is regional (within a single UTM zone, single state plane, or single national grid).
• Engineering, surveying, or infrastructure work demands sub-metre consistency in linear measurements.
• The data joins with existing planar maps or grid systems.

The hybrid pattern — geographic for storage and transport, projected for computation — is common and usually correct. Convert at the compute boundary, store in geographic.

Common misconceptions

“Geographic coordinates are 3D by default.” Most EPSG geographic CRSs are 2D — latitude and longitude only. 3D variants exist (e.g., EPSG:4979 is WGS84 3D geographic, with ellipsoidal height), but the common case is 2D plus a separate vertical reference.

“Latitude and longitude are always in degrees.” Almost always. EPSG records the unit explicitly per CRS; a small number of specialised CRSs use gradians. The default in everyday work is decimal degrees.

“Geographic CRSs are not coordinate systems because they don't use metres.” Geographic CRSs use angular units (degrees), and that is by design. Distance work is a separate concern — geodesic formulas like Vincenty's convert angular coordinates to ground distance when needed.

“Distance calculations are unreliable on geographic coordinates.” Distance from geographic coordinates is mathematically well-defined; it just isn't linear. Vincenty's formula on WGS84 yields millimetre-accurate distances for any two points; haversine on a sphere is faster but loses ~0.5 % accuracy near the poles. The /tools/distance-calculator implements both with the method named in the result panel.

“WGS84 and EPSG:4326 are the same thing.” WGS84 is the datum; EPSG:4326 is the CRS that combines the WGS84 datum with the geographic coordinate system in degrees. Saying “EPSG:4326 coordinates” is unambiguous; saying “WGS84 coordinates” is usually fine in casual contexts but ambiguous at sub-metre precision (WGS84 has had multiple epochs and small re-realisations since 1984).