Type an address into any major mapping service and you'll get a pin dropped on a map in seconds. It feels effortless. But under the hood, there's a non-trivial piece of machinery at work - a geocoder converting your free-form text into precise geographic coordinates.
For most of the world, this problem is largely solved. Addresses in the US, UK, or Europe follow reasonably predictable formats. The house number comes first. The street follows. The city and zip code close it out. India is a different story entirely.
At Meesho, geocoding is not an academic problem. It's an operational necessity. We process millions of deliveries across every Indian state, and the accuracy of our geocoding directly determines whether a package reaches the right door or comes back as an RTO (Return to Origin). Bad geocoding means missed deliveries, frustrated customers, and real financial cost.
After years of relying on third-party geocoding services, we decided to build our own - designed specifically for how Indians actually write addresses. We called it GeoIndia. It was published at EMNLP 2024, one of the top conferences in Natural Language Processing.
Here's what we built, and why it works.
The Indian Address Problem Is Unlike Anything Else
To understand why we needed a custom solution, consider what an Indian address can look like in practice:
"XX, palasi mohania village madarsa chowk rto jama masjid Araria Bihar, 854333, purnia"
Now try to parse that. Which part is the locality? Which is the landmark? Is "rto" part of the address or does it refer to the Regional Transport Office? Is "Araria" the city or the district? And where exactly in Bihar does "purnia" place you?
This isn't an edge case. It's representative of how a large fraction of addresses in Tier-2 and Tier-3 India are actually written - especially when customers enter their addresses digitally for the first time, transliterating from their native language into English.
Why Standard Geocoders Struggle
The structural challenges are multi-layered:
- No standardization: There's no uniform address format across India. Mumbai addresses look nothing like Chennai addresses, which look nothing like rural Bihar addresses.
- Inconsistent ordering: The same address might place the pincode first, last, or in the middle depending on who wrote it.
- Landmark-heavy language: "Near the big banyan tree" or "behind Gandhi Market" are real, commonly used address components and they're not in any database.
- Misspellings and transliteration drift: "Daharahara chawk" and "Dharhara chowk" are the same locality. A general-purpose NLP model trained on English text has no reliable way to know that.
- Scale and diversity: India has 29 states, each with its own linguistic patterns, regional terminology, and address conventions.
General-purpose geocoders - even the best ones globally are trained predominantly on well-structured Western addresses. At the fine-grained resolution that last-mile delivery requires, they consistently underperform on Indian data.
The Core Idea: Teach the Model to Think in Hexagons
Rather than trying to predict raw latitude/longitude coordinates (which is a notoriously difficult regression problem), we framed geocoding differently: as a sequence generation task.
The insight, borrowed from recent NLP research and adapted significantly for our context, is this: divide the entire surface of the Earth into a hierarchical grid of hexagonal cells, then train a language model to generate the correct cell identifier from an input address.
Why Hexagons?
We chose the H3 hexagonal grid system for a few reasons that matter in practice. Unlike square grids, hexagons have only one type of neighbour - every adjacent cell shares an edge, not just a corner. This makes spatial relationships cleaner and more consistent, which helps the model learn that geographically close addresses should produce similar outputs.
H3 is also hierarchical: each cell can be sub-divided into finer and finer resolutions. We operated at resolution 9, which covers a radius of roughly 200 meters, precise enough for building-level geocoding.
The clever part is in how we encoded these hexagonal cell IDs for the model. Each character of the alphanumeric H3 index is treated as a separate token with custom delimiters, allowing the model to understand the hierarchical structure within the identifier itself. Neighbouring hexagons share most of their bit-level representation, which nudges the model to produce outputs that are geographically coherent even when it's uncertain.
The Seq2Seq Framing
Once you frame geocoding as "given this address string, generate this H3 cell ID string", you can apply the full power of modern sequence-to-sequence language models. The address is the input sequence. The H3 cell identifier is the output sequence. The model learns the mapping.
This is fundamentally different from how earlier geocoders worked — either as rule-based lookups against address databases, or as coordinate regression models that tried to predict decimal numbers directly. Both approaches hit hard limits with noisy, unstructured input. The Seq2Seq approach is far more tolerant of the messiness of real Indian addresses.
Five Engineering Decisions That Made the Difference
- One Model Per State, Not One Model for India
Our first instinct was to train a single model covering all of India. It didn't work well. The address data is heavily skewed - Uttar Pradesh alone has nearly 7 million training examples, while Sikkim has around 12,000. A pan-India model consistently overfit to high-data states and performed poorly in the rest.
The fix was straightforward but operationally significant: train one dedicated model per state. 29 models in total, each optimized for the specific vocabulary, address conventions, and data volume of its state.
State-specific models consistently outperformed the pan-India model across every state — with mean distance error improvements of up to 35% in high-complexity states like Himachal Pradesh.
2. Build the Tokeniser From Scratch
Off-the-shelf tokenisers trained on general English text handle Indian addresses badly. "Nagsen Nagar" becomes a string of meaningless sub-word fragments. "Bhim Chowk" gets split in ways that destroy the semantic meaning of the locality name.
We trained a custom SentencePiece tokeniser from scratch on 67 million Indian addresses. The difference was dramatic: locality names, chowks, nagars, and mohallas were preserved as coherent units, giving the model a far better foundation to reason from.
One instructive side experiment: we tried treating pincodes as single special tokens, reasoning that a pincode like "440014" should be atomic. It backfired - mean distance error jumped from 0.6 km to 2.6 km in Nagpur. The reason: Indian pincodes have internal hierarchical structure (the first digit indicates a zone, subsequent digits progressively narrow the region). Treating the whole pincode as a single opaque token destroyed that structure. Splitting it hierarchically let the model learn geography from the pincode itself.
3. Transfer Learning Cuts Training Cost Dramatically
Expanding a geocoder to a new state is expensive if you always start from scratch. We found a better path: initialize the new state model with the weights of an already-trained state model, rather than generic pre-trained weights.
The results were striking. When training the Bihar model initialised from a Nagpur model rather than from generic pre-trained weights, the distance error converged to a lower value in 10 epochs compared to 30 epochs with standard initialisation. Faster convergence, lower error, significantly less compute.
This matters enormously for scaling. As we expand to new geographies or as existing states add new pincodes and localities, we don't need to retrain from scratch. We can warm-start from the nearest related geography.
4. Smaller Model Beats Larger for This Task
We tested five sizes of the Flan-T5 family - from 60M to 11B parameters. The winner was Flan-T5-base at 220M parameters, outperforming both smaller and larger variants.
The larger models (3B, 11B parameters) actually performed worse, likely overfitting to the variability and noise in Indian addresses rather than generalising. The 220M model hits the sweet spot: enough capacity to learn complex address patterns, small enough to generalise well and serve at low latency.
We also compared against a quantized large language model fine-tuned with LoRA. The smaller T5 model won convincingly across every metric. The lesson: for this specific task, parameter-efficient fine-tuning of a very large model is not a substitute for full fine-tuning of a well-sized model.
5. Tune Batch Size Aggressively for Data-Scarce States
Small states like Goa, Tripura, and Manipur have fewer than 60,000 training examples - a fraction of what large-state models train on. Standard batch sizes and gradient accumulation steps that work for data-rich states don't work here.
For data-scarce states, we found that small batch sizes with minimal gradient accumulation, essentially updating model parameters more frequently on smaller chunks of data significantly improved performance. In Himachal Pradesh, dropping from batch size 8 to batch size 2 reduced mean error from 4.8 km to 3.8 km and P99 error from 8.7 km to 6.9 km. A meaningful improvement from a single hyperparameter adjustment.
How It Performs: The Numbers That Matter
We benchmarked GeoIndia against a well-known global geocoding platform - the standard that most of the industry relies on across all 29 Indian states.
The results, frankly, surprised even us:
- In Bihar, mean distance error reduced by 62.5% on seen addresses and 47.3% on unseen ones. The P99 error - the worst-case tail, which matters most for delivery reliability dropped by 84.7% on seen data.
- In Andhra Pradesh, mean distance error reduced by 53.7% for seen addresses, with P99 error dropping by 88.2%.
- Even in states with very limited training data - Arunachal Pradesh, Assam, Northeast India, GeoIndia showed substantial P99 improvements, demonstrating that the approach generalises beyond its training distribution.
- Across 29 states, GeoIndia consistently outperformed the benchmark platform on the tail error metrics that matter most for logistics.
In multiple states, we achieved more than 50% reduction in mean distance error and more than 85% reduction in 99th percentile distance error - the metric that determines whether your worst-case deliveries succeed or fail.
The P99 metric deserves emphasis here. In logistics, average performance is less important than tail performance. A model that's accurate 95% of the time but fails catastrophically on the remaining 5% creates serious operational problems. GeoIndia's strength at P99 directly translates to fewer failed deliveries in the hardest-to-serve geographies.
From Research to Real-Time: The Production Story
A model that works in a notebook is one thing. A model that serves millions of geocoding requests at under 100ms latency is another.
Our production deployment required several layers of engineering beyond the core model:
- Latency optimisation: The base model had inference latency of around 700ms - far too slow for real-time use. We applied GPU inference optimisation techniques to bring this down to approximately 80ms, enabling synchronous geocoding in the delivery flow.
- Intelligent routing: With 29 state models, we needed a lightweight gating network to route each incoming address to the correct state model quickly and accurately.
- Caching: Many addresses repeat the same customer placing multiple orders, or multiple customers at the same building. We implemented a caching layer that serves repeated addresses instantly without model inference.
- Model guardrails: Production safety mechanisms that detect and handle cases where the model's confidence is low or its output appears geographically implausible.
- Feedback loop: Delivered coordinates from our logistics network feed back into the training pipeline, continuously improving model accuracy over time.
GeoIndia has now been powering geo-fencing, hub allocation, and route optimization in production for several months, handling real delivery traffic across India at scale.
What We Learned Building This
A few broader lessons from this project that we think generalise:
- Domain-specific tokenisation is underrated: The gap between a generic tokeniser and a domain-trained one was larger than any model architecture choice. If your input text has specialised vocabulary - whether it's medical terminology, legal language, or Indian addresses, train your tokeniser on that vocabulary.
- Bigger models don't always win: For structured prediction tasks with noisy, high-variance input, a well-sized model trained thoroughly often beats a larger model trained with parameter-efficient methods. Match model capacity to data complexity, not to parameter count.
- Data imbalance is a first-class problem: A pan-India model that ignores the 100x difference in training data between UP and Sikkim will always underserve Sikkim. Designing explicitly around imbalance through state-specific models and data-constrained training strategies is the right approach, not an afterthought.
- Transfer learning compounds over time: The ability to warm-start new geographies from existing models doesn't just save compute on day one. It means the system gets faster and cheaper to expand as you build up a portfolio of trained regional models.
- Tail metrics drive operational outcomes: Optimizing for mean error gives a misleading picture in logistics. P99 error is what determines whether your hard-to-reach customers get their orders. Design your evaluation framework around the metrics that reflect real operational cost.
What's Next
GeoIndia is a foundation, not a finished product. We're actively exploring several directions to make our geocoding even more context-aware:
- Native Multilingual Support: Many of our customers enter addresses in regional scripts. We are working on a domain-specific, multilingual language model trained from scratch to handle this deep linguistic diversity.
- Learning from Real Delivery Paths: Our current model relies solely on text, which struggles when entirely different landmarks are used to describe the exact same location. Next, we plan to incorporate actual spatial context by mapping neighborhood connectivity using historical delivery traces from our Field Executives.Fusing Graph and Language Models: To solve the problem of addresses that sound similar but are miles apart, we are exploring unified architectures. By combining graph-based spatial learning with semantic language modelling, the system will explicitly reason across both geographic topology and linguistic structure
The full paper is available in the EMNLP 2024 Industry Track proceedings.
About the Authors
Bhavuk Singhal, Anshu Aditya, Lokesh Todwal, Shubham Jain (ex-Meesho), and Debashis Mukherjee (ex-Meesho) are members of Meesho's Data Science team based in Bangalore. This work was published at the 2024 Conference on Empirical Methods in Natural Language Processing (EMNLP 2024), Industry Track.
