What accuracy and coverage limits apply to Redis geospatial indexes — how exact are the coordinates returned by GEOPOS and the distances returned by GEODIST, and which coordinates cannot be stored at all?
answer
- 26 bits/axis → sub-metre storage error
- GEOPOS returns cell centre, never your exact input
- haversine on a sphere, <0.5% error, no altitude
- latitude limited to ±85.05112878° — no poles
- circle and box only; no polygons
basics
~20 sCoordinates are quantised to 26 bits per axis, so GEOPOS comes back within roughly a metre of what you wrote, never bit-identical. GEODIST is a great-circle distance on a sphere — a straight line, no roads, no altitude, with sub-percent error. Latitude is limited to about ±85.05°, so the poles cannot be stored.
solid answer
~50 sThree separate limits. **Quantisation.** A point is encoded as 26 bits per axis into a 52-bit geohash score. That is lossy: `GEOPOS` returns the centre of the cell you landed in, typically well under a metre from the input, but never the exact value you wrote. Do not round-trip through Redis and expect equality, and do not use `GEOPOS` as your system of record for coordinates. **Distance model.** `GEODIST` (and the radius filter inside `GEOSEARCH`) computes a haversine great-circle distance on a sphere of fixed radius, ignoring the Earth's ellipsoidal shape and altitude. The documented error is under about 0.5%. It is an as-the-crow-flies number: never a driving distance, walking time or road-snapped result. **Coverage.** Longitude must be within ±180° and latitude within roughly ±85.05112878° — the Mercator cut-off. `GEOADD` errors on out-of-range values, so polar coordinates simply cannot be indexed. In practice: use Redis to shortlist candidates cheaply, then let a routing service rank them.
code
text · 9 linesGEOADD pts -122.419416 37.774929 SF
GEOPOS pts SF
# 1) 1) "-122.41941750049591064"
# 2) "37.77492961401463914" <- close, not identical
GEOADD pts 0 89.5 NorthPolar
# (error) ERR invalid longitude,latitude pair 0.000000,89.500000
GEODIST pts SF SF m # "0.0000" - altitude is not modelled at allgo deeper
Know that both storage and distance are approximate, and that GEOPOS does not return your exact input.
Separate the sources: quantisation on write, haversine-on-a-sphere on distance, and the ±85° latitude limit, with rough magnitudes for each.
Draw the design consequence — Redis is candidate generation; exact geofence, routing and ranking happen downstream on the shortlist — and note boundary cases are indeterminate.
Frame it as an accuracy budget: cheap in-memory filtering with sub-metre/sub-percent error is fine for recall, but any decision with money or legal weight needs an exact check on the reduced set.
## Three independent sources of imprecision Candidates often collapse these into one vague "Redis geo is approximate". They are distinct, and each bites differently. ### 1. Coordinate quantisation (storage) `GEOADD` bisects longitude over [-180, 180] and latitude over the Mercator range 26 times each, interleaving the 52 resulting bits into the sorted-set score. Storage therefore records **which cell** a point falls into, not the point. `GEOPOS` decodes the cell back to its centre. How big is a cell? 26 bisections of 360° of longitude leave cells on the order of tens of centimetres wide near the equator (narrowing toward the poles as meridians converge); the documented worst-case error introduced by the encoding is around 0.6 m. Practical consequences: - `GEOPOS` never returns exactly the doubles you wrote. Code that asserts equality on a round-trip fails, and diffing "stored vs submitted" coordinates produces phantom changes. - Two distinct points closer together than a cell collapse to the same score. They remain distinct members — sorted-set members are unique by name, not score — but they are indistinguishable positionally. - Redis is a spatial *index*, not the record of truth. Keep authoritative coordinates in your primary store and treat the geo key as a derived structure you can rebuild. ### 2. The distance model (computation) `GEODIST` and the final filtering step inside `GEOSEARCH` use the **haversine** formula on a perfect sphere with a fixed Earth radius (Redis uses 6372797.56 m). Reality is an oblate spheroid, so: - Error against a proper ellipsoidal (Vincenty/geodesic) calculation stays well under a percent — the docs cite a standard error below 0.5%. - **Altitude is ignored entirely.** Two points on different floors of the same building are zero metres apart. There is no third dimension in the encoding. - The result is a straight great-circle line. It is not road distance, not travel time, and takes no account of rivers, one-way streets or walls. A 500 m radius can contain a driver on the wrong side of an unbridged river. This matters at the shape boundary too: because both the stored point and the distance calculation carry error, a member sitting almost exactly on your radius may be included or excluded in a way you cannot predict. If a boundary decision is business-critical (geofenced pricing, legal jurisdiction), do not let a Redis radius be the arbiter — use it to shortlist, then re-verify precisely. ### 3. Coverage limits (what you cannot store) - Longitude: [-180, 180]. - Latitude: approximately [-85.05112878, 85.05112878]. The latitude cut-off comes from the Web-Mercator-style square projection the geohash scheme uses; it makes the encodable area a square, which keeps the bisection uniform. Values outside these bounds cause `GEOADD` to return an error rather than silently clamping. So the polar regions genuinely cannot be indexed — irrelevant for consumer apps, occasionally fatal for research, shipping or aviation datasets, which need a real GIS. A related distortion: geohash cells are equal in *degrees*, not in *metres*. Near the poles a cell is far narrower east-west than near the equator, so cell-based reasoning about ground distance is latitude-dependent. `GEOSEARCH` compensates by filtering candidates with the real distance formula, but hand-rolled cell tricks on top of `ZRANGEBYSCORE` do not. ### 4. Query-shape limits Redis offers exactly two shapes: a circle (`BYRADIUS`) and an axis-aligned rectangle (`BYBOX`). There are no polygons, no "inside this delivery zone", no nearest-road snapping, no isochrones. A delivery-zone polygon is normally approximated by a bounding circle in Redis and then point-in-polygon tested precisely in the application. ## How to talk about this in an interview The good answer names the three error sources separately, quantifies them (sub-metre storage, sub-percent distance, ±85° latitude), and then draws the architectural conclusion: Redis geo is a **fast candidate generator** — it turns "all 2 million drivers" into "these 30" in a millisecond. Precision decisions (exact geofence membership, routing time, ranking) belong to the layer behind it, which can afford to be exact because it only sees 30 rows.
- A test asserts that GEOPOS returns the exact coordinates that were written. Why does it fail, and how should the test be written?`GEOADD` quantises each axis to 26 bits, so what is stored is a cell identifier and `GEOPOS` returns that cell's centre — typically under a metre from the input but never bit-identical. The test should assert with a tolerance (compare with an epsilon, or assert `GEODIST` between written and read-back point is below a metre) rather than checking equality.
- Your product needs 'inside this delivery polygon', not 'within this radius'. How do you use Redis here?Use Redis for candidate generation only: `GEOSEARCH` with a circle or box that fully contains the polygon (its bounding shape), then run an exact point-in-polygon test in the application or a GIS store on the small candidate set. Redis reduces millions of points to tens in a millisecond; the precise geometry runs on tens of rows, so it is cheap.
It is like recording an address to the nearest doorstep rather than the nearest centimetre, and measuring distance with a taut string over a globe: good enough to pick who is nearby, useless for deciding who is exactly on the property line.
saying these in an interview costs you the question
- Treating GEODIST as a driving or walking distance rather than a great-circle line
- Expecting GEOPOS to return the exact submitted coordinates
- Storing polar coordinates and being surprised GEOADD errors out
- Believing altitude or floor level affects the distance — the encoding is strictly 2-D
- Making a legal or billing geofence decision directly on a Redis radius boundary