Address normalisation in the Baltics is harder than it looks

Every failed delivery has a story, and a surprising number of those stories begin before the van is even loaded — in a single line of text that a customer typed into a checkout box. Address quality is the quiet foundation of last-mile logistics: if you cannot reliably turn what a customer wrote into a precise point on a map, everything downstream degrades. The route is wrong, the driver is confused, the parcel is late, and the failure gets blamed on the courier when it was actually born at data entry.

In Western European markets this is a mostly-solved problem, because the tooling was built for those markets. In the Baltics it is not, and the reasons are specific enough to be worth explaining.

The same address, written five ways, all correct

Start with language. Lithuanian, Latvian and Estonian all decline nouns, which means a street name changes form depending on the grammatical case. A street written one way on a sign may appear in a different form when someone writes "I live on…". Both are correct. Your database probably stores only one.

Then there are the abbreviations. In Lithuanian a street might be gatvė (abbreviated g.), an avenue prospektas (pr.), an alley alėja (al.). Customers use the full word, the abbreviation, or nothing at all, interchangeably. "Savanorių pr. 178", "Savanoriu prospektas 178", "savanoriu 178" and "Savanorių pr.178A" may all be the same customer trying to reach the same door.

Now remove the diacritics. The letters ė, š, ų, č and their relatives carry meaning, but they get stripped constantly — by keyboards set to the wrong layout, by legacy systems that only store ASCII, by customers in a hurry. "Šiauliai" becomes "Siauliai", "Vėžaičiai" becomes "Vezaiciai". A naive string match treats these as different places.

A Baltic address is not a string to be matched. It is a structured fact wearing one of a dozen possible costumes, and the job is to see through the costume.

The apartment problem

Even once you have the right building, you often are not done. A large share of Baltic deliveries go to apartments in multi-storey blocks, and the unit detail — apartment number, entrance, floor — is exactly the part customers are most careless about. "Verslo al. 12-4" might mean apartment 4, or entrance 12 building 4, or building 12 apartment 4, depending on local convention and how the customer thinks about it. Get it wrong and the driver reaches the right building and cannot find the recipient, which is a failed attempt as surely as an unknown street.

The apartment and entrance detail is also what determines the courier's real service time — the walk to the correct door, the correct intercom, the correct floor. So resolving it is not just about finding the address; it is about feeding the route planner an honest estimate of how long the stop will take.

Why off-the-shelf geocoders fall short

Generic geocoding services are built to a global average. They are genuinely impressive at turning "10 Downing Street, London" into a coordinate. But they are trained and tuned for the markets that generate the most queries, and the long tail of Baltic morphology, abbreviation and diacritic handling is not where their effort goes. They will confidently return a point — often the centroid of the street, or the wrong building entirely — with no signal that they have guessed. A confident wrong answer is worse than an honest "I am not sure", because you act on it.

What last-mile operations actually need is different from what a map search needs. A map search can afford to be approximately right; a delivery cannot. The operation needs a canonical address, the precise access point, and — crucially — a confidence score it can act on before the parcel is loaded.

How we approach it

The address graph inside Kelvara treats resolution as a pipeline, not a lookup. In outline:

• Normalise the input. Restore likely diacritics, expand or standardise abbreviations, and reduce declined forms toward a canonical stem — before any matching happens.
• Match against authoritative data. The national address registries of all three countries are the ground truth for which streets and buildings actually exist. We match against them rather than a scraped map.
• Score the match. Every resolution comes back with a confidence value. An exact registry hit scores high; a fuzzy match with an ambiguous apartment scores lower and can trigger a second look before dispatch.
• Learn from outcomes. When a delivery succeeds or fails, that is a signal about whether the resolution was right. Access notes, corrected entrances and previous outcomes flow back and improve the next resolution at the same address.

That last point is the one that compounds. An address is not a static record; it accumulates operational knowledge. The tenth delivery to a building knows the intercom is broken and the courtyard entrance is the one that works, because the previous nine taught it. That knowledge is worth as much as the coordinate.

Why it is worth the effort

It would be easier to bolt on a generic geocoder and accept the failure rate. We built the address graph the hard way because address quality sits upstream of everything else we do. A wrongly resolved address produces a bad route, a confused driver and a failed attempt — and a failed attempt costs as much as a successful delivery while producing an unhappy customer instead of a happy one. Fixing the address is the cheapest possible place to prevent that failure, because it happens before a single kilometre is driven.

Address normalisation is not glamorous. It shows up in no marketing headline and wins no awards. But in a region where one address can be written five correct ways and none of them match your database, getting it right is the difference between a route that works and a day of redeliveries. In the Baltic last mile, the boring data problem is the one that pays.