Messy Address Geocoder for Last-Mile Delivery Using Past Drop Points

The problem couriers have with addresses

In much of South Asia, the Middle East and Africa, addresses are descriptions rather than codes: "House 12, Street 4, near Madina Masjid, behind the petrol pump, Block C". The same place is written ten ways by ten customers, in English, local script or transliteration. Postcodes, where they exist, cover large areas. General geocoders often return the centre of the neighbourhood, hundreds of metres away from the door.

The cost is visible every day: riders call customers for directions, failed first attempts, late deliveries and wasted fuel. Yet every courier holds a large, underused asset: GPS points from past successful deliveries, which show where each address actually is.

What already exists and the gap

• Google Maps Geocoding API handles formal addresses well but is often imprecise for informal landmark-based ones and costs money per request at scale.
• Plus Codes and what3words give precise location codes, but customers rarely know or use them.
• Swiggy has written on its engineering blog about address correction for quick commerce, including a classifier that detects when a captured location is inaccurate by comparing it with the address text and past delivery locations.
• Pelias and Nominatim are open-source geocoders built on open map data, which is often thin in informal areas.

The gap: large delivery companies build this internally; mid-sized couriers, pharmacy chains and food delivery startups do not have the team to do so. A service that learns from a company's own delivery history is the product. The core work is data engineering and entity resolution, not app screens.

What you build

Roles: API client (the courier's order system), operations reviewer (fixes low-confidence addresses on a map), admin.

Flows:

1. Historical orders with addresses and drop GPS points are loaded and cleaned.
2. Addresses are parsed and normalised; aliases are learned ("DHA Ph 6", "Defence Phase VI").
3. Drop points for the same customer and address are clustered into a stable location.
4. A new order's address is matched against known addresses and clusters; the service returns a coordinate, confidence and evidence.
5. Low-confidence results go to reviewers; their fixes feed back into the gazetteer.

The technically interesting part

This is entity resolution with a spatial twist. Two address strings may refer to the same door or not; text similarity alone is misleading because "Street 4, Block C" exists in many neighbourhoods. You need blocking (by city and area, or by H3 cell of past drops), a comparison model that uses text, landmarks and spatial evidence, and a rule for when to trust history over text.

Drop-point clustering matters too: GPS is noisy near tall buildings, and riders sometimes mark delivered from the road. Use density-based clustering, remove outliers, and measure how many past points you need before the location is stable. Show your evaluators the confidence score is calibrated: 90% confidence should mean the answer is within your distance target about nine times in ten.

How to evaluate it

• Distance error: median and 90th percentile distance from predicted coordinate to actual drop point on a held-out month.
• Hit rate: share of addresses within 50 m and 100 m, versus a commercial geocoder and a gazetteer-only baseline.
• Parser: component-level F1 on 500+ labelled addresses.
• Calibration: reliability plot for the confidence score.
• Performance: single and batch latency; throughput on 100,000 addresses.

Suggested plan

1. Weeks 1 to 4: partner with a courier or delivery startup for anonymised historical data, or build a realistic dataset from OpenStreetMap plus simulated drops; label addresses.
2. Weeks 5 to 9: parser, normalisation, gazetteer from OpenStreetMap.
3. Weeks 10 to 14: drop-point clustering and alias learning.
4. Weeks 15 to 20: matching model, confidence scoring, API.
5. Weeks 21 to 24: review tool and feedback loop.
6. Weeks 25 to 30: held-out evaluation, baselines, write-up.

Path to a product

The first customer is a mid-sized courier or a delivery startup with a few years of order history. Charge per geocoded address above a free volume, or an annual licence for self-hosting when data cannot leave the company. As the service improves across clients, offer an opt-in shared gazetteer of public place names (never customer data).

Scope warning

Do not build a rider app, order tracking or route optimisation. Do not share one client's customer addresses with another. Do not try to cover a whole country; one or two cities with good data is enough.

Learn what you need on Sefism

• Data Analytics roadmap : SQL and Python foundations for the pipeline.
• System Design roadmap : designing a low-latency lookup service with batch updates.
• Swiggy Bytes : the engineering blog with its address correction write-ups.
• PostgreSQL Documentation : the base for PostGIS spatial queries.
• Fundamentals of Data Engineering : ingestion and serving patterns for the feedback loop.

Get help with this idea

The first thing to settle is where the delivery history comes from; without it the idea changes shape. If you want a second opinion on scope, stack or how to evaluate it before you pitch it to your supervisor, a mentor can help you shape it. You still build it; the guidance is about making the plan realistic and the results defensible. New here? create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session