Crack all remaining eeu.rd header bytes via eeu.mod's own binary field descriptors + DBAL.OUT disassembly Disassembled db_road.cpp's read_current_record_from_database in DBAL.OUT to get the real field read order and names (countryID, cityID, prefix, suffix, rdtype, roadinfo), confirming delta_long/delta_lat get converted to a max-corner on read. The real unlock was eeu.mod itself: its binary bytes (not just the field-name strings already extracted) carry a real per-field width/bit-offset descriptor, cracked this session and validated byte-exact against eeu.ctr's own known layout. Applied to eeu.rd's schema block and validated against real file data: cityID (bytes[1:4], 24-bit) shows 50.3% same-value match among geographically nearby records vs ~0.025% expected by chance; typeID (bytes[5:7]) ranges 0-2571, matching eeu.typ's 2,574 real entries almost exactly; roadInfo bit0 (highway) correlates with route-like names at 89.95% vs 0.10%; suffixID/prefixID (byte[0]'s two nibbles) are independent and both span the full 0-15 range. All 8 previously unresolved header bytes are now accounted for, with zero bits wasted in the roadInfo byte's 6 packed sub-fields.
Crack eeu.rd's delta_long/delta_lat: a real segment bounding-box extent eeu.mod's own schema names this table's real fields in order: ...min_long, min_lat, delta_long, delta_lat, name... -- min_long/ min_lat sit exactly where the already-verified longitude/latitude fields are, putting delta_long/delta_lat exactly at the 2 fields previously listed as "unresolved, small values" (bytes[16:20]/[20:24]). Validated at real scale (20,000-record random sample across the whole 8.8M-record file): zero negative values for either field, implied segment diagonal median 350m / mean 1.1km, 96.8% under 5km, 99.9% under 50km -- exactly the real-world range of named road-segment lengths. Also checked the firmware side directly (user asked specifically): dbal confirms real db_road.cpp/db_road_list.cpp/db_road_cache.cpp/ db_road_sel_char.cpp source files and one accessor (db_road_NameListDataByIndex_V004), but unlike eeu.si's rich db_seg_* catalog, no further per-field road-classification accessors were found -- the firmware confirms the handler exists but doesn't hand over a field-by-field breakdown. The remaining 14 eeu.mod field names (cityAndCountryID through interchange) packing into 8 still-unresolved bytes remains open; highway as a single bit of byte[0] tested and refuted (zero correlation with route-like names across all 8 bits).
Advance eeu.iof: eeu.mod schema names, il-reference-count correlation, correct eeu.rd bytes[1:5] eeu.mod names the table intersectionOffsetFile with real fields offset/ type/count, confirming and renaming zero4/vb/c80. type's value shape (0x80 default vs {0,1} for real anchors) now reads as a clean bit-7 discriminator. New lead for the long-unresolved common-case count field: correlates moderately (r~0.21) with how many eeu.il entries reference the same eeu.rd record -- a real signal, not an exact formula. Two other hypotheses (eeu.rd's own bytes[1:5]; local road density as a literal intersection-count proxy) were tested and refuted. Major correction found along the way: eeu.rd's bytes[1:5] has 6,174 distinct values at full file scale, not '~5 distinct patterns' as previously reported from a small sample. Also refutes the direct-embed hypothesis against eeu.si's own bit layout. Fixed across eeu-rd-Road-Routing-Graph.md, eeu-si-Segment-Classification-Table.md, eeu-mod-Database-Schema.md, eeu-iof-Parallel-Road-Array.md, Home.md.
Partially crack eeu.si, correct the eeu.rd bytes[1:5] cross-reference lead Fixed 8-byte records, validated at full file scale (24,353 records). Cracked byte 0 (rank/class/divided) and byte 4's low nibble (route_num_type/paved), in exact eeu.mod schema order, with plausible bounded value ranges and realistic real-world rates (paved ~95%, divided ~16%). 15 more named fields in bytes 1-3 not yet assigned. Also corrects a previous session's lead: eeu.mod's write-up flagged eeu.si as a strong candidate for eeu.rd's unresolved bytes[1:5]. Checked directly -- eeu.rd's ~5 distinct patterns there are far too few to index eeu.si's 20,381 distinct records, so that specific cross-reference doesn't hold up. Corrected on eeu-mod-Database-Schema.md and eeu-rd-Road-Routing-Graph.md. Adds eeu-si-Segment-Classification-Table.md, updates Home.md, Unexamined-Files.md, and _Sidebar.md.
Add full file-format wiki: home status table + per-file detail pages Documents every file on the CD_8555 map disc (db/ folder): byte layouts, decode status (cracked/partially cracked/not examined), and validation evidence for each, distilled from the main repo's README research log. Covers the road graph (eeu.rd/.il/.iof/.typ), the road/city name-search catalogs (rt/rl/prl, cty/cl/ct, ctr), the MAP_COMPRESSED tile format (mp0/mg1-mg4) including tile geometry and the topology/adjacency table, the eeuz.fea gazetteer, the FLAT_COMPRESSED container, ISO handling, and a first-look triage of the 16 files never examined at all. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>