site_data.py - Train sim's own tiny RailML reader.
Independently re-parses safeAPIRBC2oo2SA/etc/site/ab_site.railml.xml -
the same single source of truth safeAPIRBC2oo2GP/etc/scripts/
generate_ab_site_gp.py and safeAPIRBC2oo2GA/etc/scripts/generate_ab_site_ga.py
already generate GP's/GA's own C site-data tables from, and
safeAPIRBC2oo2TestEnv/src/web_runner/site_data.py already reads for the
live schematic - deliberately a FOURTH independent reader, not a call
into any of those three, matching the "each generator re-parses the file
itself, no pipeline coupling" convention those two C-side generators'
own header comments already establish (see either one's own doc for the
full rationale: no build-order coupling, and a real cross-check
opportunity instead of one silently trusting another's derived output).
Train only ever needs ONE thing from the file: the `nid_lrbg -> name`
mapping this sim uses purely for its own log-line decoration (see
train_sim.py's own get_balise_name()) - replaces what used to be a
hardcoded BALISE_NAMES dict that was, by actual comparison, a byte-for-
byte duplicate of this file's own <baliseGroup> data.
| balise_names |
( |
| railml_path = None | ) |
|
@return {nid_lrbg: name} parsed fresh from the RailML file (no
caching - this sim's own catalog/config loading is likewise done
once at import/startup time, matching that same "read once, live
for the process's lifetime" posture). Falls back to a hardcoded copy
of today's known-good data (see _FALLBACK_BALISE_NAMES's own doc) and
logs a warning if the file can't be found/parsed, rather than raising
- a missing balise-name mapping is a log-decoration cosmetic, never
worth failing sim startup over.
Definition at line 52 of file site_data.py.
1.18.0