Japan has no city polygons. The postcode resolves it anyway.

Date: 2026-06-05 Scope: the CJK resolution arena — the point-geometry finding (JP/KR/TW), the pivot from point-in-polygon to authoritative name-match, and Japan landing at 94% built / 94–98% resolved.

We spent the European locales teaching a resolver to drop a postcode's centroid into a city's polygon and read off the city. Then we pointed it at Japan, and the first thing it told us is that Japan doesn't have the polygons. The second thing it told us is that it doesn't matter.

The wall: there are no municipality polygons in CJK

The European coordinate-first recipe is point-in-polygon: take a postcode centroid, find the WOF locality whose polygon contains it, done. It got Germany to 92.6% and the Netherlands to 94.9%. It gets Japan to 25% — and it took a while to understand why, because the failure is structural, not a tuning gap.

WOF's administrative geometry for the CJK countries is point-based exactly where postcodes resolve. We sampled the per-placetype geometry and the pattern is the same across all three:

WOF placetype	maps to	JP	KR	TW
region	prefecture / province	polygons	—	polygons
county	sub-prefecture / ward	polygons	69%	3%
localadmin	municipality (市区町村)	0%	0%	0%
locality	sub-municipality	~1%	~0.4%	~1%

The level a postcode actually resolves to — the municipality — is essentially all points, in Japan, Korea, and Taiwan alike. So point-in-polygon has nothing to contain. This isn't a Japan quirk we can special-case around; it's the shape of the whole CJK arena, and it means the European recipe doesn't generalize east. Confirmed, quantified, written down.

The pivot: resolve by authoritative name, not by polygon

If you can't ask "which polygon contains this point," you ask the postal authority "what's the municipality for this postcode," and then you find that municipality in WOF. Japan's postal authority publishes exactly that — KEN_ALL, from Japan Post, and crucially a romanized edition whose municipality column reads SAPPORO SHI CHUO KU, in the same alphabet as WOF's romanized place names. Authoritative, and matchable.

Getting it was its own small saga: every KEN_ALL download URL we knew was a 404, the new ones are gated behind JavaScript and a Japan-only fetch, and the file when it finally arrives is CP932/Shift-JIS from 2025. But it arrives, and it carries the one thing WOF's own postcode hierarchy doesn't — the municipality, not just the prefecture (WOF's postcode→admin chain stops at the prefecture, far too coarse).

The build is then a different shape feeding the same machinery:

postcode → KEN_ALL municipality NAME (romanized, authoritative)
postcode → GeoNames point
name + point → match to a nearby WOF place → WOF id, with is_containing=1

That last step writes the ordinary postcode_locality table, so the existing postcode_area_resolution strategy resolves Japan with zero new resolver code. The European locales drop a centroid into a polygon; Japan matches an authoritative name to a point. Same table, same strategy, different build — which is exactly the division of labor the Geographic Rule Engine was built to carry.

The detail that moved it from 52% to 94%

The first name-match attempts capped at 52–60%, and the reason is a lesson about WOF's CJK modeling: Japanese municipalities are split across WOF placetypes. A regular city is a locality. A designated-city ward is a county or localadmin. A Tokyo special ward is a borough. Match against any single placetype and you miss half the country — Osaka's 530-0001 resolves to Kita (the correct ward) but you scored it against locality and found a town named Kita three prefectures away.

Search all the municipality-ish placetypes at once — locality + county + localadmin + borough — and keep the one whose name appears in the authoritative municipality string, nearest first, and it jumps to 94.9%. The granularity inconsistency that capped the single-placetype match dissolves when you stop assuming WOF models municipalities in one place.

Results

n = 2,000 postcodes, scored two ways:

measure	result	gold
build name-match	94.9%	KEN_ALL (authoritative)
end-to-end resolver (city text + postcode)	98.5%	KEN_ALL
end-to-end resolver, independent cross-check	93.9%	GeoNames admin2 (sourced separately from KEN_ALL)

The 93.9% is the one to trust: GeoNames' municipality field comes from a different lineage than KEN_ALL, so a resolved place agreeing with it isn't the build grading its own homework. Japan resolves its postcodes to the right municipality nine times in ten, with an out-of-distribution parser and no city polygons, because the postcode is language-agnostic and the postal authority is right.

Merging Japan into the shared asset left the European locales byte-identical — Germany, France, Britain, and the Netherlands resolve exactly as before; Japan rides alongside them.

What it doesn't do yet, and what it proved

The honest edges: a bare ward name shared across cities (Chuo alone, no city) can still let the resolver's exact-name tiering pick the wrong region over the postcode — the realistic city-token flow resolves at 98.5%, so it's an edge, but a proximity-gated exact tier would close it and help the European locales too (filed separately). Korea is obtainable but its GeoNames names are Hangul against WOF's romaji, so it wants a coordinate-match to sidestep transliteration. Taiwan is the real gap — no GeoNames postal file at all, and it isn't in the admin DB yet.

But the thing this validated is bigger than Japan. The point-geometry wall is CJK-wide, which means name-based-from-the-postal-authority isn't a Japanese workaround — it's the CJK resolution architecture, and the convention/strategy machinery already holds it: a different build for a different data shape, feeding one unchanged resolver. The European recipe didn't have to bend to fit Asia. We just wrote the second recipe and pointed the same engine at it.