Why LLMs can describe location but not compute it
Table of contents
Language models have gotten good enough at enough things that it's tempting to assume they're good at everything. They write working code, read contracts, summarise research, hold a coherent conversation about almost any subject. So when teams build customer-facing assistants, they stretch that same assumption to the physical world, because the model sure sounds like it understands it.
But ask a language model about positions, distances, routes or spatial relationships, and it fails in ways that are subtle enough to slip past review and serious enough to matter, like a customer standing outside the wrong building.
The cause isn't a gap in training data. It's what these systems are built to do. A language model predicts the next token in a sequence. It doesn't measure anything.
Four queries and what they actually require
"Which of your stores is closest to me?"
The model treats the customer's location as a string, and store records as strings too. It matches on textual similarity and returns something confident, usually the store whose name contains the customer's district rather than the one that's actually nearest, because name overlap is the strongest signal it has.
Check the answer against a map and it frequently is not the closest store. It may not even be in the right direction. What a correct answer requires:
- Resolve the customer's location to coordinates
- Retrieve candidate stores within a plausible radius
- Measure distance to each one across the road network, not in a straight line
- Rank by which is actually reachable, and return the nearest
Four steps, none of them linguistic. This is computation over geographic data. The model is doing text prediction and hoping the shape of the answer matches.
"How do I get from the station to your Shoreditch store?"
Ask for directions and the model will give them to you. Turn left, continue for 200 metres, right at the junction. The format is right, the tone is confident, and the route often doesn't exist. Compared against the real street network, generated directions cut across blocks with no through road, miss the obvious route entirely, send people the wrong way down one-way streets, and report distances that don't match the path described.
That's not carelessness. Routing is a shortest-path traversal across a graph of millions of connected segments, each carrying its own attributes: direction of travel, speed, turn restrictions, access rules. The answer comes from walking that graph. There's no way to arrive at it by predicting a sequence of sentences, because the sentences are the output of the computation, not a substitute for it.
"Find me a click and collect point on my way home."
This one looks like the easiest, and it's the most revealing. "On the way" reads like a casual phrase, so the model treats it as a preference and returns somewhere central and well known.
But "on the way" is actually a spatial constraint with real structure. It means the location falls within an acceptable detour from a route between two specific points. Answering it means geocoding both endpoints, computing the route between them, drawing a corridor around that route, and testing candidates against it. Whether somewhere is on your way depends entirely on geometry, and the phrase itself doesn't contain any.
The same applies to every constraint of this kind. Nearby. Between. Within walking distance. Close enough to justify the trip. These are all quantities, phrased as adjectives.
"Can this arrive today, given traffic?"
The model has another problem here. Even a perfectly computed route can go stale five minutes later. Real travel time depends on current flow, incidents, roadworks, temporary restrictions and closures. A model reflects typical conditions it's seen described, which is a historical average dressed up as a current answer.
Give it a search tool and it can retrieve a traffic report. It still can't recalculate the route under those conditions, or confirm the journey's possible before the cut-off. Fetching a traffic report isn't the same as recomputing the path through it.
This is not a freshness problem
The standard fix is to add retrieval. Let the model search, let it read current pages, and the embarrassing errors go away. It stops recommending stores that closed eighteen months ago.
That's a real improvement, and it solves a genuinely different problem. Retrieval fixes staleness. It tells the model what's true today.
What it doesn't do is establish spatial relevance. Whether a place is actually near the customer, whether it sits meaningfully between two points, whether it can be reached inside a delivery window, these are all questions about structure, not facts. No amount of fresh text answers them, because the answer was never written down anywhere to retrieve.
You could read every article, review and blog post ever published about a high street and still have no idea how many metres separate two shop doors. Nobody writes that down. Distance lives in coordinates and in networks. It doesn't survive being described in prose, which means it can't be recovered from prose.
Why it feels like the model knows
The illusion works because the model does hold real information about place. It can name the cities in a region, recognise landmarks, describe the character of a neighbourhood, recall roughly how far apart two capitals are, and suggest the places people talk about most.
All of that comes from statistical association between words. The model has learned that certain place names show up together constantly, and others never do. That association carries real signal about the world, enough to generate answers that read as geographically informed.
Underneath it, there's no map. No coordinates, no topology, no street network, no sense of which side of the river anything is on. The model can tell you a landmark is near a district, because those words appear together everywhere. It can't tell you the landmark's position, what connects to it, or how you'd get there, because none of that is stored as structure.
So the model has an accurate picture of what people say about places, and no picture at all of where those places actually are. The two look identical right up until you need a number.
Information versus structure
It's tempting to file this next to the model's known weakness with arithmetic. Language models approximate calculations from patterns rather than actually computing them, which is why they miscount and misadd, and why the fix is to hand the sum to a calculator.
Spatial reasoning is that problem with two additional layers.
First, structure. A sum only needs the numbers in front of it. A route needs a graph: nodes, edges, weights, restrictions, connectivity. The answer is a property of how the network is wired, and that wiring isn't something a model can work out just from having read about the places the network connects.
Second, time. A sum has one correct answer forever. A journey has a different correct answer at eight in the morning than at two in the afternoon, and a different one again once a road is shut. Any approach built on learned patterns is answering a question about a world that's already moved on.
That's why "the model will get better at this" is the wrong bet. A bigger model with more text still has tokens and probabilities where it needs spatial graphs, live data and deterministic algorithms. This isn't a capability that scales into existence. It's a different kind of machine.
Being honest about the split
None of this is an argument against language models in location features. It is an argument about which layer owns which job, and the split is unusually clean.
Models are strong at exactly the part that used to be hardest to build. They interpret a messy, ambiguous request and work out what the customer actually wants. They handle the customer who says "somewhere near the office, but not the big one" and ask a sensible follow-up question when the request is underspecified. They turn a structured result into a clear sentence. Building that with rules used to be close to impossible. Now it's straightforward.
Models are weak wherever the answer has to be computed rather than composed: geometry, network distance, travel time, address validity, current opening hours, anything that changes faster than a training cycle. These are the parts where being nearly right is exactly the same as being wrong.
What this means if you are building a location-aware agent
Drawn along that line, the architecture is not complicated:
- The model reads the request and decides what needs to be known
- A geocoding call turns text into coordinates, at building level rather than postcode centroid
- A distance or travel time call measures the real network under current conditions
- A location search call returns candidates that satisfy the spatial constraint
- Live store data answers whether a place is open, staffed and reachable
- The model composes the answer from results it was given, not numbers it produced
The rule underneath it: the model is never allowed to generate a quantity. It asks for one.
This matters more as these systems move from answering to acting. An assistant that describes a store is low risk. One that reserves the collection slot, dispatches the courier, or tells a customer their order arrives before six has made a commitment on your behalf. Every one of those depends on a spatial calculation being correct, and a model that produces confident text regardless of whether it computed anything is about the worst possible component you could put at that point in the chain.
The same holds anywhere an agent touches the physical world: planning a multi-drop route, coordinating a courier network, matching a job to the nearest available driver, quoting a delivery window at checkout. Every one of those is a spatial constraint problem with a customer's expectations riding on the answer.
The layer that gets skipped
Most of the effort in agent projects goes into prompting, tool definitions and orchestration. Comparatively little goes into whether the location data underneath is actually accurate, which stays uninteresting right up until the moment it becomes the whole problem.
If your assistant is going to tell a customer where to go, the address has to resolve to the correct building, the distance has to reflect the road rather than a line drawn across it, and the store record has to be current.
This is the part Woosmap works on: address autocomplete, geocoding, distance and travel time, location search. All of it returns a computed answer rather than a likely one, which sounds like a dull distinction right up until it's the thing deciding whether your customer actually arrives.
If you are building an agent, the Woosmap MCP server hands those services straight to the model as tools it can call, so it asks for the number rather than inventing one. It is documented at developers.woosmap.com/products/mcp-server/overview/.
The queries stay yours, too. They're not used to power advertising or any other product, which is a sharper question now that customers are talking to an assistant instead of typing into a search box.
Let the model do the talking. Let something built for it do the measuring.
Where to start
If you are building this now, the useful exercise takes an afternoon. Run those four queries through your own assistant, then check each answer against a computed one. The gap is usually wider than the team expects, and it shows you exactly which parts of your stack need a lookup rather than a better prompt.
The Woosmap APIs, and the MCP server that exposes them as tools, are documented at developers.woosmap.com and developers.woosmap.com/products/mcp-server/overview/. A free developer account gives you enough calls to run that comparison properly.