tahini
commented
6 days 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)
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.