site_data.py - IL sim's own tiny RailML reader.
Independently re-parses safeAPIRBC2oo2SA/etc/site/ab_site.railml.xml -
see TrainRBCSim/src/train/site_data.py's own header for the full "why a
FOURTH independent reader, not a shared library call" rationale (matches
the no-pipeline-coupling convention safeAPIRBC2oo2GP's/GA's own RailML
generators already established).
Unlike Train's own reader, this is genuinely NEW ground for IL - today's
il_sim.py hardcodes no route data at all (every ROUTE_ADD's own
start_signal/end_signal/route_len is entirely test/command-supplied, see
that file's own header doc). This module gives IL its own real route
table (id/name/start_signal/end_signal/length_m), the same shape
safeAPIRBC2oo2GA/etc/scripts/generate_ab_site_ga.py's own
ab_site_ga_route_layout_t table already carries and the SAME positional-
id convention it uses (route/signal ids assigned by RailML document
order, not parsed from the element's own @id string) - so a route id
this module reports lines up numerically with what GP/GA's own C code
means by that same id.
| routes |
( |
| railml_path = None | ) |
|
@return a list of {"id", "name", "start_signal", "end_signal",
"length_m"} dicts, one per <route>, ordered and id-numbered exactly
the way generate_ab_site_ga.py's own parse_railml() derives them
(signal/route ids by document-order position, length_m read directly
from each route's own sapi:routeDescription/@lengthM extension - no
segment-length summation needed, that field is already explicit).
Raises on a genuinely missing/malformed RailML file - unlike Train's
balise_names() (a pure log-decoration convenience), a route table
this sim doesn't have at all today is real, load-bearing IL data
(this is what Phase D's own periodic route-status broadcast iterates
over) - a silent empty-table fallback here would make IL announce
"there are zero routes," which is materially wrong, not just
cosmetically incomplete like a missing balise name would be.
Definition at line 37 of file site_data.py.
1.18.0