You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An issue that @jeffkessler-keolis raised that may affect #66 : HASTUS has separate schedule_ids for vehicle schedules and crew schedules, while #66 only has a single service_id, which corresponds to a HASTUS vehicle schedule id. If a producer who uses HASTUS has crew schedules that aren't aligned to vehicle schedules (e.g. vehicle schedules and GTFS use a service_id for "Weekday", while crew schedules have separate schedules_ids and duties for "Monday" and "Tuesday"), then it may be difficult to find a way to translate crew schedules into run_events.txt.
Jeff, can you write up a specific example?
Other producers: If you use HASTUS, do you have crew and vehicle schedules that don't line up with each other? Would this be a problem for you?
This issue won't delay #66. If this is a problem, we'd look for a workaround or an optional/backwards compatible addition on top of #66 for 2.1.
The text was updated successfully, but these errors were encountered:
An issue that @jeffkessler-keolis raised that may affect #66 : HASTUS has separate schedule_ids for vehicle schedules and crew schedules, while #66 only has a single service_id, which corresponds to a HASTUS vehicle schedule id. If a producer who uses HASTUS has crew schedules that aren't aligned to vehicle schedules (e.g. vehicle schedules and GTFS use a service_id for "Weekday", while crew schedules have separate schedules_ids and duties for "Monday" and "Tuesday"), then it may be difficult to find a way to translate crew schedules into
run_events.txt
.Jeff, can you write up a specific example?
Other producers: If you use HASTUS, do you have crew and vehicle schedules that don't line up with each other? Would this be a problem for you?
This issue won't delay #66. If this is a problem, we'd look for a workaround or an optional/backwards compatible addition on top of #66 for 2.1.
The text was updated successfully, but these errors were encountered: