POIs for Hyperlocal Delivery: A Data-Centric Approach to the Last-Last-Mile

Authors: Charan, Aarav Nigam

Special thanks to Meghana Negi for her contribution and guidance throughout the project.

Introduction

In hyperlocal delivery, finding a customer’s location is only half the problem. A latitude-longitude pin can tell us where a delivery ends on the map, but not how a delivery partner should interpret that location in the real world. In dense urban environments, the same pin could correspond to a gated residential complex, a large tech park, a hospital campus, or a university block. Bridging the gap between a map coordinate and an actual doorstep is what we think of as the last-last-mile problem. At the center of this problem is a simple but powerful abstraction: the Point of Interest, or POI.

At Swiggy, a POI is not just a coordinate or a place name. It is a meaningful geographic unit that represents how people actually interact with space. A POI may be a residential society, a mall, a tech park, a hospital, or any other place where delivery behavior is shaped by shared boundaries, common entry points, and recurring movement patterns. We currently manage POIs at the scale of several hundred thousand, and they power multiple downstream workflows across customer experience and operations.

Why it matters: a meaningful area is a better unit for delivery decisions than a single pin.

• Precision geofencing: a delivery partner can be marked as having “reached” a location when they cross the POI boundary instead of when they enter an arbitrary radius around a point.
• Consistent availability: customers inside the same large complex can be treated consistently for restaurant access and delivery-time computation.
• Demand shaping: high-density clusters such as hostels or office parks can be identified and served with more context-aware product behavior.

From Discovery to Construction

Mining POIs at the scale of India is challenging largely because addresses are noisy, inconsistently written, and often do not explicitly reveal whether they belong to a meaningful complex. Our earlier approach tackled this using a fully unsupervised pipeline that combined address text with spatial coordinates. Customer addresses were cleaned, embedded using a RoBERTa-based masked language model trained on millions of Indian addresses, merged with normalized latitude-longitude features, and then clustered using hierarchical agglomerative clustering followed by DBSCAN-based spatial cleanup. Final POI polygons were generated from convex hulls around clustered points.

This approach helped improve POI coverage, but it was also computationally expensive, hard to tune, and operationally heavy. Hierarchical agglomerative clustering runs in O(n² log n) time and requires O(n²) space for the pairwise distance matrix — at the scale of millions of addresses per city, this translates to multi-hour runtimes and significant memory pressure even on distributed infrastructure. Those constraints made rapid expansion difficult across cities and use cases. Over time, that led us to a simpler question: if good-quality building boundaries are now available from open datasets, can we stop rediscovering geometry from scratch and instead focus on attaching identity and meaning to those boundaries?

That question shaped our current approach.

The Pipeline

Today, the hardest part is no longer drawing the building boundary. Large-scale open datasets — Google Open Buildings, OpenStreetMap building footprints, and Microsoft Global ML Building Footprints — already provide high-confidence polygon geometries derived from satellite imagery. These polygons give us reliable physical outlines at scale, but on their own, they are still only geometry. They do not tell us the name of the place, what kind of place it is, or whether it is operationally meaningful for delivery.

So instead of discovering POIs end-to-end from raw address clusters, we treat open building footprints as the starting layer and enrich them using Swiggy’s internal signals.

At a high level, the pipeline works in four steps, illustrated in the diagram below:

This shift is important. The earlier system tried to infer boundaries and semantics jointly from noisy signals. The current system separates the two problems: open data provides the boundary, and Swiggy data provides the operational meaning. That separation makes the system easier to scale, easier to maintain, and easier to improve incrementally.

What a POI contains

A POI is more than a polygon. We store its geometry, centroid, identifiers, and type, but we also connect it to downstream structures that make it usable in production: entry gates, entity mappings, and internal paths from gates to customer locations. In practice, this means a large residential society is not represented as a label on a map but as a structured object with boundaries, access points, and navigation context.

For example, a society like “Prestige White Meadows” isn’t just a name in our database; it is a complex polygon with defined entry gates, mapped internal paths, and a centroid that anchors its delivery logic

Tagging a POI: from weak address signals to structured identity

One of the most important stages in the pipeline is tagging: assigning a POI a name, type, and address-related metadata. This problem is deceptively hard because customer-entered addresses are highly unstructured. Individual addresses may include flat numbers, tower labels, local landmarks, abbreviations, or repeated filler phrases. But when we aggregate many such addresses for the same footprint, useful signals begin to emerge.

