Geometries and coordinate reference systems

Why is a coordinate meaningless without its reference system, and where does geospatial difficulty move?

Graph had no projection because reachability has no bound. Geospatial is the opposite extreme, and it is the family where this mechanism's shared template works best. A polygon of ten thousand vertices has a bounding box (the smallest axis-aligned rectangle around it) described by four numbers. If that box does not intersect your query, then neither does the polygon. This implication is exact, one-sided and cheap. Filter-and-refine (a cheap filter with no false negatives, followed by exact evaluation on the survivors) is not an optimization here. It is the architecture.

So the interesting constraints are elsewhere. Two things are categorically new.

The objects have extent. Everything indexed so far has been a point in some space: a row with a key, a document, a vector. A polygon occupies a region. It does not belong in one cell of any partition, because it straddles several. Every mechanism in this article is downstream of the fact that an extended object cannot be assigned a single location without losing information.

The predicate is a real-world relation, not an arithmetic one. "Within 500 metres" is a statement about the surface of an oblate spheroid (a slightly flattened sphere, which is the shape of the Earth). It is written in coordinates that were projected onto a flat plane by one of thousands of conventions. And it is evaluated in floating-point arithmetic, whose rounding can make two computations disagree about whether a point is inside a polygon. Correctness here is a modelling question before it is a computational one. It is the first time here that the dominant error source is semantic rather than mechanical.

A coordinate pair is meaningless without knowing what it is a coordinate in. Latitude and longitude on a specific ellipsoid, or metres east and north of some origin under some projection, are different spaces. The same numbers denote different places in each. The description of that space is a CRS (coordinate reference system).

The consequence that matters mechanically: most spatial operations are only valid in some coordinate systems. Distance and area need a projected system with metric units. In raw latitude/longitude, a degree of longitude is about 111 km at the equator and shrinks towards zero at the poles.

Worked example

Near Pune (latitude about 18.5 degrees), one degree of longitude is about 111 km × cos(18.5°) ≈ 111 × 0.948 ≈ 105 km. At latitude 60 degrees it is 111 × 0.5 = 55.5 km. So Euclidean distance over latitude/longitude is not distance at all. It is a number that is small when things are close, and wrong by a factor that varies with latitude.

RelationshipA degree of longitude shrinks with latitude →

111 km \times cos (18. 5^{\circ}) \approx 105 km

Data table

Kilometres per degree of longitude, by latitude
Latitude (degrees)	km per degree
0	111
1.11	111
2.23	111
3.34	111
4.45	111
5.56	110
6.67	110
7.79	110
8.9	110
10	109
11.1	109
12.2	108
13.3	108
14.5	107
15.6	107
16.7	106
17.8	106
18.9	105
20	104
21.1	104
22.3	103
23.4	102
24.5	101
25.6	100
26.7	99.2
27.8	98.2
28.9	97.2
30	96.1
31.1	95
32.3	93.9
33.4	92.7
34.5	91.5
35.6	90.3
36.7	89
37.8	87.7
38.9	86.3
40	85
41.2	83.6
42.3	82.1
43.4	80.7
44.5	79.2
45.6	77.6
46.7	76.1
47.8	74.5
49	72.9
50.1	71.3
51.2	69.6
52.3	67.9
53.4	66.2
54.5	64.4
55.6	62.7
56.7	60.9
57.9	59.1
59	57.2
60.1	55.4
61.2	53.5
62.3	51.6
63.4	49.7
64.5	47.7
65.6	45.8
66.8	43.8
67.9	41.8
69	39.8
70.1	37.8
71.2	35.8
72.3	33.7
73.4	31.7
74.5	29.6
75.7	27.5
76.8	25.4
77.9	23.3
79	21.2
80.1	19.1
81.2	17
82.3	14.8
83.4	12.7
84.5	10.5
85.7	8.4
86.8	6.24
87.9	4.09
89	1.94

Every projection distorts something: area, angle, distance or direction. None preserves all of them. This is a theorem about mapping a sphere onto a plane, not an engineering limitation.

So the CRS is a unit, and it behaves exactly like one. Operations between mismatched units are silently wrong rather than loudly failing, because both values are "two floats". This is the classic failure of an untyped unit, the same class of bug as adding milliseconds to seconds. The systemic answer is also the same: carry the unit with the value and refuse to operate across mismatches. That is what an SRID (spatial reference id, a number naming the CRS) attached to every geometry is for. It is a semantic type doing real work. Geospatial is the clearest case where a type system prevents a correctness failure that no amount of testing would reliably surface.

-- PostGIS: geography type does distance on the spheroid, in metres.
SELECT ST_DWithin(
    courier.location::geography,
    pickup.location::geography,
    500);                       -- 500 metres, not 500 degrees

The second correctness surface is validity. A polygon can be self-intersecting, have rings wound the wrong way, or have holes outside its outer ring (its shell). Predicates over invalid geometries return arbitrary results, not errors. So validity is a constraint that must be enforced at write time. Otherwise the index is built over nonsense. This is input validation with an unusually sharp consequence.

Underneath both lies floating point. A question like "is this point exactly on this edge" is decided by the sign of a small determinant (a number computed from the coordinates). That is exactly where floating point loses all significance. Two geometrically equivalent computations can disagree. This means spatial predicates are not always transitively consistent. Robust implementations fall back to exact arithmetic for the degenerate cases, at considerable cost. This is real and permanent, and it is why spatial libraries are so much harder than they look. It is also the cause of Amara's third report: two libraries made different, equally defensible, rounding decisions for a point on the edge.

One line: a coordinate is meaningless without its CRS, a CRS is a unit, and unit errors here are silent. So the SRID is part of the type and validity is a write-time constraint.