Daniel sent us this one — he's thinking about address geolocation and the absolute mess it becomes when you try to validate a physical place across different systems. He lives in Jerusalem, and he points out that Jaffa Street can be spelled Jaffa, Yafo, or Yaffo in English alone. Three variations for one street. Now multiply that across every language and every script, and suddenly the permutations are ridiculous. His question is: is there any universal physical place descriptor for an address that works across systems, or are we stuck with the autocomplete guessing game at scale?
This is one of those problems where the deeper you dig, the worse it gets. And it's not academic — global supply chains are breaking on this right now. A container of medical supplies gets held at customs because the delivery address in the carrier's system doesn't match what's on the commercial invoice. Not because it's wrong, but because two APIs romanized the same Hebrew street name differently.
We're not talking about a localization bug. This is a systemic failure.
Exactly the right framing. Addresses are human-readable descriptors. They're not machine-validatable identifiers. And the entire logistics industry has been papering over that gap with Google's autocomplete, which is like using a restaurant recommendation engine to do air traffic control.
Let's unpack why Jaffa Street has three names, and why that's a problem for everyone who ships things.
The core issue is this: an address is a cultural artifact masquerading as a data field. It works beautifully when a human reads it — "Jaffa Street 42, Jerusalem" — you know where to go. But when a machine needs to validate that "Jaffa St 42" and "Yafo Street 42" and "Yaffo St 42" all point to the same physical doorway, there's no canonical source of truth to consult.
The machine can't just say "close enough." It either matches or it doesn't.
And if it doesn't match, the shipment gets flagged, the address gets marked invalid, and somewhere a customer service agent is explaining to a frustrated warehouse manager why the pallet is sitting in limbo. The scale of this is enormous. In Israel, the Israel Postal Company maintains authoritative Hebrew addresses — those are the real, official addresses. But no single romanization standard is enforced across APIs. Google Maps picks one transliteration. Bing picks another. OpenStreetMap's Nominatim picks a third. They're all technically correct, and they're all different.
That's just Hebrew to English. Extend this to Arabic, Russian, Amharic, Chinese —
The permutations explode combinatorially. Chinese is particularly brutal because you've got Pinyin romanization, Wade-Giles in older systems, and then the original characters. A warehouse address in Shenzhen might have five or six valid English representations depending on which romanization convention the API uses.
What's actually happening under the hood? What is geocoding doing when you type an address?
To understand the mess, we need to look under the hood of how geocoding actually works. There are two directions. Forward geocoding takes a text address and returns coordinates — latitude and longitude. Reverse geocoding does the opposite: you give it coordinates, it returns the nearest address. The problem is that different geocoders use different reference datasets and different transliteration rules. So the same physical doorway at coordinates thirty-one point seven eight three, thirty-five point two one seven — that's roughly Jaffa Street — will return different address strings depending on which geocoder you query.
There's no arbiter that says which one is correct.
There isn't. Google Maps holds an estimated eighty percent plus market share in mobile mapping, which means it has become the de facto address authority by sheer gravitational pull. When a logistics platform needs to validate an address, it typically pings Google's geocoding API. If Google says "Yafo Street" and your database says "Jaffa Street," you change your database.
Which would be fine if Google were optimizing for validation accuracy. But they're not.
They're optimizing for consumer user experience. Google Maps wants to help a user find the nearest falafel place. It doesn't care whether the romanization is consistent with some academic standard — it cares whether the user can type "Jaffa" and get the right result. And Google's autocomplete is brilliant at guessing. It's terrible at deterministic verification. It doesn't verify. And over time, Google can change its transliteration choices. A query that returned "Jaffa Street" last year might return "Yafo Street" this year because they updated their language model.
If you're a logistics company that built a validation pipeline around Google's responses, you're building on sand.
The sand shifts. Let me give you a concrete comparison. If you take an address on Jaffa Street in Jerusalem and geocode it through Google Maps versus OpenStreetMap's Nominatim, you'll get different English representations. Google might return "Jaffa Street." Nominatim might return "Yafo Street." Both resolve to roughly the same coordinates, but the text strings don't match. If your validation logic does a simple string comparison — which many systems do — it flags a mismatch and rejects the address as invalid.
Even though it's the same street.
Even though it's the same physical place. Now, you might say, well, just compare the coordinates instead. And that's a partial fix — but coordinates have their own problems. A coordinate is a point, not a place. It doesn't tell you the building name, the floor, which entrance to use. And coordinate precision isn't perfect either — there's GPS noise, tectonic drift, different coordinate reference systems. A point is not an address.
The transliteration trap is really the heart of this. Hebrew to English is non-trivial in ways that people who only work in Latin scripts don't appreciate.
The variations Jaffa, Yafo, and Yaffo aren't random typos. They reflect different romanization standards. Jaffa is the colloquial English rendering that's been used for centuries — it's what tourists know. Yafo is closer to the modern Hebrew pronunciation and follows a more academic transliteration convention. Yaffo splits the difference, doubling the F to preserve the dagesh — the dot in the Hebrew letter that indicates gemination. Three different systems, all defensible, none authoritative.
Each API picks one arbitrarily.
Or worse, inconsistently. I've seen cases where Google Maps returns "Jaffa Street" for the road segment but "Yafo" for the neighborhood label, in the same API response. Now imagine you're a developer in Shanghai trying to ship something to Israel. You don't know Hebrew. You don't know which romanization is correct. You just know your system rejected the address and you don't know why.
This is the part where Google's dominance becomes a structural problem, not just a convenience.
It's a single point of failure and a lock-in problem. When a company builds its entire address validation stack around Google's geocoding API, it's not just using a service — it's adopting Google's worldview of what addresses are. And that worldview is English-centric, consumer-optimized, and opaque. You can't audit why Google chose a particular transliteration. You can't appeal it. You just accept it.
If you're a competitor to Google in some adjacent space — say you're building a logistics platform — you're now dependent on your competitor's reference data.
Which is an uncomfortable position. There are open alternatives. OpenStreetMap's Nominatim is the most prominent. It's community-maintained, free, and transparent about its data sources. But it has less coverage in some regions, and its transliterations can be inconsistent because they depend on which volunteer mapped which street and what romanization they happened to use.
Even the open alternative inherits the same fragmentation problem, just with different specifics.
The fragmentation is structural. It's not that Google is doing something wrong — it's that the entire concept of a text address as a machine identifier is broken.
We've got this fragmentation. What are people doing about it? And what should they be doing?
There are a few attempts to solve this from the ground up, and they take fundamentally different approaches. The most well-known is probably what3words. They divided the entire planet into three-meter by three-meter squares — about fifty-seven trillion of them — and assigned each square a unique three-word identifier from a fixed dictionary of forty thousand words. So the entrance to a specific building on Jaffa Street might be something like "piano.
Which is memorable in a way that coordinates aren't.
It's very human-friendly. You can say it over the phone. You can print it on a delivery label. Mongolia adopted it for their national postal system. Mercedes-Benz integrated it into their navigation. It's clever.
I hear a "but" forming.
First, it's proprietary. The word list and the algorithm are owned by a private company. They offer free use for individuals, but commercial use at scale requires a subscription. If you're a logistics company processing millions of addresses, you're paying. Second, the word assignments are language-specific. ranch" in English maps to completely different words in Arabic or Hebrew. So it's not language-independent — it's multi-language with separate dictionaries. Third, adjacent squares have completely unrelated word triples. ranch" might be next to "flame.tower" — there's no spatial relationship encoded in the identifier. That makes it hard to tell if two addresses are near each other without resolving them both.
It's precise but proprietary, and it doesn't encode proximity.
It struggles with large areas. If you're shipping to a warehouse that covers multiple three-meter squares, which one is the official address? You need to pick a specific entrance point, and if the driver approaches from a different direction, their three words might be different.
What about the open alternative?
Open Location Codes, also known as Plus Codes. This is the one that I think is technically the most interesting. Google developed it, but crucially, it's open-source and patent-free. It encodes geographic coordinates into a short alphanumeric string. A typical Plus Code looks something like "eight G four Q two Q eight F plus four F" — that's a specific building in Jerusalem.
Not exactly rolling off the tongue.
It's not meant to be poetic. It's meant to be deterministic, free, and work offline. You don't need to phone home to a server to resolve a Plus Code. The algorithm is public — you can encode and decode coordinates yourself. It's designed so that codes that are close together spatially share a common prefix, so you can truncate them. The first four characters get you to a city-level area. The full code gets you to roughly a fourteen-by-fourteen-meter square — not quite as precise as what3words, but close.
It's language-independent by design. The characters are from a set that avoids easily confused letters and numbers — no zero versus O, no one versus L.
They removed vowels and visually similar characters specifically to avoid the transliteration problem entirely. A Plus Code is the same string whether you're in Tokyo, Tel Aviv, or Toronto. That's the killer feature for logistics.
Adoption is low.
Google integrated Plus Codes into Google Maps — you can tap and hold to get one. They're used in some emergency services in developing countries where street addresses don't exist. India's postal system has experimented with them. But most people have never heard of them, and most logistics platforms don't support them as a native address format.
We've got a proprietary system with good marketing and an open system with no marketing.
That's the what3words versus Plus Codes story in a sentence. And here's the thing — neither of them is actually an address. A Plus Code is a grid reference. It tells you where something is, not what it's called or how to interact with it. It doesn't encode the building name, the floor number, the delivery instructions. What we really need is a hybrid: a human-readable address that can be cryptographically or algorithmically linked to a canonical location identifier.
The text address "Jaffa Street forty-two" would carry with it a verifiable Plus Code or similar identifier that says "regardless of how you romanized this, the physical location is here.
And that linkage needs to be verifiable across systems. You shouldn't have to trust Google's transliteration — you should be able to independently confirm that the text address and the location code resolve to the same place. Some people have proposed using cryptographic hashing of coordinates combined with a canonical name registry, but nothing like that exists at scale.
Let's make this concrete. Walk me through what happens today with a real shipment.
Take a shipment from Shenzhen to a warehouse in Beit Shemesh, Israel. The Chinese exporter writes the destination address in Chinese characters on the commercial invoice. The Chinese carrier romanizes it using their internal system — probably Pinyin-based, but maybe not. That romanized address gets transmitted to the Israeli carrier's system, which has its own romanization of Hebrew addresses. The Israeli system tries to match the incoming address against its database. It fails, because the Chinese romanization of the Hebrew place name doesn't match the Israeli romanization of the same place name. The shipment gets flagged for address validation. A human has to intervene.
How long does that intervention take?
Could be hours, could be days. Meanwhile, the shipment is sitting in a container yard accruing demurrage fees. Multiply this by thousands of shipments daily, and the cost is enormous. Now imagine both systems included a Plus Code as a secondary identifier. The Chinese carrier generates the Plus Code from the coordinates of the destination. The Israeli carrier receives it, decodes it, and immediately knows the exact physical location regardless of what the text address says. The text address becomes the human-readable label, and the Plus Code becomes the machine-verifiable ground truth.
That works because the Plus Code algorithm is deterministic and public. Both sides can compute and verify it independently.
No server required. No API key. No licensing fee. Just a few lines of code. That's the power of an open, algorithmic location code versus a proprietary lookup service.
Why isn't everyone doing this?
Coordination problems are the hardest problems. There's no standards body mandating Plus Codes on shipping documents. No major carrier has built it into their workflow. The cost of adding it is low, but the organizational inertia is high. And what3words has done a much better job of commercial partnerships — they've got deals with logistics companies and automakers. Plus Codes are technically superior for this use case, but they've had essentially zero commercial evangelism.
It's the classic open-source adoption problem. Better technology, worse distribution.
Google's own relationship with Plus Codes is ambivalent. They developed it, they open-sourced it, they integrated it into Maps — but they don't aggressively promote it. Probably because Google Maps is a commercial product that benefits from address lock-in. Every address query that goes through Google's geocoding API is data they can use to improve their maps. Plus Codes bypass that.
Google has a structural disincentive to promote the open standard they themselves created.
It's an awkward position. They deserve credit for developing and open-sourcing it. But the business model of Google Maps depends on being the intermediary between addresses and locations. Plus Codes eliminate the intermediary.
Given all that, here's what you can actually do if you're building a system that needs to validate addresses.
First, don't rely on a single geocoding API. Build a multi-provider fallback chain. Start with Google, fall back to OpenStreetMap's Nominatim, fall back to Bing. But crucially, add a normalization layer that handles transliteration variants before the address ever hits the geocoder. That normalization layer should maintain transliteration tables for high-traffic regions — Israel, the UAE, China, Russia — to catch common romanization variants.
"Jaffa," "Yafo," and "Yaffo" all get normalized to a single canonical form before you even ask the geocoder to resolve them.
And you build those tables by analyzing your own data. Run a batch geocoding test across multiple APIs. Take your existing address database, send every address to Google, Nominatim, and Bing, and measure the mismatch rate. You'll probably find that five to ten percent of your international addresses return inconsistent results. Those inconsistencies are your normalization targets.
That's the kind of thing you can do on a Monday morning and have results by Wednesday.
Second actionable step: adopt Open Location Codes as a secondary identifier for every address in your database. It's free, it's open, and it gives you a deterministic fallback when address strings conflict. You don't need to replace your existing address fields. Just add a Plus Code column. When two addresses fail a string match but have the same Plus Code, you know they're the same place.
You can generate Plus Codes offline, so you're not dependent on any external service.
The algorithm is public. There are libraries in pretty much every language. It's a weekend integration project, and it future-proofs your address database against the next time Google changes its transliteration model.
For international shipping specifically, pre-compute transliteration tables for your high-traffic corridors. If you ship a lot between China and Israel, invest in mapping the common romanization variants of Israeli addresses as they appear in Chinese carrier systems. That's not a general AI problem — it's a specific, tractable data problem. You're not trying to solve all of transliteration. You're solving the transliteration of a few hundred street names that account for eighty percent of your volume.
The advice is: multi-provider geocoding with a normalization layer, Plus Codes as a secondary identifier, and targeted transliteration tables for your busiest routes. None of this requires a breakthrough. It's all implementable with current technology.
None of it requires waiting for a universal address standard to emerge. Which brings us to the bigger question.
Even with those fixes, the bigger question remains. Will we ever get a universal address standard, or is fragmentation the permanent state?
I think the answer is that fragmentation is permanent for the human-readable layer — and that's fine. Language is messy. Streets will always have multiple names across cultures and scripts. The solution isn't better maps or better transliteration. It's better abstractions. A layer that sits between the human-readable address and the machine-verifiable location, translating one to the other in a way that's deterministic, open, and verifiable.
That layer doesn't exist yet as a standard. It exists in pieces — Plus Codes, what3words, various geocoding APIs — but nothing ties them together into a universal address descriptor.
The closest thing we have is probably the Plus Code approach: an open, algorithmic encoding of coordinates that any system can compute and verify independently. But it's not an address. It's a grid reference. The missing piece is the binding between the human-readable address and the canonical location code — something that says "Jaffa Street forty-two, in all its romanization variants, resolves to Plus Code eight G four Q two Q eight F plus four F, and you can verify this without trusting any single provider.
As AI agents and autonomous delivery scale, this becomes critical. You can't have a delivery drone guessing which romanization to use.
The autocomplete guessing game won't cut it for robot routing. An autonomous delivery vehicle needs a deterministic location reference. It can't type "Jaffa" into a search box and hope for the best. It needs to know, with cryptographic certainty, that the drop-off point is exactly here and not fourteen meters to the left.
That's the shift that I think will eventually force adoption. Not human frustration with failed deliveries — we've tolerated that for decades. But autonomous systems can't tolerate ambiguity. They need ground truth.
Ground truth in location isn't a text string. It's a coordinate pair, or something algorithmically derived from one. The Jaffa Street problem isn't just about Israel. It's a microcosm of how human language and machine systems collide. Every country with a non-Latin script has this problem. Every logistics company that crosses a script boundary hits this. The solution isn't better maps. It's better abstractions.
The abstractions exist. They're just not connected to the addresses yet.
That's the engineering challenge. Not inventing new location technology — we have that. It's building the bridge between the human layer and the machine layer. And that's a coordination problem, which means it's a people problem, which means it's the hardest kind.
And now: Hilbert's daily fun fact.
Hilbert: In the early fifteen hundreds, Portuguese sailors in the Comoros archipelago encountered a snake whose venom caused victims to laugh uncontrollably before paralysis set in. They named it "cobra de riso" — the laughter snake — a name that later linguists traced to a mistranslation of the local Swahili word for "tickling," since the venom caused a tingling sensation that islanders described as being tickled from the inside.
Tickled from the inside. That's deeply unsettling.
The Jaffa Street problem is everywhere, and it's not going away. But the tools to work around it are already in our hands — we just need to wire them together. This has been My Weird Prompts. Thanks to our producer Hilbert Flumingtop. If you enjoyed this, email the show at show at my weird prompts dot com. We'll be back soon.
