eeu.si — Segment Classification Table

Status: ✅ Cracked · 195 KB · NOT_COMPRESSED · Record framing cracked and validated at full file scale; all 20 real leaf fields positioned in exact eeu.mod schema order across the record's 5 real bytes. 2 of the 20 fields (rank/class/divided and route_num_type/ paved) plus 3 more (driveable_lower/drivable_upper, tollbooth_direction, restclass) have a joint-exclusivity or fully- saturated-range validation signal; the final 11 single-bit flags rest on position + schema-order match alone (2 of those 11 have an extra corroborating joint-distribution signal — see below).

A real road-segment classification/attribute table — road rank, class, whether it's divided, tolled, paved, and more. Not previously examined — only its candidate 8-byte record size (from the shared header's record_count_lo16 field) and its schema field list (via eeu.mod) were known going in.

Record format — cracked, validated at full scale (24,353 records)

94-byte header (record count 24,353 read straight from the header), then exactly 24,353 fixed 8-byte records: 24,353 × 8 = 194,824 bytes, an exact match to the real body size, zero leftover.

bytes[0:5]  real per-record data, see below
bytes[5:8]  always zero on every record checked (24,353/24,353)

Only 20,381 of 24,353 records have a distinct 5-byte payload — 3,972 records duplicate another record's exact value. Not a clean dedup table (that would require zero duplicates); more likely allocated per some other axis (e.g. per-region/country) where the same attribute combination legitimately recurs.

eeu.mod's real field list

eeu.mod names this table seginfo, with 20 real leaf fields once the 11 shared header-struct boilerplate strings are excluded (see Database Schema): rank, class, divided, [drivables: driveable_lower, drivable_upper], toll_vignette, toll_road, tollbooth_direction, hwy_complex_bit, restclass, landmark, dbldig, detailedcity, urban, bifurcation_left, bifurcation_right, rnc, truck_digitized, route_num_type, paved.

drivables is (by analogy with eeu.pmm's own type_and_listIndex wrapper, see Postal-Code Merge Tables) almost certainly a struct/group name wrapping its two children (driveable_lower/drivable_upper), not itself a 21st real field — consistent with the inconsistent spelling ("driveable" vs "drivable"), a real quirk of the original compiler's packing (a single logical value split low/high across non-adjacent bits), not a project typo.

Cracked: byte 0 = rank / class / divided, in exact schema order

bits[0:3]  rank      -- values 0-4 ONLY (5,6,7 never observed)
bits[3:7]  class     -- values 0-12 (13,14,15 never observed)
bit[7]     divided   -- boolean, 16.30% of records (3,970/24,353)

Cracked: byte 4's low nibble = route_num_type / paved, the exact last 2 fields, in the last real byte

bits[32:35]  route_num_type  -- values 0-6 ONLY (7 never observed)
bit[35]      paved           -- boolean, 94.56% of records (23,029/24,353)

Both crackings are validated by:

• exact bit-width match — the sub-fields sum to a whole byte with no slack bits
• exact schema-order match — rank/class/divided are the first 3 real leaf fields; route_num_type/paved are the exact last 2
• small/clean bounded value ranges — none of the 5 sub-fields fills its full bit-width range, consistent with real bounded enums rather than noise
• real-world plausibility — divided's ~16% and paved's ~95% are both realistic rates for a European road network

Not independently confirmed against ground truth — no populated cross-reference was available this session (see below).

Bytes 1-3 (24 bits), all 15 remaining named fields, in exact schema order throughout

driveable_lower, drivable_upper, toll_vignette, toll_road, tollbooth_direction, hwy_complex_bit, restclass, landmark, dbldig, detailedcity, urban, bifurcation_left, bifurcation_right, rnc, truck_digitized — 15 real fields, 24 real bits, of which bits[8:11] (byte 2's low 3 bits) and bit[23] (byte 3's top bit) are always zero — 20 real bits of storage for 15 fields.

Cracked: driveable_lower/drivable_upper = byte 1, bits[0:2]

Joint distribution across all 24,353 records: (1,1)=9,258, (0,1)= 7,548, (1,0)=7,547, (0,0)=0 — these two bits are NEVER both clear. Exactly matches real-world expectation for a "drivable in the lower-numbered direction" / "drivable in the upper-numbered direction" pair: a real road segment must be traversable in at least one direction (a segment nobody can drive is not a real road), while bidirectional (1,1) and the two single-direction cases are all real, distinct possibilities. The near-identical (0,1)/(1,0) counts are consistent with "lower"/"upper" being an arbitrary node-order label rather than a real-world-meaningful compass direction.

Cracked (identity): tollbooth_direction = byte 1, bits[4:6]

Joint distribution: (0,0)=23,729 (97.4%), (1,0)=314, (0,1)=310, (1,1)=0 — mutually exclusive, both rare (~1.3% each). Matches a real "which direction requires toll payment" state: not a toll booth; tolled one way; tolled the other way — never both.

Cracked (position, plausible identity): restclass = byte 2, bits[3:7]

The 4 bits directly following byte 2's confirmed-always-zero bits[0:3]. All 16 of 16 possible 4-bit values are used across the file — a fully-saturated range, the cleanest possible signal for a genuine, tightly-packed enum field with no wasted bit (stronger than the 5-bit interpretation tried first, which only used 30/32 values — bit 7 doesn't belong to this field).

