Series: Finding India (Part II of II)

How Delhivery Maps Learned to Read Indian Addresses

Key takeaways:

More data wasn’t enough: The real breakthrough came when the engineers realised that the problem was not data quality but understanding addresses as a language. 

Breakthrough with the Geocoder: The system learnt to interpret the entire address and predict its geographic coordinates. 

Learning how geography works in the real world: Field visits with delivery riders revealed the gaps between geographic proximity and operational reality. 

(Finding India Part I of II: https://www.delhivery.com/blog/series-finding-india-(part-i-of-ii)

——

By 2020, Delhivery had spent several years improving how it understood addresses. The company had moved beyond PIN codes, built one of the country's largest databases of localities, developed tools to plan service centre expansion and started collecting GPS data from millions of deliveries.

Yet one operational metric refused to improve- misroutes. A misrouted parcel is a package sent to an incorrect city or sorting facility because of incorrect pin codes, incomplete address or other factors. 

The expectation had always been that as Delhivery delivered more shipments and collected more data, the system would naturally become more accurate. Instead, routing accuracy had begun to plateau. For months, the misroute rate remained around 2.7 per cent despite continuous refinements.

The engineering team improved matching rules. They expanded the locality database. They analysed more delivery data. Nothing fundamentally changed.

"It was one of those moments when we realised the problem wasn't the implementation anymore. The assumptions behind the system had reached their limits," recalls Rohan Anand, Vice President & Head of Data Science at Delhivery.

Until then, almost everything they had built relied on the same idea: identify a locality within an address and use that to determine where the shipment should go. It had worked remarkably well. But India had changed faster than the software.

Customers were writing addresses that referred to places the system had never seen before. New neighbourhoods appeared constantly. Local names evolved. The locality database, no matter how large it became, would always be playing catch-up.

The engineers realised they weren't facing a data problem anymore. They were facing a language problem.

The 12 year journey of Delhivery Maps

Rethinking the Problem

As the engineering team was working very hard to improve misrouting, one of the engineers in the team, Harshit, began exploring an idea that initially seemed far removed from logistics.

Instead of asking whether a computer could identify the locality within an address, he wondered whether it could understand the address itself.

Anand often describes the idea through an analogy: When we translate English into French, we're converting one language into another. We started asking ourselves whether we could translate an address into a location. It was a fundamentally different way of thinking. Instead of breaking an address into familiar pieces, the system would learn to interpret the entire address and estimate its geographic coordinates directly. There was no established playbook for doing this in India.

The models had to learn from millions of examples, and every improvement came from understanding why previous predictions had failed.

Anand says, "It actually started as a hobby project. For a long time, there wasn't much to show. But we felt this was the only approach that could really scale."

Eventually, it did. The new Geocoder significantly reduced misroutes, bringing the rate down from around 2.7 per cent to nearly 1.3 per cent. As the models continued to improve, misroutes fell to below one per cent. For customers, the change was largely invisible. 

Around 2022, the engineering team started looking beyond misroutes as the next big challenge. The advanced version of Geocoder ensured rooftop level accuracy, enabling the team to locate addresses not just within 100 metres but precisely right upto the customer’s doorstep to help guide new riders properly and build trust for our clients on delivery attempts. 

For the network, it was transformative. 

“Delhivery began operating its physical network like digital infrastructure. Once we had the capability to convert an address to a coordinate, service areas no longer had to follow fixed locality or PIN code boundaries. Instead, centres could be assigned dynamically using custom geographic zones, making network expansion faster and far more accurate. That was a big moment,” says Anand. 

Beyond the Distribution Centre

As had happened several times before, solving one problem revealed another. Once the system could accurately determine which distribution centre (last mile centres that distribute shipments to consumers) should receive a shipment, the team began asking whether it could also identify the right delivery rider. 

A service centre is divided into multiple delivery territories, each typically managed by a different rider. Traditionally, those territories had evolved through operational experience. Managers knew their cities well and allocated deliveries based on familiarity. The engineering team wanted to see whether those decisions could also become data-driven. 

What they found surprised them.

Experienced managers often had slightly different interpretations of where one territory ended and another began. In some cases, neighbouring teams each assumed that a particular area belonged to the other, creating small gaps that had gone unnoticed for years.

It wasn't a failure of operational knowledge. It simply illustrated how difficult it is for people to define geography with precision. Using the new mapping system, Delhivery could create dynamic geographic zones and allocate shipments with much greater accuracy than before.

It was another example of technology complementing operational experience rather than replacing it. 

Learning From People who Deliver

Although machine learning became central to the project, Anand is quick to point out that many of the team's most important lessons came from spending time with delivery riders.

The engineers had already begun collecting GPS data through the delivery application. Initially, it was intended to calculate travel reimbursements. Over time, it became one of the richest sources of location intelligence available to the company. 

But data alone rarely explained everything. Field visits revealed countless examples where the digital representation of a place differed from reality.

Two houses might appear only fifty metres apart on a map, yet reaching one from the other required travelling three kilometres because a river, railway line or inaccessible road lay in between. Traffic bottlenecks, gated communities and temporary road closures shaped delivery routes in ways that maps often couldn't capture.

"Those visits were incredibly valuable. The riders helped us understand why certain decisions that looked obvious on a map simply didn't work in the real world," says Anand.

Over time, the team realised that good mapping wasn't just about collecting more data. It was about understanding how that data reflected real operations.

Building Trust in the System

Machine learning made Delhivery Maps possible, but Anand believes the team's biggest progress often came from examining where the models failed rather than celebrating where they succeeded.

Every incorrect prediction became an opportunity to understand something new about Indian addresses. The same philosophy applied to the people using the system.

One lesson the team learnt was that introducing automation required more than accurate algorithms. Operations teams naturally trusted methods they had developed over years of experience. Even when the new system consistently performed better, individual mistakes stood out more than thousands of correct decisions.

Building confidence therefore became as important as improving accuracy. "Technology has to earn people's trust. That takes time," says Anand.

A Different Kind of Map

Most mapping platforms are designed to help people discover places or navigate from one destination to another.

Delhivery's challenge was very different.

Its systems needed to decide which distribution centre should receive a shipment, which rider should deliver it, how hundreds of deliveries should be sequenced and how an expanding logistics network should be planned. Those decisions required a different understanding of geography.

Rather than investing in large-scale ground surveys or satellite imagery, the team built its understanding of India from the operational data generated by millions of deliveries.

Every successful delivery improved the system's understanding of addresses, travel times and routing decisions. Only much later did those capabilities evolve into a visual mapping platform.

Anand says, "We built intelligence first. The map came afterwards."

When Others Began Asking For It

After more than a decade of continuous iteration, Delhivery reached a point where the platform had become reliable enough across its own operations to be packaged as a standalone product.

It became Delhivery Maps. 

For the engineers, however, the launch didn't feel like the beginning of something new. It felt like the culmination of years of solving one operational problem after another. What surprised them most came afterwards. Interest began coming from companies outside Delhivery.

Anand says with a smile, "They're not organisations that don't know Google Maps exists. Everyone knows those products. So when they come to us, it tells us there are problems that existing mapping providers haven't solved."

For him, that interest has been one of the strongest validations of the team's work. 

Some of the common use cases of Delhivery Maps are:

• Validate addresses by identifying and filling missing details.

• Geocode incomplete addresses into precise latitude and longitude coordinates.

• Optimize delivery routes at scale for faster and more efficient operations.

• Autocomplete addresses with intelligent address and POI suggestions.

• Distance and ETA calculations which can work at scale

• In-app navigation to help last mile riders become more productive

It suggests that the challenges Delhivery encountered over a decade were not unique to one logistics company. They reflected a broader gap between consumer mapping products and the needs of businesses operating complex physical networks.

The team is now working on expanding the platform further, including strengthening traffic intelligence and building one of India's largest databases of points of interest for enterprise use cases.

—————

https://www.delhivery.com/maps

(Reporting and editorial by Taslima Khan)

https://www.linkedin.com/in/taslima-khan-02b22b16/