2.3 Location, Distance, and Direction

Key takeaways

• Location is always relative to a coordinate reference system, even when it looks absolute.
• Distance has multiple definitions (Euclidean, geodesic, Manhattan, network) — each with appropriate uses.
• Direction on a sphere is a subtle concept; azimuth and bearing behave differently from what you might expect.

Introduction

Every spatial operation decomposes into some combination of location, distance, and direction. They sound self-explanatory, but each has enough subtlety to fill a chapter. This lesson covers the essential distinctions so you can reason about them precisely when analysing data or critiquing someone else's analysis.

Location

Absolute vs relative location

• Absolute location — a coordinate expressed in a defined CRS. "37.7749° N, 122.4194° W" is an absolute location (in EPSG:4326).
• Relative location — a description by reference to other features. "The café across the square from the town hall" is relative.

GIS usually deals with absolute locations but often converts between the two. Geocoding (Module 12) turns relative descriptions (addresses) into absolute coordinates.

Location is CRS-dependent

The same point on Earth has different numeric coordinates in different CRSs:

None is more "correct" than the others — they're different representations. Always store or communicate locations with their CRS explicitly. A naked pair of numbers is ambiguous.

Coordinate precision

How many decimal places matter?

Storing 8+ decimal places is pointless for most applications — it records precision your data doesn't have and wastes storage. Conversely, 2 decimal places cannot support a parcel-level analysis.

Distance

Euclidean (Pythagorean) distance

The straight-line distance between two points in a projected Cartesian space.

$$d = \sqrt{(x_2 - x_1)^2 + (y_2 - y_1)^2}$$

Correct in a flat, projected CRS. Wrong if your coordinates are geographic (degrees).

Geodesic (great-circle) distance

The shortest distance along the surface of the ellipsoid, computed with Vincenty's or the Haversine formula:

from math import radians, sin, cos, asin, sqrt

Use this when your data is in geographic coordinates and you need real metres.

Manhattan distance (L1 / taxicab)

Sum of absolute differences:

$$d = |x_2 - x_1| + |y_2 - y_1|$$

Appropriate where movement is constrained to a grid (Manhattan streets, indoor corridors).

Network distance

Distance along a network (road, river, transit). Not a simple formula — requires a graph-shortest-path algorithm (Dijkstra, A*). Module 13 covers this in depth.

Which one do I use?

Mismatch gives wrong answers. A Euclidean distance between two lat/lon coordinates is degrees, not metres, and near the poles it's spectacularly wrong.

Direction

Cardinal directions

North, south, east, west and their intercardinals (NE, SW, etc.). Simple but insufficient for quantitative analysis.

Azimuth

The angle clockwise from north, in degrees (0–360). North = 0°, east = 90°, south = 180°, west = 270°. The standard geospatial convention.

Bearing

Same as azimuth in most usage. Nautical bearings sometimes specify "bearing from" vs "bearing to" and quadrant conventions (N 45° E) — be cautious when reading older navigation material.

Forward azimuth on a sphere

On a sphere, the azimuth between two points changes along the path. Start flying due east from New York; you end up somewhere north of Portugal because great-circle paths curve on a flat map. This is why:

• Airline routes appear curved on flat maps.
• The initial bearing from A to B is not the same as the bearing from B to A plus 180°.

1from pyproj import Geod
2g = Geod(ellps='WGS84')
3az12, az21, dist = g.inv(lon1=-73.78, lat1=40.64,   # JFK
4                         lon2=-0.46, lat2=51.47)    # LHR
5# az12: initial bearing from JFK ≈ 51°
6# az21: initial bearing from LHR ≈ -71° (not 51° + 180°)

When software returns a single "bearing", check its definition.

Worked example: are you within 1 km of a restaurant?

Given your location (lat, lon) and a list of restaurant points (also lat, lon), how do you answer "which are within 1 km"?

Wrong: compute Euclidean distance in degrees, check if it's less than some threshold. The threshold's meaning changes with latitude.

Right approach 1: reproject both to a local metric CRS (UTM for the zone), compute Euclidean distance in metres.

Right approach 2: use Haversine directly on the geographic coordinates:

1within = [r for r in restaurants
2          if haversine(user_lat, user_lon, r['lat'], r['lon']) <= 1000]

Right approach 3: let PostGIS handle it with the geography type (Module 8):

1SELECT * FROM restaurants
2WHERE ST_DWithin(
3  location::geography,
4  ST_MakePoint(:lon, :lat)::geography,
5  1000  -- metres
6);

Common mistakes

• Using degrees as if they were kilometres. One degree of longitude is ~111 km at the equator and 0 km at the poles.
• Assuming straight-line distances on flat maps are real. The Mercator projection inflates distances at high latitudes.
• Confusing bearing from A and bearing from B. On a sphere they are not simple reciprocals.
• Storing coordinates as (lat, lon) but assuming the library expects (lon, lat). GeoJSON, most PostGIS functions, and most ISO standards use (lon, lat) order. Leaflet uses (lat, lon). Always check.

Self-check exercises

Summary

• Location is always CRS-specific; store and communicate the CRS.
• Distance has several definitions — pick based on data CRS and the physical reality you're modelling.
• Azimuth is standard direction; on spheres, bearings don't simply reverse.
• Coordinate order (lon, lat vs lat, lon) is a frequent source of bugs. Check your library.

Further reading

• Snyder, J. P. — Map Projections: A Working Manual (USGS Professional Paper 1395).
• Karney, C. F. F. — Algorithms for Geodesics, 2013.
• PostGIS documentation — ST_Distance vs ST_DWithin vs ST_DistanceSphere.
• Aviation Formulary by Ed Williams — concise reference for great-circle and rhumb-line computations.