Status: ✅ Cracked · eeu.cty validated against real-world cities (Tirana, Timișoara, Iași, Sofia)

74.2 MB, NOT_COMPRESSED, 939,351 records.

• Same 94-byte header, then fixed 79-byte records, no gaps ((74,208,823 - 94) / 79 = 939,351 exactly).

Bytes	Field	Notes
[0:4]	self-referential sequential index	record i's index always equals i (sanity check, not needed for lookups)
[4:6]	candidate finer admin-region reference	Unresolved
[6:10] / [10:14]	bounding box MIN longitude/latitude (SW corner), int32 LE, /100000	✅
[14:18] / [18:22]	bounding box MAX longitude/latitude (NE corner)	✅
[22:57]	name, UTF-8 (not Latin-1 — confirmed by "TIRANË" needing UTF-8 to decode correctly), NUL-padded, "<place>, <parent place>" or bare "<place>"	✅
[57:59]	country tag — constant across one country's whole block	✅ Cracked — 35 distinct values, one per real eeu.ctr country (does not match .ctr's own row index; a separate numbering, resolved empirically by matching each tag group's real-world centroid, see build_country_tag_map())
[59:63]	—	Unresolved int32
[63:71]	a second, more precise representative point (lon, lat, /100000)	✅ — consistently closer to a real "city center" than the bbox midpoint
[71:75]	—	Unresolved int32, frequently an explicit -1/0xffffffff sentinel
[75:79]	—	Unresolved uint32

Bounding-box hierarchy validated directly: a top-level entry with no name comma ("LAMPEDUSA E LINOSA", the whole comune) has a box wide enough to span both its islands (~40km apart); a small locality inside it ("GUITGIA, LAMPEDUSA E LINOSA") has a ~1km box fully nested inside the comune's. Box area correlates with administrative level, making it a usable zoom-dependent importance proxy for display.

Real-world validation: record 220303 "TIRANË", bbox (19.698,41.248)–(19.952,41.397), representative point (19.825,41.322) — real Tirana is (19.819°E, 41.328°N), inside the bbox, ~700m from the representative point. Similar exact matches found for Timișoara, Iași (via clustered Romanian postal-code sub-records), and Sofia (via clustered Bulgarian postal-code sub-records).

.cty alone is sufficient for both name search and zoom-dependent display — a plain in-memory substring scan over the whole 74MB file takes ~0.3s, no separate index needed.

75.8 MB, FLAT_COMPRESSED (see container format). Fixed 54-byte records, 4,084,104 on the reference disc, no gaps: bytes[0:4] candidate index into eeu.cty, bytes[4:54] (50 bytes) a UTF-8 search-key name (ASCII-transliterated and/or ;-sort-key-rewritten, same demotion convention as .prl — see Name Search Catalog).

Validated at the same confidence level accepted for .rl's own .rd pointer: 314/500 (62.8%) of a random sample match the pointed-to .cty name exactly or by substring; the rest are transliteration/;-rewrite/ same-cluster-sibling cases, no outright-wrong pointer found. Not required for basic search/display — .cty alone already covers that.

5 MB, FLAT_COMPRESSED. Same 19-byte-node, subtree_size-skip-pointer structure as eeuz.rt (see Name Search Catalog) — confirmed by the identical pointer hit-rate test (80.7% on a 14,283-node sample vs. a 4.31% base rate, matching .rt's 72.8%-vs-4.2% closely enough to be clearly the same mechanism). Walking sampled subtrees spells real Russian/former-USSR administrative vocabulary (RAYON, KOZHUUN, SAVYET). Not deeply pursued beyond this structural confirmation (the practical search/display need is already covered by .cty directly).

The running map viewer uses eeu.cty directly (via PrefixNameIndex) for live per-letter Address Entry narrowing, specifically not the .ct trie — "SOFIA" was directly confirmed unreachable from .ct's own 'S'-prefix shard, matching the same kind of "forest of shards, not one connected tree" gap already documented for .rt.

research/city_reader.py (CtyCache, PrefixNameIndex, build_country_tag_map()).