Geospatial patterns.

GEOADD stores a named location in a Sorted Set encoded as a geohash. The argument order is longitude first, then latitude — the GeoJSON convention, not the everyday latitude-first habit. Getting the order wrong silently maps every point to the wrong hemisphere; there is no runtime error.

GEOPOS returns coordinates in the same longitude-first order. The returned values may differ by a few microdegrees from the inputs because coordinates are stored as 52-bit geohash integers (precision ±0.6 m).

GEODIST accepts four units: m (metres), km (kilometres), mi (miles), ft (feet).

GEOSEARCH supersedes the deprecated GEORADIUS and GEORADIUSBYMEMBER (pre-6.2 forms). Two search origins: FROMMEMBER centres the query on a stored member; FROMLONLAT centres it on arbitrary coordinates. Two shapes: BYRADIUS draws a circle; BYBOX draws a rectangle (width × height centred on the origin).

Output options: WITHCOORD includes [lon, lat] per result · WITHDIST includes the distance from the origin · WITHHASH includes the raw geohash integer · COUNT N limits to N results · ASC / DESC sorts by distance.

Persist results to a new key with GEOSEARCHSTORE. The output is a Sorted Set with geohash scores, ready for further range queries.

A GEO member carries only a name. There is no room in the Sorted Set score for ratings, cuisines, or availability. Store extra data in a separate Hash keyed by the same id; GEOSEARCH returns the ids, then HGETALL fetches the rows.

The same pattern applies to real-time tracking. On each GPS ping, update the driver's position with a new GEOADD (calling GEOADD on an existing member replaces the coordinates). A separate status Hash records the timestamp and availability flag; query the GEO index for candidates, then filter by the status Hash.

Valkey does not provide built-in geofencing events. The pattern is application-side: store fence definitions as GEO entries (or in a Hash), check each position update with GEOSEARCH, and compare current state to previous state to detect enter or exit transitions. Broadcast transitions via Pub/Sub to interested subscribers.

The GEOHASH command returns the human-readable geohash string for a member. Longer strings encode finer precision; the string is the same encoding stored as the ZSET score (decoded to a 52-bit integer). Useful for debugging and for exporting to external geospatial tools.

Removing a location uses ZREM, not a dedicated GEOREMOVE, because GEO data is stored in a standard Sorted Set.

The structure reveal (figure 18): a GEO set is a Sorted Set. The source states it three times: “Coordinates are stored as geohashes in a Sorted Set” (line 5) · “The results are stored as a Sorted Set with geohash scores” (line 71) · “Since GEO data is stored in a Sorted Set, use ZREM” (line 125). GEOADD encodes (lon, lat) into a 52-bit interleaved geohash integer stored as the ZSET score; GEOSEARCH is a bounded range-scan over that score space.

codemojex has no geospatial surface (figure 19). It is a location-agnostic Telegram emoji-guessing game — players guess emoji; the bus rotates service across players; nothing is placed in space. Unlike some other modules in the R7 family, geospatial does not map onto codemojex’s domain. The standalone store-locator and ride-share examples above are the natural home for GEO commands.

Each dive takes one slice of the geospatial pattern in depth. Read them in order: the add-and-query commands first, the shape options second, the underlying structure third.