8 posts tagged with "International"

Feed an address into a sequence labeler and part of it goes missing. The model tags the tokens it recognizes — house number, street, city — and the characters it doesn't understand fall on the floor. decodeAsJSON hands you back a tidy object with every field in its place, and no field in that object tells you the modelshrugged at a fifth of the input.

So you ship that parser. It looks great on the addresses you tested it against. And you have no idea what it's dropping in production, because the output format was built to hide exactly that.

You can point a Nominatim client at Mailwoman now. It serves the same endpoints (/search, /reverse, /status) with the same JSON shape, so your existing code does not change. The backend is different. It needs no PostgreSQL, no osm2pgsql import that takes hours and tens of gigabytes, and no separate server, so it can ship inside an app. It answers Nominatim's queries from a SQLite file.

Our geocoder had beaten Nominatim across the United States by fifteen points, so we ran the same benchmark on Europe and expected a similar result. Europe produced a double-digit loss.

A loss to Nominatim would have been acceptable, because Nominatim covers the whole planet on community-contributed data and is the standard to beat. We could not explain the loss, though. We knew our parser was not ten points worse in Europe than in America, so we investigated what the gap consisted of.

This post covers the cause, the fixes, and the problems the fixes did not solve. For the European comparison we added a third system: Pelias, through geocode.earth. geocode.earth hosts Pelias on Elasticsearch. Pelias turned out to be the stronger competitor, and this post states where it still beats us.

Our parser scores 28% on Spanish addresses. By the metric that reads its labels, it is, on paper, broken in a country of forty-seven million people.

That metric is measuring the wrong thing. The moment we measured the right one, the panic fell apart.

The last postcode post concluded that the "which country is this" signal has to come from the trained model reading the whole string, because the postcode by itself settles the question less than half the time. That is the expensive version of the feature. In this post we built the country signal into the model. It improved German addresses in native word order by a large margin and did not help the same addresses in a different word order.

We took the postcode's gazetteer membership (the [us, de, fr] answer from last time) and injected it into the model at the postcode token instead of passing it to a regex. The injection is a small additive vector on the hidden state at the position of the five digits, encoding which countries the code could belong to. On German addresses in German word order, it added thirty-five points of locality accuracy and beat Pelias.

The international-order numbers were much worse. With the same model, the same anchor, and the same German cities written house-number-first with the postcode after the city (the way our test feed renders them), the model scored slightly above 50%. On those rows the anchor did slightly worse than no anchor.

The rest of this post addresses three questions:

• When a parser "collapses" on a test, is the parser wrong, or is the test?
• Can you train one model to read an address in any order, or does each order cost you the other?
• What does a learned anchor learn: the meaning you intended, or the position where it appeared in training? This one took three retrains to answer.

For about a month our resolver used one method. It takes a postcode, finds the city polygon that contains the postcode's centroid, and reads off the city. The method got the Netherlands to 95% and Germany to 93%. Then we ran it on Japan, and Japan's gazetteer data has no city polygons.

This post covers two countries where the gazetteer data is sparse, what a geocoder can still do there, and where it stops. We resolved Japan to 94% by replacing the polygon lookup with a postal-authority lookup. Korea had the opposite problem. We could place the coordinate correctly for every postcode, but we could not confirm the name of the place most of the time.

The work raised three questions:

• What do you do when the gazetteer gives you points where you expected shapes?
• Does the method that worked for Japan generalize, or did it work only once?
• What happens when the map is missing data for the part of a country you most need?

We set out to fix a small problem in our address parser and measured a number that told us not to build the larger change we had planned.

The small problem is this. When our postcode extractor sees a five-digit run, it has to decide whether the run is a real postcode or a house number that looks like one. It checks the neighboring words against every country's street vocabulary we know (American, German, and French) at once. This works with three countries. At twenty countries, a German street suffix starts matching an English word by coincidence. We looked for a way to tell the extractor which country's words to check.

That question leads to a larger one, and this post is mostly about the larger one.

In Tokyo, the address of Tokyo Tower is 〒105-0011 東京都港区芝公園4-2-8.

In English: "4-2-8 Shibakōen, Minato City, Tokyo 105-0011".

The Japanese form runs right-to-left compared to the English form. The prefecture (都道府県) comes first, then the city or ward (市区町村), then a district (丁目) and a block-number-style locator. There's no street name — just a grid.

This is why every rule-based address parser written for Western addresses breaks on Japan.