One of the core operations behind Uber’s driver matching is a spatial join. Let me explain…
Your phone sends a location (a point). Uber needs to know which nearby drivers (also points) fall within a certain radius, and which pricing zone (a polygon) you are standing in.
Neither of these is a simple key match like user_id = driver_id. It is a question involving geometry, a simple variant being - does this point fall inside that shape, or how close is it to another point?
That is what a spatial join is. Instead of joining two datasets on a column, you join them on a spatial relationship: intersects, contains, or within a distance. Here are a few more examples -
-
DoorDash and Instacart use it to check if a delivery address falls inside a store’s delivery zone, and to assign the nearest available driver.
-
Swiggy and Zomato use it to decide if your address falls inside a restaurant’s serviceable radius before they even show it in your feed.
-
Strava uses it to match your GPS trace against known running or cycling segments, so it can tell you if you just set a personal record.
By the way, this is how you identify if you need a spatial join or not - one side is usually points (a person, an order, a sensor reading) and the other side is polygons or radius (a zone, a district, a delivery range).
The join answers a question that a normal SQL join cannot: not ‘do these IDs match’, but ‘do these shapes overlap in space’.
The easiest way to prototype spatial joins and other geo capabilities is through an OSS library called geopandas. This is what I also used in the past while I was building a similar system.