Module 4: Coordinate Reference Systems

4.3 Geographic vs Projected Coordinates

The critical distinction between angular (lat/lon) and planar (x/y in metres) coordinates.

Lesson 17 of 100·18 min read

Key takeaways

Geographic coordinates (lat, lon) are angles on a curved surface.

Projected coordinates (x, y) are planar metres suitable for arithmetic.

Knowing which you have changes which operations are valid.

Introduction

Ask a GIS veteran what separates beginners from intermediates, and they'll often say: "they confuse geographic and projected coordinates." This lesson makes that distinction crisp. Once internalised, whole classes of bugs vanish.

Geographic coordinates

Geographic (sometimes angular or unprojected) coordinates describe a point on the Earth's surface using angles:

Latitude — angle north (+) or south (−) of the equator, −90° to +90°.
Longitude — angle east (+) or west (−) of the prime meridian, −180° to +180°.
Optional: ellipsoidal height — metres above the reference ellipsoid.

Examples:

San Francisco: 37.7749° N, 122.4194° W (or +37.7749, −122.4194).
Sydney: 33.8688° S, 151.2093° E (or −33.8688, +151.2093).

Geographic coordinates are:

Naturally global — cover the whole Earth with one system.
Not directly usable for distance or area math — degrees are not metres.
The native format of GNSS receivers, GeoJSON, and most data catalogues.

Projected coordinates

Projected coordinates result from applying a map projection — a mathematical function that flattens the ellipsoidal surface onto a plane. They are:

Planar (flat).
Usually in metres (sometimes feet).
Locally Euclidean — Pythagoras works, at least over short distances.
Distorted in specific, known ways (see 4.4 and 4.5).

Examples of projected coordinates:

Web Mercator (EPSG:3857): SF ≈ (−13 621 795, 4 545 515) metres.
UTM Zone 10N (EPSG:32610): SF ≈ (553 340, 4 183 073) metres.
British National Grid (EPSG:27700): central London ≈ (530 000, 180 000) metres.

Why it matters — operations that differ

Operation	Geographic	Projected
Euclidean distance	Invalid — returns degrees	✓ metres
Buffer by N metres	Needs geodesic buffer	✓ direct
Area of polygon	Needs spherical integral	✓ planar area
Sum of coordinates	Meaningless	Valid
Rendering as tiles	Typically reprojected to Web Mercator	✓ native
Global visualisation	✓ coverage	Some projections fail

A 500-metre buffer computed on lat/lon data with a Euclidean buffer will be wildly wrong. It might be metres-sized near the poles and tens of kilometres at the equator — all named "500".

How to tell which you have

Five quick tests:

Check the file's CRS metadata. ogrinfo / gdalinfo report the CRS. EPSG:4326, 4269, GCS_WGS_1984 → geographic. Anything else → usually projected.
Check the coordinate magnitudes. Longitude and latitude are in the range (−180, 180) and (−90, 90). Projected metres are typically 6- or 7-digit numbers.
Check the units. CRS WKT includes UNIT["Degree", ...] for geographic and UNIT["metre", 1] (or foot) for projected.
Check the axis order. Geographic is often (lat, lon) — but GeoJSON uses (lon, lat). Projected is (easting, northing). A swapped pair is a common bug.
Plot it. A geographic dataset of a city fits in a degree box; a projected one covers kilometres of metres.

Which should you store data in?

For analysis

Choose a projected CRS appropriate to your area:

Global analysis — equal-area global projection (e.g., Equal Earth, Mollweide).
Country-level — national grid (BNG for UK, Lambert-93 for France, State Plane for US states).
Metre-level mapping — UTM zone containing the area of interest.
Continent-level — Lambert Conformal Conic or Albers Equal Area.

For exchange and web

Use EPSG:4326 (WGS 84 geographic). It's lingua franca; every tool speaks it. Web tile rendering uses EPSG:3857 but source data can (and should) remain 4326 until rendered.

Reprojecting in code

Python

1import geopandas as gpd
2[object Object]
3[object Object]
4

Rule: reproject before computing distances, areas, or buffers unless you're using a geodesic function.

Axis-order confusion

One of the most annoying bugs in GIS. Conventions:

Source	Order
GeoJSON	(lon, lat)
PostGIS `ST_MakePoint`	(lon, lat)
Leaflet	(lat, lon)
ArcGIS Python API	(lon, lat)
ISO 19111 (authoritative EPSG meta)	often (lat, lon) for geographic

Tools like pyproj added always_xy=True specifically to force consistent (lon, lat) regardless of CRS-declared axis order. When integrating different systems, axis order is a top source of "data off by a factor" bugs.

Self-check exercises

1. You have a GeoJSON file with coordinates like [-122.4, 37.8]. What CRS is it in, and what type (geographic or projected)?

GeoJSON is conventionally EPSG:4326 (WGS 84 geographic) with (lon, lat) axis order. So this is the longitude -122.4, latitude 37.8 near San Francisco. It's geographic — angular degrees, not metres.

2. Why will `gdf.geometry.area` return nonsense on a GeoJSON in EPSG:4326?

Because area computes planar (Euclidean) area on the coordinate values — in this case degrees-squared, which is meaningless. Either reproject to an equal-area CRS first, or use a geodesic area function (shapely via pyproj.Geod.geometry_area_perimeter, or PostGIS ST_Area(geography)).

3. You need to buffer a point by 1 km. You have the point in WGS 84. What's the safest workflow?

Reproject the point to a local projected CRS (UTM, State Plane, or similar) where the unit is metres; buffer by 1000; optionally reproject the result back to WGS 84 for storage. Alternatively, use a geodesic buffer (PostGIS ST_Buffer(geography) or geopy helpers) which respects curvature.

Summary

Geographic = angular, global, great for exchange.
Projected = planar, local-to-continental, required for metre-based analysis.
Reproject before distance / area / buffer calculations.
Axis order varies by tool — verify, don't assume.