Status: ✅ All 1,535 files on the disc examined and documented. Every distinct file FORMAT is identified; most are cracked (plain text/self-documenting); a handful of proprietary binaries are identified but not byte-level decoded (noted per-subsystem below).

config/create_cd (5,105 bytes, plain text, disc root — not under db/) is the disc's own build/mastering script: the literal, authoritative record of how CD_8555.ISO was assembled, not inferred or reverse-engineered. Shell-like syntax (mkdir/cd/cp/cp -r), dated 22.07.2019 (matching every file's own real mtime on this disc), and self-referential — its own last lines copy itself into config/create_cd.

Every cp line's source is a real internal Navteq/Siemens production file-server path, most under a mapped drive v:\db\PRODUCTION\NT\VW\ EU2019Q1\eu910\eeu\eeu\505.30.910.1.84\....

• The origin of the EEU50530910.84 version string every NOT_COMPRESSED file's own 94-byte header carries (verified directly: eeu.rd's own header bytes spell out exactly EEU50530910.84). The correspondence is strong but not a trivial dot-stripping match: the path's 505.30.910.1.84 has 5 dot-separated components; the header string is EEU + 50530910 + . + 84 — the first 3 path components concatenated, then the LAST component after a literal dot, with the 4th component (1) not represented at all.
• ZIP_3kb is the source tree's own real folder name for every eeuz.* file's compressed variant — block_size=3072 was a deliberately named packaging choice at the source, not just an empirically observed constant. eeuz.fea (FEATURE_COMPRESSED, a different container) is ALSO sourced from a ZIP_3kb folder, consistent with the shared 80-byte-header/zlib-block-packing primitive both formats reuse.
• db/zone.cfg and files.cfg are copied from a SEPARATE path (d:\GDVDImages\CD_8555\..., the disc-mastering staging area) — not from the eeu map-data production tree at all.

cdrom.toc (543 bytes, plain text) is a real, human-readable manifest:

Volume:            CD_8555
Date:              22.7.2019
Version:           505.30.910.1.84
Customer Version:  V17
Customer Info:     VW
TPD:               2019060000
SVD:               EDB_20190607
TMC:               20190610
DBAL:              V006.047 V007.038 V008.704 V009.038 V010.015

Version is an EXACT match to create_cd's own source path — closing that correspondence completely. TPD matches tpd/nscWeu_eue_20190607/ LPOI.TXT and INFO25.PSC's own TPD-PRODID exactly. SVD matches EDB/POI/POI.DB3's own database.id exactly. TMC matches telemat/'s own source path date exactly. DBAL matches dbal/'s own 5 folder names exactly.

DBINFO.TXT is a real per-brand manifest: VW part number 1T0051859AR, system name "EU East V17", and placeholder ("tbd") Seat/Skoda/Bentley part numbers — confirms this disc build serves the whole VW Group brand family, matching POI.DB3's own category split below.

A real, standard SQLite database (open directly, no proprietary container). Confirms this project's own firmware investigation, which had already predicted a .db3 POI file at exactly this path from vdo.nav.api.edb.* strings but never had disc access to open one.