Cracked (position, later pass): the remaining 11 single-bit flags, assigned by exact schema order

The same technique already validated for byte 0 and byte 4: eeu.mod lists exactly 11 more single-bit leaf fields after restclass, and exactly 11 real bits remain unassigned, in the same relative order:

byte 1  bit[2]   toll_vignette      -- 11.62% (2,831/24,353)
byte 1  bit[3]   toll_road          -- 14.72% (3,584/24,353)
byte 1  bit[6]   hwy_complex_bit    --  2.66%   (647/24,353)
byte 2  bit[7]   landmark           -- 10.84% (2,639/24,353)
byte 3  bit[0]   dbldig             -- 24.19% (5,891/24,353)
byte 3  bit[1]   detailedcity       -- 26.69% (6,499/24,353)
byte 3  bit[2]   urban              -- 56.84% (13,842/24,353)
byte 3  bit[3]   bifurcation_left   -- 46.69% (11,371/24,353)
byte 3  bit[4]   bifurcation_right  --  3.75%   (914/24,353)
byte 3  bit[5]   rnc                --  3.95%   (961/24,353)
byte 3  bit[6]   truck_digitized    --  4.98% (1,212/24,353)

toll_vignette/toll_road are schema-adjacent and land in the only 2 bits available in byte 1's gap between drivable_upper and tollbooth_direction; hwy_complex_bit is the schema's next field after tollbooth_direction and lands on byte 1's only remaining real bit; landmark is the schema's next field after restclass and lands on byte 2's only remaining real bit; the final 7 fields (dbldig through truck_digitized) match byte 3's 7 real bits (bit[7] confirmed always zero) 1:1 in schema order with zero slack.

Two independent signals beyond position:

• rnc/truck_digitized are NEVER both set: joint distribution (0,0)=22,180, (0,1)=1,212, (1,0)=961, (1,1)=0 — the same clean joint-exclusivity signature already used for tollbooth_direction and driveable_lower/drivable_upper.
• toll_vignette/toll_road are almost always mutually exclusive: (0,0)=17,975, (0,1)=3,547, (1,0)=2,794, (1,1)=37 (0.15% of records) — weaker than a hard rule, but consistent with 2 closely-related "toll payment method" flags that are usually, not always, exclusive (a road could plausibly require both a vignette AND direct tolling in rare cases).

The other 9 fields' individual semantics are not independently cross-validated — confidence rests on position + exact schema-order match + plausible value-rate ranges only, the same standard already accepted for rank/class/divided/route_num_type/paved.

Tested and refuted: dbldig ("double digitized" — the real Navteq term for a divided highway modeled as 2 separate carriageway geometries) was hypothesized to tightly track divided (byte 0 bit 7). Joint distribution (divided, dbldig): (0,0)=15,301, (1,0)=3,161, (0,1)=5,082, (1,1)=809 shows no such coupling — dbldig is a real, distinct field, not a redundant re-encoding of divided.

Corrects a previous session's lead: eeu.rd's bytes[1:5] is NOT a direct index into this file

eeu.mod's write-up flagged eeu.si as "a strong, not-yet-pursued lead" for eeu.rd's own unresolved bytes[1:5] ("candidate road-class flags"). Originally checked against a since- corrected "~5 distinct patterns" claim for that field — a full-file scan actually finds 6,174 distinct values — but even with the correct cardinality, decoding eeu.rd's bytes[1] directly using this page's own exact rank/class/divided bit layout produces values filling the FULL 0-7/0-15 range rather than eeu.si's own bounded 0-4/0-12 ranges (and a 46.5% divided-equivalent rate vs. eeu.si's own 16.3%) — eeu.rd does not directly embed eeu.si-style flags using that encoding. Also tested (see Parallel Road Array): eeu.rd's bytes[1:5] shows no correlation with eeu.iof's own count field either (r ≈ -0.02).

This specific cross-reference does not hold up. More likely: the real seginfoID foreign key lives on the MAP_COMPRESSED tile format's own segment records — eeu.mod's "Ordinary Map File" block independently names a seginfoID field there, alongside seg/restr_left/restr_right/left_node/right_node/ length — not on eeu.rd at all. eeu.rd and the MAP_COMPRESSED tile format are two separate representations of the road network. Not pursued further this session (would require reopening the tile format's own segment record parser).

Reader code

research/si_reader.py — read_si().