Refactoring the structure of the input files to achieve the following:
The same route entity representing a specific physical sequence of components can be re-used to avoid unnecessary duplication
Each train entity can traverse through the same passenger-facing route multiple times over its lifetime, to mimic the concept of a service block
Summary of proposed changes:
Each route entity in the routes.json file would now purely contain the physical sequence of components, without any schedule information
Introduction of the new "tour" entity, which would specify multiple routes in the order to be traversed, along with schedule information in args corresponding to each component of each route; stored in a file called tours.json
Each train entity in trains.json would be assigned to one tour
Within a tour, the last component of each previous route must match the first component of the next route, so the train would seamlessly transition from one route to the next
In the Line 4 example, the routes would become distilled down to just the eastbound and westbound component sequences, and there would only be a few trains, since it is the same few trains operating round-trips along the line repeatedly throughout the day.
Refactoring the structure of the input files to achieve the following:
Summary of proposed changes:
In the Line 4 example, the routes would become distilled down to just the eastbound and westbound component sequences, and there would only be a few trains, since it is the same few trains operating round-trips along the line repeatedly throughout the day.