Snapping GPS Coordinates to the Correct Building Entrance

“Navigation took me to the back of the building.” The coordinate is right, the geocoder is right, the map is right. This is not a geometry bug — it is a missing column, and the fix is a data-collection strategy rather than a code change.

The complaint

The reports are specific and repeat by site rather than at random. The driver is routed to a loading bay on a different street from the reception. A university address drops the pin on the geometric centre of a 40-hectare campus with no road within 200 m. A retail park unit resolves to the car park entrance rather than the unit. A gated apartment complex resolves to the courtyard, and the driver stands at a locked gate 80 m from where the phone says they have arrived.

The tell that this is not the same problem as being on the wrong side of the road is scale and consistency. Wrong-side errors are 10–20 m and spread across many addresses; entrance errors are 50–500 m and cluster on a small number of large sites, which then account for a disproportionate share of failed deliveries.

Why the address point is not wrong

An address point represents the address, and the standard representations are a parcel centroid, a building centroid, or a rooftop point — sometimes an interpolated centreline position at lower geocoding accuracy levels. All of those are defensible answers to “where is 14 Mill Lane”. None of them is an answer to “where does a person carrying a parcel go”.

For a terraced house those two questions have the same answer to within a few metres, which is why the distinction goes unnoticed until the dataset contains warehouses, hospitals and campuses. For a 200 × 100 m distribution shed, the centroid can be 110 m from the only door, on the wrong side, behind a fence. The geometry is correct and the delivery still fails.

Routing engines paper over part of this by snapping the destination to the nearest routable way and adding a walking leg. That is why the pin often lands on the road behind the building: the centroid’s nearest road is not the road with the entrance on it. The snap is doing its job on the wrong input.

What is actually missing from the data

The missing entity is an access point: a coordinate, attached to an address, that says where to arrive, plus enough attributes to make it usable — which mode it serves (pedestrian, van, HGV), whether it is gated, opening hours, and the routable way it connects to. Almost no commercial address dataset ships this, because the address authorities that produce address data are recording property identity, not logistics.

Recognising this changes what you go looking for. You are not tuning a snapping radius; you are acquiring or generating a layer that does not come with the addresses. Everything below is one of the three ways to get it.

Where entrance data does exist

• OpenStreetMap. Entrances are mapped as nodes on building ways tagged entrance=main, entrance=yes, entrance=service or entrance=staircase, often carrying their own addr:housenumber. Coverage is highly uneven — excellent in some cities, absent in others — but where it exists it is exactly the right shape, and it also carries the barriers that matter: barrier=gate with an access value tells you the approach is controlled before the driver discovers it.
• Building footprints plus the road network. Where there is no mapped entrance, a footprint layer — OSM buildings, or the open datasets produced by footprint detection from imagery — lets you infer a plausible one: the point on the footprint boundary closest to a routable way that serves the address. It is a guess, it is much better than the centroid, and it should be stored with a confidence flag saying it was inferred.
• Site-specific overrides. For the hundred sites that generate most of your failures — hospitals, business parks, large customers — somebody phoning and writing down the delivery entrance beats every algorithm on this page. Build the table; it is small.

Building the layer from your own deliveries

This is the strongest option available to anyone already running deliveries, and it is chronically under-used: every completed delivery already records where the driver was standing when they marked it complete. That is a direct observation of the entrance.

1. Capture the GPS fix at the moment of the proof-of-delivery event — the barcode scan or signature — together with its reported accuracy. Discard fixes with accuracy worse than about 20 m; in dense urban settings a large fraction will fail this, and keeping them poisons the estimate.
2. Group the surviving fixes by address and require a minimum count before trusting the result — five is a reasonable floor. A single observation cannot distinguish the entrance from a driver who scanned in the van.
3. Take a robust centre, not the mean. The geometric median, or a small-epsilon DBSCAN run per address keeping the largest cluster, resists the outliers that a mean does not; the technique is the same one used for spatial clustering generally. Multiple genuine clusters is itself useful output: a site with a pedestrian door and a goods entrance has two, and they should be stored as two access points with modes attached.
4. Store it as an override on the address with a confidence score and an observation count, and let it take precedence over the geocoded point. Recompute on a slow schedule so a site that moves its reception is picked up within weeks.
5. Feed it back into routing as the destination, and keep the original address point for anything address-shaped — billing, dedup, reporting. They are different fields and conflating them is how you lose the ability to tell what changed.

Snapping, and what to do when you cannot

With an access point in hand, the snapping rule is: route to the access point, not to the address point, and snap the access point to a routable way filtered by the mode you are actually using. A van destination must not snap to a footpath, and a walking leg must be allowed to use one — using one network for both is what produces the instruction to drive down a pedestrianised alley.

When you have no access point, the failure should be visible rather than silent. Do three things. Show the building footprint on the driver’s map instead of only a pin, so the size of the ambiguity is legible. Flag addresses whose footprint is large — over, say, 2,000 m² — or whose centroid is more than 50 m from any routable way, because those are exactly the records that will fail and they can be identified before a driver is dispatched. And put a one-tap “the entrance is here” control in the driver app: it costs a driver three seconds and it is the highest-quality entrance observation you will ever get.