4,733,183 real POIs, most with a full address (house number/street/ city/region/country, each dedup'd through a shared 5,091,214-row string pool — the same pattern eeuz.prl uses). Real, immediately-recognizable content: fuel-brand POIs Q8/ENI/TAMOIL/ESSO/IP (all genuine European petroleum retailers) under a real "gas station" category.

Confirms this POI database is shared across the whole VW Group brand family: real category names include "main seat"/"main skoda"/ "main vw"/"main bentley".

One metadata row's own ClearCase config-spec text names the real internal codebase arriba2/arriba2_VW directly — independently corroborating eeu.mod's own Arriba/5.3 self-identification from the OTHER side (the tool that built this database, not just the firmware that reads it) — and a Java Swing authoring tool under the same vdo/nav/... package namespace already found in the firmware.

PredefinedStatement (35 rows) embeds real, readable SQL text behind a small bytecode prefix — e.g. GetFullPoiData: select b.Poi_ID, b.Coordinate, ... from Poi_BaseAttributes b left join Poi_AddressAttributes a on b.Poi_ID = a.Poi_ID ... where b.Poi_ID = ?1;. This directly confirms, from the database's own side, this project's firmware-only finding that the real client only ever calls a fixed catalog of precompiled, parameterized statements, never arbitrary SQL.

Coordinate — CRACKED (a later session): a 64-bit integer, not this disc's usual /100000-scaled int32 lon/lat pair (splitting it into two int32 halves, tested earlier, produces no plausible degree values) — but the originally-flagged leading candidate, "a Hilbert/Morton space-filling-curve index", turned out to be exactly right:

u = Coordinate & 0xFFFFFFFFFFFFFFFF      # reinterpret signed -> unsigned
x = deinterleave(u, start_bit=0)          # even bits -> raw longitude
y = deinterleave(u, start_bit=1)          # odd bits  -> raw latitude
lon = x / 2**32 * 360.0 - 180.0
lat = y / 2**32 * 360.0 - 180.0           # SAME 360-based scale as lon, not ±90

Found by joining Poi_BaseAttributes → Poi_AddressAttributes → String_BaseAttributes on a real city name ('SOFIA') and noticing every one of that city's own Coordinate values shares an unmistakable high-bit prefix when printed unsigned — exactly a Morton code's spatial-locality signature.

Validated at 2 precision levels: a broad 18-city sweep (Stockholm to Athens, Moscow to Zagreb) lands every city within a fraction of a degree of its real center; 2 individually-known real landmarks found by NAME — Fiumicino (Rome's airport town) and a POI literally named "R7 DOLGOSROCHNAYA PARKOVKA DOMODEDOVO" (Domodedovo/Moscow airport's own long-term parking) — both decode within ~0.01–0.03° (1–3km) of their real published coordinates. Confirmed at bulk scale: 10,000 real POIs (2,000 each from 5 spread-out cities) decoded and checked against each city's own real, padded metro bbox — 9,988/10,000 (99.9%) land inside the correct real bbox. research/poi_db_reader.py's decode_coordinate() implements this — not yet bit-exact to this disc's usual precision standard, but correct in shape, sign, and bulk placement.

POI category icons — CRACKED (a later session): a clean, fully self-documenting chain, real standard PNG images throughout. PoiPartition_BaseAttributes.Icon_ID → Image_BaseAttributes.Image_ID (validated: every partition's own real category name matches its linked image's own real name — "gas station" → an image itself named "gas station") → Image_ImageBlob_Relation (filtered to ImageSet_ID=1, "2D.34.39.PNG.Day" — ImageSet_BaseAttributes names 4 real sets, 2D/3D × plain/shadow) → ImageBlob_BaseAttributes. ImageData, a REAL, STANDARD PNG FILE (confirmed via its own magic bytes, 89 50 4E 47 0D 0A 1A 0A). Every icon is exactly 34×39 pixels — the SAME dimensions as tpd/'s own ICONS/ PNG folder above, consistent with a shared/sibling icon set. Visually confirmed real, recognizable icons by decoding and inspecting several directly: a gas pump, an airplane, a pharmacy cross. research/poi_db_reader.py's load_poi_icons() implements the whole chain.

Real, standard ALERT-C (ISO 14819) TMC traffic location tables for 14 European countries, plus 19 per-language event-text tables. TMCCONFIG.ini is plain, self-documenting text — PROD = "RNS_EU_38", and one line per country giving its real ALERT-C Country Code + Location Table Number, ISO 3166-1 alpha-2 code, and a real bounding box in plain decimal degrees:

AUSTRIA = 0xa, 1, "AT", "aut_A_1_3_4", 9.53485, 46.41923, 17.11080, 48.99898, 0, 272678, , "A"

Germany's own line (5.877°E–15.0087°E, 47.387°N–55.017°N) is immediately verifiable as its real bounding box, no scaling needed.

lan/*.et files confirmed to hold real TMC/ALERT-C phrase-fragment text: lan/english.et's body contains real English fragments ("Approach with care", "Beware of stationary traffic", "Queuing traffic for 1/2/3/4/6/10 km", "Road closed", "Slippery roads", "Traffic flowing freely", real month/day names) — the standard phrase library RDS-TMC receivers use to reconstruct messages. A small header embeds the real source filename (english.csv) directly, confirming these are compiled from plain CSV. The exact string length/packing scheme was not decoded (extracted fragments are often missing their own leading 1-3 characters, consistent with an un-decoded length-prefix byte).

english.et (13,200 bytes) splits cleanly into a 39-byte file header (embeds english.csv + language code en), a 5,764-byte binary region, then a 7,397-byte text blob with ZERO 0x00 bytes anywhere in it (rules out plain NUL-terminated strings) — the first real readable text is "proach with care", i.e. "Approach with care" missing its own leading "Ap".

Hypothesis 1, a plain (offset, length) uint16 index table — REFUTED: reinterpreted as 2,882 little-endian uint16s, only 36% fall inside the blob's own valid byte range (0–7397), with no visible sequential pattern among the ones that do.

Hypothesis 2, a plain IEEE-754 float32 array (motivated by the region's own real, highly skewed byte distribution — 0x40 in 22% of all header bytes, 0x00 in 21%, both classic float32-exponent values, vs. the near-flat distribution a real offset table would show) — also REFUTED: only 36% of the 1,441 reinterpreted float32s land in a plausible small-magnitude range: most decode to nonsensical ~1e35 or ~1e-38 exponents.

The "missing leading characters" effect is real and precisely reproducible, confirmed via exact hex-offset inspection, not a scan artifact: "...care" is followed by exactly one byte (0x14), then literally p,r,i,l — no A anywhere — yet 6 bytes later 0x06 precedes the COMPLETE word August, A included. The same letter is encoded two completely different ways a few bytes apart, and the file's very FIRST real string (Approach) already has its own leading "Ap" replaced the same way — ruling out a simple "back- reference to an earlier occurrence in this same blob" explanation, since there is no earlier occurrence for the first entry. Real evidence of some per-entry prefix/dictionary substitution scheme — plausibly a static shared-prefix dictionary common across all 19 .et files, or bit-level Huffman coding of just the leading 1-3 characters — but which one, and its exact code table, was NOT identified. Documented here as a genuine, not-yet-workaroundable wall (2 concrete simple hypotheses tried and cleanly refuted with real evidence), not an abandoned lead.

A later session, from the FIRMWARE side (the same separate factory firmware disc — see the main README §2.6, out of scope for this map- disc wiki): its embedded debug strings reveal a real, complete LanguageTable/TokenTable/NodeTokenEntity subsystem — SortTokenTable, FindLongestInTokenTable, AddTokenEntity, and a real decode() deserializer — architecturally exactly the kind of longest-match dictionary tokenizer that would produce this "missing leading characters" pattern. Caveat: its real source path is naviservice/voicegeneral/SentenceAssembler.cpp, the turn-by-turn VOICE-GUIDANCE sentence assembler — a different (though it does have its own AddTmc/GetTmc/SetTmc methods, so TMC content flows through it when spoken aloud) resource from .et's own raw phrase table. Upgrades this wall from "unknown scheme" to "very likely a dictionary/token-table scheme, real precedent exists in this exact code area" — without closing it.

.lt files (real per-country binary ALERT-C location tables) were identified by naming convention and structurally examined (no clean small fixed-record width found, consistent with the real format's own variable-length record shapes) but not byte-level cracked.

A strong new lead for eeu.tmc (still unopened): scanning its first ~20KB for short ASCII-digit runs finds a real sequence of small, mostly-ascending integers (117, 118, 225, 259, ..., up to 951) — consistent with real ALERT-C Location Code (LCD) point numbers, and dbal/'s own embedded source list below names BOTH db_tmc.cpp AND db_tmc_deprecated.cpp — CORRECTED, a later session's 5-version diff: both files coexist in ALL 5 DBAL versions, refuting the earlier guess that the on-disc TMC format changed between DBAL releases (see the dbal/ section below). Not cross-checked further.

SpeechRes.xml is a real, readable XML resource manifest covering 8 per-locale voice packs (parts/uvo_*.zip) and confirms real SPEECH RECOGNITION support (per-user SpeakerProfiles/*.cfg/*.voc file masks), not just TTS output.

The ZIPs confirm the real TTS engine vendor is SVOX (a real commercial speech-synthesis company later acquired by Nuance/Cerence) — svox.bin's own header is plain ASCII: OS VxWorks PLANG 1 ... FILETYPE BIN MAJVERS 3 — the first confirmation in this project of the actual embedded real-time OS (VxWorks), previously only known as an unidentified PowerPC native-code region.

SVOXKEYS.txt is a real, dated license-key string: P 10 6 2005 AS 3.0 Siemens_VDO CP2 9 DABFSNIPC... — confirms Siemens VDO licensed SVOX's engine on 10 June 2005, tying this subsystem to the same corporate lineage already established from the firmware's vdo.nav.* namespace and eeu.mod/POI.DB3's own Arriba/arriba2 codebase identity.

vsi.img's own header is also plain text: real per-locale voice IDs (enGBFemale) and named sound events (beep, navi_specific, tone_error, tone_sds_error) alongside an mp4-tagged audio reference.

The actual voice-model/phoneme-inventory binary payloads (kj0ca0b16_0.pil, svox.bin, vsi.img) are real, proprietary SVOX formats — not reverse-engineered.

All 5 DBAL.OUT files ("Database Abstraction Layer", one per supported head-unit software generation) are confirmed 32-bit big-endian PowerPC ELF relocatable object files (ET_REL, EM_PPC) — ties directly to the firmware's own already-known PowerPC native-code region.

A plain printable-ASCII-run scan (no ELF tooling needed) finds ~330 distinct real internal source paths under J:\siemens\source\libraries\ dbal\.../J:\siemens\source\navicore\..., matching this project's own already-cracked db/ files by name almost one-to-one:

A runtime log string independently confirms an already-established empirical finding, from the source's own words: "db_page:: update_pnext: element is already in the hash" confirms eeuz.fea's directory really is a hash table, not a spatial/sequential index.

A real, dated ClearCase build history names dozens of individual bug-fix branches, several directly relevant to open problems on this wiki: alle_DbNavRbg3057_vw_split_mp0, alle_dbal_DbNavRbg3119_ house_number_opt, alle_DbNavRbg2825_intersection_roundabout, alle_tmc_exit_fix, and lupa_dbal_DbNavRbg3501_RNS510_ wrong_phoneme_Dummy_V10 (literally naming "RNS510").

Per-version printable-string counts grow monotonically (4208 → 4405 → 4600 → 4780 → 4802 for V006_047 → V010_015), and distinct .cpp/.h basename counts likewise (109 → 112 → 124 → 128 → 128) — confirming these are 5 real successive builds, not 5 unrelated ones. A "first-appears-in-version" diff over every real source basename:

The "generic corridor" subsystem — REMOVED at exactly the V007→V008 boundary, the same release that added the aspect/event framework above. A full V010_015-vs-V006_047 file diff found 65 additions and 11 REMOVALS; all 11 belong to one real subsystem under real source path K:\siemens\...\genericcorridor\{corridorhelpers,corridormain, corridorstorages}\... (note the K: drive — every other path in this file uses J:, a different build-machine mapping for this one, older subtree): corridorbackend.h, corridorcatalogstorage.h, corridorcitylistrecord.h, corridorcityrecord.h, corridorconfig.h, corridorfrontend.h, corridorhelpers.h, corridorlitree.h, corridormp0storage.h, corridorobjectpool.h, corrstatus.h — present in BOTH V006_047 and V007_038, gone from V008_704 onward. A 12th related file, corridorroadstorage.h, was actually ADDED in V007_038, one version before the whole subsystem was cut. Two real runtime strings confirm it was a genuine working feature: "Unsupported request in corridor mode (dir=%d, catID=%d, count=%d)!" and "MP0Storage: constructor:oslib_MutexCreate failed" — and corridormp0storage.h directly references eeuz.mp0, suggesting "corridor mode" was a route-corridor predictive tile-prefetch cache, later removed and presumably replaced by V008_704's mapjobqueue.h/maploader.h job-queue abstraction.

The V008_704 phoneme classes are a real, dated EU/North-America architectural split, confirmed via mangled C++ symbols naming an actual dbal::phonemes:: namespace (Q34dbal8phonemes17CPhonemeEUHandler = dbal::phonemes:: CPhonemeEUHandler). This disc's own family, CPhonemeEUHandler, reads eeuz.pca/.pct/.prd/eeu.pcl directly, while CPhonemeNAFileReaderHandler/CPhonemeNAFlashHandler/ CPhonemeNAFlashFile use a completely different "flash file" (loadPhonemeFileFlashMemory) code path for the (never-seen-here) North American disc family — strong evidence the phoneme data format itself, not just the handler class, differs between EU and NA discs.

The user provided a separate factory firmware disc (out of scope for this map-disc-focused wiki — see the main README §2.6 for the full picture). Its application image embeds the dbaLib runtime's own real log strings, directly confirming the dynamic-loading mechanism the 5-version diff above already implies: "dbaLib: best matching dbal.out version on DVD: V%03d_%03d", "now unload DBAL version: V%03d_%03d", etc — the firmware detects which DBAL version the inserted disc requires, searches dbal/ for a matching (or best-compatible) V0NN_0MM/DBAL.OUT, and dynamically loads/unloads it as discs are swapped. A catalog of 77 real, versioned db_*_V0NN accessor function names was also found there, independently confirming several field names this wiki could previously only cite from eeu.mod's own authoring-tool schema — see eeu.mod and eeu.tmc for the specific accessor names.

nscWeu_eue_20190607/INFO25.PSC is a real, self-documenting config file (TPD-PRODID 2019060000, TPD-CNTRY listing the same 33 countries already found via eeu.cal/eeu.ctr, LPOIPRO Y).

Confirmed to be a real embedded HTML "browser" destination-search UI: each of 8 per-language folders holds an IDENTICAL 122-file set (verified by hash) of real HTML forms submitting to http://tpdhost/cgi/search/StartTPD — the head unit runs (or emulates) a local embedded web server with a CGI-style handler. SF_<FORMID>.HTM (search-criteria forms, e.g. SF_11000.HTM = "Airports", radius + name filters) and ST_<FORMID>.HTM (results pages, with <%if_result>/<%INDEX_FIRST>-style template substitution) reference real per-form search index tables under TABLES/0/<NNNN>.IDX + .URL, whose own header is plain, self-documenting text:

block-offset=428?compr-max-size=1860?compr-type=Z?order-type=lambda?table-type=G?uncompr-max-size=3012
ID:A:6|POS:P:8|NAME:V:84|LKI:B:1|PHONE:V:19|IMPORTANCE:B

— a real named+typed schema (the same ID+position+name+phone shape as POI.DB3's own Poi_BaseAttributes) for a zlib-compressed (compr-type=Z) table.

A later session cracked the structure right after that header, previously assumed to just be part of "the compressed body": a real per-block (offset, lambda_hash) index table — repeating 9-byte records ([4-byte BE uint32][4-byte BE uint32]['|' delimiter]), BOTH fields strictly monotonically increasing across every record. Confirmed on both a small per-form .IDX (30 records) and the much larger merged TABLES/GENERIC.IDX (136.9MB, 92,006 records — same shape at a larger scale, not a coincidence specific to the small file). This matches order-type=lambda exactly: a sorted hash-boundary table letting a real client binary-search for which single compressed block a query's own lambda hash falls into, instead of decompressing every block in order.

Tested and REFUTED: the compressed block BODIES themselves are NOT standard zlib (RFC1950), raw DEFLATE (RFC1951), gzip, or bz2 — exhaustively scanned at every byte position in a small, fully-scanned .IDX file, zero real hits in any of these formats despite the file's own compr-type=Z label. A real but still unidentified proprietary encoding — left open for a future session (LZO, a custom Siemens/ Continental scheme, and non-byte-aligned/bit-packed encodings are the untried candidates).

A later session, prompted by a direct re-check of this whole folder's contents, found a 2nd real embedded CGI host and the actual "navigate here" action. ST_DETAIL.HTM (1 per language, real content identical except the LAN tag/translated text) is the single POI-detail screen shown after picking a search result — real fields STR/NR (street/number), VIL/CTY/CTRY (village/city/country), TEL (phone), POI (name) — and it's the ONLY file anywhere in tpd/ referencing ctrlhost, distinct from the already-documented tpdhost (which only ever handles the DATA endpoints cgi/search/cgi/form/ cgi/StartTPD). ctrlhost handles 3 real CONTROL/ACTION endpoints instead:

• cgi/menu?option=tpd_prev_page — the "back" button
• cgi/phone?NR=<%TEL!CGI> — click-to-call
• cgi/setdest?NAME=<%POI!CGI>&PHONE=<%TEL!CGI>&LOC=<%LOC!CGI>&ENTRY= <%EP1!CGI>&ENTRY=<%EP2!CGI>&...&ENTRY=<%EP9!CGI> — the real "set this POI as my navigation destination" action, with up to 9 real ENTRY parameters (plausibly one per usable building entrance) — the concrete mechanism the firmware investigation (§2.5) had only inferred existed, now with its real endpoint and parameter shape.

Also corrected 2 stale file-count claims found while verifying this: exactly 59 real numbered SF_<FORMID>.HTM search forms per language (not 60), byte-exact matching 59 numbered TABLES/0/<NNNN>.IDX files (also not 60 — that count was actually this directory's ST_*.HTM total: 59 numbered + ST_DETAIL.HTM).

<LAN>.LSC files are plain, self-documenting text naming a real category-group hierarchy (TPD-GRP <group-id> <child ids>) feeding the category picker; ICONS/ICONS810 (381 real PNG files, self-explanatory POI-category names like AIRPORT/ALL_RESTAURANTS/ ATM_EUR) and IMAGES (22 GIF UI-chrome files) round out the system.

A later session opened the one file under tpd/ that had never actually been read: TPD3.DIC. Despite the .DIC extension, it's NOT a binary word/phrase dictionary — just 60 bytes of plain text, a 3rd disc-root-level product manifest, one directory above INFO25.PSC/LPOI.TXT:

TPD-DBID	2019060000
TPD-UPI	eue_0	25	/nscWeu_eue_20190607 D

TPD-DBID matches the same 2019060000 build stamp already confirmed 3 ways above — now a 4th independent confirmation. TPD-UPI ("Update Package Info", by the obvious reading, not independently confirmed) names the one real product instance shipped on this disc: eue_0 (a product code), the real /nscWeu_eue_20190607 path (byte-exact), and a trailing D flag (plausibly "Directory"/"Data", not confirmed). The middle field, 25, was tested against every other count already known for this disc and matches none of them — not TPD-CNTRY's 33 countries, not TPD-LAN's 8 languages, not any individual language code (1 2 3 4 5 6 15 20) — real, unexplained.

research/create_cd_reader.py, research/poi_db_reader.py, research/telemat_reader.py, research/speech_reader.py, research/dbal_reader.py, research/tpd_reader.py — all documentation- only modules (every format here is either plain text/self-documenting, a standard container like SQLite/ZIP/ELF/PNG/GIF, or a proprietary binary explicitly flagged as not decoded).