latlng

Ride-hailing and on-demand dispatch

Match every request with the closest available driver, tell riders when their driver is about to arrive, and manage pickup zones at airports and venues — all from live positions held in memory.

The challenge

On-demand dispatch lives and dies by latency. Every request needs the nearest available drivers right now, filtered by vehicle type and status. Once a match is made, the rider wants to know when the driver is close — which means comparing two moving positions continuously.

Doing that with polling burns resources and still reacts late. Doing it with custom code means reimplementing spatial indexing and proximity detection.

How latlng helps

Driver search in one call

nearby returns drivers sorted by distance, filtered by status, vehicle type, or rating, and capped with limit — ready to offer the job.

Driver-near-rider alerts

Roaming geofences fire when a driver comes within a set distance of a waiting rider. nodwell ensures one alert per approach, not one per position update.

Pickup and queue zones

Airport lots, stations, and event venues become geofences. Enter and exit events let you keep a fair queue of waiting drivers.

Status without extra writes

Update a driver's status field when a trip starts or ends; the next search reflects it immediately without resending the position.

Requests that clean up

Store open ride requests as objects with expire_seconds. Abandoned requests are deleted by the expiry sweep, stop matching proximity fences, and fire Del events your dispatch service can use to release them.

Live dashboards

Stream geofence events to operations dashboards over WebSocket channels, with tokens that can subscribe but not write.

How it fits together

  1. 01

    Rider requests

    The request is stored in a riders collection with a TTL and queried against nearby available drivers.

  2. 02

    Dispatch offers

    Your matching service offers the job to the closest drivers and updates the winner's status.

  3. 03

    latlng watches

    A roaming geofence between drivers and riders detects the approach.

  4. 04

    Rider is notified

    The roam event triggers an "arriving now" push through your notification service.

Alert when a driver is 150 m from the rider

A roaming geofence compares every driver update with open rider requests. Register it once; it applies to every ride.

HTTP
curl -s -X POST http://127.0.0.1:7421/hooks \
  -H 'content-type: application/json' \
  -d '{
    "name": "driver-near-rider",
    "endpoint": "https://notifications.internal.example.com/arriving",
    "def": {
      "collection": "drivers",
      "query": {
        "Roam": {
          "target_collection": "riders",
          "target_pattern": "*",
          "meters": 150,
          "options": {},
          "nodwell": true
        }
      },
      "detect": ["Roam"],
      "commands": ["Set"]
    }
  }'

Where latlng stops

  • latlng finds candidates by straight-line distance. Rank the final offer by drive time with a routing engine if roads, rivers, or one-way streets matter.
  • Matching logic, pricing, and driver acceptance flows live in your dispatch service; latlng provides the spatial queries and events it builds on.
  • Live WebSocket channels don't buffer events for disconnected clients. Use hooks for notifications that must be delivered.

Frequently asked questions

How do I find the nearest available driver?

Store drivers as point objects with a status field and run a nearby query with a where-in filter on status and a limit. Results are sorted by distance and include the distance in meters.

How do I notify a rider that the driver is arriving?

Use a roaming geofence between the drivers collection and the riders collection with a radius such as 150 meters and NODWELL enabled. latlng sends one event when a driver first comes within range.

How do I manage an airport pickup queue?

Register the waiting lot as a polygon geofence with enter and exit detection. Your queue service adds drivers on enter events and removes them on exit events or when they accept a trip.

What about ride requests that are abandoned?

Store requests with expire_seconds. When the TTL runs out the request is removed, so it no longer appears in queries or triggers proximity alerts.