Open tahini opened 9 months ago
In the meantime, having old schedules on updated paths, if the number of nodes is different will prevent trRouting from running for ever and ever.
The following SQL queries in the DB can help find out which lines/paths are problematic:
select a.acronym, shortname, p.updated_at, t.updated_at, cardinality(nodes), cardinality(node_arrival_time_seconds), cardinality(node_departure_time_seconds)
from demo_transition.tr_transit_lines l
inner join demo_transition.tr_transit_agencies a on a.id = l.agency_id
inner join demo_transition.tr_transit_paths p on p.line_id = l.id
inner join demo_transition.tr_transit_schedule_trips t on t.path_id = p.id
where cardinality(nodes) != cardinality(node_arrival_time_seconds)
Ran into this problem again today. For example, when deleting nodes in a path and the schedule cannot be updated, trRouting will simply silently fail to start with a message like "Index out of range while parsing connection for trip on line (Ligne 5 - Bleue (Copie))" in the logs and all route calculations will return no service available. It is very unintuitive.
For exact schedules imported from GTFS, there is no oubound/inbound, frequencies or number of units. It is thus not possible to re-generate schedules for those paths, when the path is updated for example. Just taking the current trips and updating the stop times is not a good idea, as the user cannot know which trips were using the updated paths, so cannot really understand the result.
Instead, we should just warn the user that trips using this path for service X cannot be updated and they should manually change it.