Road Naming Join

Status: ✅ Cracked — not a file format, but the join logic that turns an unlabeled rendered polyline (from tile geometry decoding) into labeled segments ("these vertices are DC158, these are STADION, ...").

Reader: research/road_naming.py.

Why it works

decode_features() accumulates each vertex in integer delta space and only divides by 100000 once at the end, so round(lon*100000) reliably recovers the exact original int32 for a genuine on-road vertex — the same bit-exact match already used to validate tile decoding itself. build_rd_index() reads the whole 590MB eeu.rd into memory once, uses numpy to vectorize the coordinate decode + bounding-box filter across all 8.8M records (sub-second), then builds an exact-match dict {(lon, lat): name} plus a degree-binned grid for a nearest-within-tolerance fallback (default 75m) over just the records inside the requested box. ~0.3–0.7s per call, dominated by the initial file read.

match_feature() matches every vertex of one decoded feature (exact lookup first, then nearest-within-tolerance) and collapses the per-vertex results into contiguous (start_idx, end_idx, name_or_None) ranges — reflecting, not hiding, the fact that one feature can legitimately chain through several different named roads.

Validation

Two independent real areas, generic coordinate-join logic, no per-example special-casing:

• A canonical 2-feature Iași tile: the 392-point feature resolves to 17 distinct real names across contiguous vertex ranges; the 154-point feature resolves to 16 more.
• A Timișoara-area tile: its single 182-point feature resolves to "DC158" at vertices 0–3 (reproducing the original single-vertex DC158 validation exactly), then "DN59" and "DJ592B" further along the same chain.

Known limitations

1. eeu.rd is not spatially sorted, so build_rd_index() is a per-call bounding-box scan of the whole 590MB file — fine to call once per visible map area, not fine to call every pan/zoom frame.
2. The nearest-tolerance fallback uses a flat degree-distance grid with a latitude-only meters-to-degrees conversion, applied isotropically to both lon and lat — conservative (may occasionally miss a real match near the dataset's poleward edge), never falsely permissive.
3. Most .rd records don't correspond to any tile vertex at all — .rd looks like a name+anchor catalog, not a full shape-point store. A fully-continuous "every vertex has a name" labeling should not be expected; unmatched runs are "unlabeled connecting geometry," not an error.
4. Ambiguity between two close-together differently-named roads within tolerance isn't resolved (first-found wins, undefined order) — not observed as a practical problem, but not proven absent either.

Reader code

research/road_naming.py — RdCache, build_rd_index(), match_feature(), distinct_names().