Ask a GIS team about their most persistent data problem and UK geocoding will come up quickly. It looks simple enough: feed in an address, get back a pair of coordinates. Then a postcode turns out to cover half a village, a point lands in a field, and a first-floor flat gets pinned to the shop beneath it. Most of the trouble traces back to the same handful of causes. Here are seven of the most common, with practical ways around each.

1. Treating a Postcode as a Precise Point

A postcode is an area, not a location. A typical unit covers anything from a handful of addresses on one side of a street to a scattered group of rural properties, and the coordinates most services return are a representative point — often the centroid of that area, sometimes snapped to the nearest building. Neither is wrong, but neither is the front door.

The error shows up in analysis. Draw a one-kilometre catchment around postcode centroids and you will include properties that fall outside it while missing others that fall inside. Route a van to the centroid of a rural postcode and the driver may end up at a gate in a field. For anything distance-dependent, be explicit about the granularity you are working at: postcode-level answers are perfectly adequate for some questions and misleading for others.

2. Mixing Up Coordinate Systems

Three systems turn up constantly in UK work. British National Grid, EPSG:27700, uses the OSGB36 datum and gives eastings and northings in metres. WGS84, EPSG:4326, gives latitude and longitude in degrees. Web Mercator, EPSG:3857, is what most slippy maps use for display.

The difference between OSGB36 and WGS84 is not a rounding error — it is often tens of metres and in places more than a hundred, enough to put a point on the wrong side of a road. Dropping eastings into a tool expecting degrees, or assuming that "latitude and longitude" always means WGS84 (EPSG:4277 also exists, and it is not the same thing), creates errors that are almost invisible on a zoomed-out map.

• Store the EPSG code alongside every coordinate pair, without exception.
• Transform properly, using OSTN15-based transformations rather than a basic three-parameter shift where accuracy matters.
• Reproject only at the edges of your workflow — pick one storage format and stick to it.

3. Underestimating How Messy Address Matching Is

Geocoders rarely fail on "10 Downing Street". They fail on the addresses that carry real-world detail.

• Sub-building information: "Flat 3, 12A Bellevue Road" is three different addresses if you ignore the flat number.
• Named properties: "The Old Forge, Main Street" has no number at all, and may share a postcode with six other houses.
• Ranges and multiples: "1–3 High Street" and "Units 4–7 Kingsway Business Park" need a decision about which point you actually want.
• Business names mixed in: "Harbour Cafe, 2 Quay Street" will confuse a matcher expecting a street address.
• Typos and abbreviations: "Rd", "Road" and "RD." should all resolve to the same thing.

Normalise before you match — case, punctuation, common abbreviations — but keep the original string untouched in a separate field. It is your audit trail when someone asks why a customer is plotted in the wrong town.

4. Relying on a Single Data Source

No single dataset covers every UK address. The Royal Mail PAF is a postal product: it tells you which addresses receive mail and under which postcode, but it does not carry coordinates. Ordnance Survey AddressBase adds UPRN, positional coordinates and classifications, including many addresses that never receive post, but it still will not contain the barn conversion signed off last month.

The gaps are predictable: new builds, properties under construction, houseboats, static caravans, houses split into flats, and agricultural buildings. Plan a fallback — a second dataset, a manual review queue, or a clear "unmatched" state — rather than forcing a best guess that quietly pollutes your data.

5. Forgetting That the UK Is Not Uniform

Address conventions vary across the four nations and the Crown Dependencies, and treating them as one block causes avoidable errors.

Northern Ireland uses BT postcodes and a different address infrastructure, with Land & Property Services maintaining the Pointer dataset rather than Ordnance Survey. Scotland has its own patterns of named properties and rural addressing. Jersey, Guernsey and the Isle of Man use JE, GY and IM postcodes and are not part of the UK at all — worth knowing if your "UK" dataset quietly includes them. A small number of postcodes, such as GIR 0AA and BFPO codes, are not geographic in the usual sense and will never resolve to a meaningful point.

6. Discarding Match Quality Information

A coordinate without context is a liability. Two addresses geocoded to rooftop precision and to a postcode centroid look identical once the numbers sit in a column, and six months later nobody can tell them apart.

Record the match level for every result — rooftop, building, interpolation, postcode centroid, locality centroid, unmatched — along with the source dataset, the date and any confidence score. Keep the original input address beside the output. This costs almost nothing at the time and saves days of investigation later.

7. Never Testing Against Awkward Addresses

A geocoder that handles a clean sample beautifully may struggle badly with the cases that matter most. Build a small test set of genuinely difficult records: a flat above a shop, a farm with no number, a new-build estate, a business park unit, a property sharing its name with three others in the same parish. Run it after every change to your pipeline.

Then check the results by eye on a map. Automated scores will not tell you that your points are consistently 80 metres north-east of the buildings they represent.

A Short Practical

Photo: craveiro_ pics / Pexels