Our tagging system combines three information sources:

• Weak signals extracted from aggregated customer addresses.
• Context retrieved from web search using those weak signals together with locality and city information.
• Reverse-geocoded geographic context derived from the POI’s coordinates.

These signals are combined and passed to an LLM, which returns a structured output containing the inferred POI name and type.

A useful way to think about this is that the LLM is not discovering the POI from scratch. It is acting as a resolver across noisy but complementary evidence: what customers call the place, how the web describes it, and where it sits geographically. This makes the system both practical and modular. In fact, although the current implementation uses an LLM, the design is model-agnostic and could be adapted to a smaller offline model or an address-specialized SLM in the future.

No matter how strong the automated system becomes, however, we still keep a human in the loop. After automated tagging, the POI and its metadata are reviewed by operations teams, who validate boundaries and make corrections where required. This gives us a pragmatic balance between scale and accuracy, especially in an environment where physical locations evolve continuously over time.

Performance and scalability

In our evaluations, this tagging pipeline reaches an accuracy of approximately 85% — measured as the percentage of POIs for which the automatically assigned name and type exactly match human-validated ground truth. It is also lightweight enough to process and tag roughly 1,000 POIs in under four minutes. That combination of accuracy and throughput is what makes the system viable at scale.

These numbers are not just model metrics. They reflect an operational shift: POI creation is no longer bottlenecked by a compute-heavy discovery stack. Instead, we can scale coverage faster by reusing reliable open geometry and focusing our effort on enrichment, ranking, and validation.

Gate Identification

Gate Identification is essential because a good boundary only tells us where a complex exists, while a good gate tells us how to enter it. Standard navigation systems often guide users toward the geometric center of a point of interest (POI), which may lie behind a wall, inside a restricted area, or far from any valid entrance. This creates practical challenges, especially for delivery partners, who can be directed to inaccessible or incorrect entry points. Without clearly identified gates, confusion arises at one of the most fragile stages of the journey, leading to avoidable delays and inefficiencies.

To solve this, we built a gate identification pipeline that relies on actual movement traces from historical deliveries rather than only on map geometry.

1. Collect GPS pings from delivery trajectories near and inside POIs.
2. Identify points where trajectories intersect and enter the POI boundary.
3. Cluster nearby entry points to absorb GPS noise.
4. Use the representative point of each cluster as a candidate gate.

This allows us to surface entry points that may not exist in public map data at all. We also found that real delivery movement was substantially more reliable than using navigation polylines from mapping providers for this task. In the current setup, the approach achieves roughly 70% accuracy before final validation by operations teams.

Why this approach works

POI creation becomes much more tractable once we stop treating it as a single monolithic ML problem. Open geospatial data gives us reliable boundaries, Swiggy’s order and address data gives those boundaries operational meaning, LLMs help resolve ambiguity in noisy textual signals, and operations teams provide the final layer of validation. Together, this decomposition moves us from a compute-intensive discovery approach to a more scalable, data-centric system that is easier to operate and extend.

What comes next

POIs do more than improve geofencing or place classification. They also create the foundation for internal-road understanding inside large complexes. Once we know the boundary of the place and its validated entry points, we can start reasoning about how delivery partners actually move within that space. That is the next frontier for the last-last-mile, and it builds directly on the POI layer described here.

Thanks soumyajyoti banerjee for helping us with blog and Goda Doreswamy for guidance.

References

[embed]Mining PoIs via Address Embeddings: An Unsupervised Approach Co-authored with Anubhav and Jose Mathewbytes.swiggy.com

[embed]Open Buildings — Google Research A dataset of building footprints to support social good applications.sites.research.google

[embed]GitHub — microsoft/GlobalMLBuildingFootprints: Worldwide building footprints derived from satellite… Worldwide building footprints derived from satellite imagery — GitHub — microsoft/GlobalMLBuildingFootprints: Worldwide…github.com

[embed]Continental-Scale Building Detection from High Resolution Satellite Imagery Identifying the locations and footprints of buildings is vital for many practical and scientific purposes. Such…arxiv.org

[embed]RoBERTa: A Robustly Optimized BERT Pretraining Approach Language model pretraining has led to significant performance gains but careful comparison between different approaches…arxiv.org