The Who's On First gazetteer, concordance scoring, and resolver candidate ranking.
View All TagsType 'Vienna, Austria' into our geocoder and it confidently returned a town of ten thousand people in Appalachia. The obvious fix was a retrain. We ran the diagnostic first, and the obvious fix turned out to be the wrong one.
You can point a Nominatim client at Mailwoman now and get a geocoder from a SQLite file, without PostgreSQL or a planet import. We did, and the US worked beautifully while the rest of the world resolved to its American namesake. The bug was one line: we'd told it the answer was always America. This post covers the line, the four cities that still won't move once you delete it, and the ranking database we forgot to switch on — which faked the entire scoreboard until a contradiction gave it away.
We ran our 30 MB browser geocoder against the incumbents — Nominatim and Pelias — on real European addresses, scored the direct way. We'd won the US. Europe opened with a double-digit loss. The cause was silence: on messy addresses we returned no result at all. This post covers what caused the empty results, the three fixes that took us clear of both incumbents in Europe, and the one place — Australia — we've now diagnosed but not yet closed.
Open the demo and type an address in Kabul, and the demo returns no result. It does not place a pin a few streets off or fall back to the city center, because the gazetteer has no entry for Kabul. Hong Kong, Tirana, Chişinău, and every place in the Democratic Republic of the Congo return no result as well. We had been calling this gazetteer "world coverage" for weeks, and it covered 97 of the world's ~195 countries. The other ninety-odd countries were absent from the file.
The whole geocoder runs in your browser. You type an address, you get a rooftop coordinate, and no server ever sees your query — the gazetteer it resolves against is a SQLite database sitting on a CDN, and the page reads it with HTTP range requests, a few kilobytes at a time. It's a lovely trick. We were proud of it. Then we counted the requests it took to find a single city, and the number was 243.
Overnight I taught the geocoder Canada. Or I thought I did. I pulled 843,000 Canadian postcodes, computed a centroid for every one, spot-checked the result — M5H 2N2, downtown Toronto, 43.652, −79.382, dead on — and validated the database every way I could read it: every postcode present, every coordinate right, and no other data disturbed. Green, top to bottom. This morning, before flipping it live, I asked the demo to find a Toronto address. It dropped the pin in Ohio.
We turned the demo into a real geocoder. You type an address and get a rooftop coordinate, computed in your browser without a server. The last feature was autocomplete. It completes the city name while you type. We had shipped autocomplete as a command-line tool days earlier and seen it rank San Francisco above San Diego, so we considered it done. We connected the same function to the search box, typed New Yor, and it suggested Denver.
Our resolver scored 93.7% on the metric we'd been quoting for months. On the same addresses, its median answer was 326 kilometers from the truth. Both numbers were correct. Only one of them told the truth.
Our parser's international-order German 'collapsed' to 44%, so we retrained it three times. Then we measured the thing that can't be gamed and found out the model had been right all along. The metric was lying. Native German was sitting at 96%.
Our resolver kept dropping German addresses in New Hampshire, and our scorecard handed it a gold star every time. This post shows how a name-match metric lied to us for months, and how much a postcode hint improved placement once we measured by distance instead.