Geospatial workloads usually start with a question in plain language, such as "which stores are inside this polygon?", "which trips cross this corridor?", or "which assets are within 10 km of this point?". They are then translated into spatial relationships between stored geometries.
Relationships you model most often
Contains / within: Is a point inside a polygon, or is one region inside another?
Intersects: Do two geometries share any area or touch along an edge?
Touches / disjoint: Boundary contact only, or no overlap at all?
SurrealDB exposes these ideas through geometry values and the geo:: function family.
let $london = (-0.04592553673505285, 51.555282574465764);
let $harare = (30.463880214538577, -17.865161568822085);
RETURN geo::distance($london, $harare);Exact operators available to your version are documented alongside geometry types and index definitions. From SurrealDB 4.0, a SPATIAL index answers the spatial operators and geo::distance radius conditions without a scan of the whole table. Use EXPLAIN to confirm that a query uses it.
Tip: combine with non-spatial filters
As location queries are rarely done in isolation, you can combine spatial predicates with ordinary fields to form queries for tasks like "coffee shops in this polygon that are open now", instead of returning every record in the table.