mirror of
https://github.com/mauriceboe/TREK.git
synced 2026-10-18 21:16:47 +00:00
Maurice
56266138c6
A plugin may already route a day in road trip mode, and the charging stops it answered with were thrown away: the map was handed an empty list and the rail never looked. That made "build it as a plugin" — the answer given to charging prices, to ABRP and to the AFIR data — untrue in the one mode where it matters. Each halt is measured along the run once and filed on the leg it is actually driven on, using the leg lengths the router reported rather than by projecting the stops too: leg distances are exact by construction, while two stops close together project onto each other's stretch and would put a charge the wrong side of a town. The rail row is deliberately the poorest of the four. No number, no editable stay, no arrival time, a hollow disc: the halt belongs to the provider, not to the traveller, and everything filled on that rail is something they put there. Nor is it ever written back — a plugin halt stored as a via would go out as a waypoint on the next run, and the plugin would plan around its own charging stop. No time on the row for a second reason: the SDK contract folds the stop into the leg duration, so the arrivals already account for it. Adding dwellSeconds to the schedule would push every arrival after a charge back by the charging time.