[Design/Requirements - Business oriented documentation] Asymmetric times #421
Description
Preflight Checklist
- I have read the Contributing Guidelines for this project.
- I agree to follow the Code of Conduct that this project adheres to.
- I have searched the issue tracker for an issue that matches the one I want to file, without success.
Request type
Request for a new component
Business contact: Martin Sojka
Functionality
Netzgrafik-Editor - Conceptual considerations on the asymmetrical timetable
First paper prototypes for asymmetric clock-face schedule and one directional trains
The next three images show the initial conceptual thoughts from the first workshop on the asymmetric clock-face schedule. They should provide an initial hint of what we believe should be analyzed and where we expect conceptual issues or changes.
| Initial concept | ||
|---|---|---|
 |
 |
 |
Asymmetric times
General requirement
The system must support asymmetrical arrival and departure time pairs. This also enforces the support of asymmetrical travel times in between, ensuring that the departure time + travel time in the forward direction equals the forward arrival time; the same formula must be satisfied in the backward direction of each train run section.
This requires a separate field for the forward and backward travel times. The Netzgrafik-Editor must therefore be extended so that these different travel times (forward: source -> target / backward: target -> source) can be saved. The Netzgrafik-Editor must be overwork. It must ensure that the correct travel time is used for all calculations based on the correct travel-direction-oriented travel times.
If the travel time is identical, the travel time is saved twice in both fields each time the same time (value). During data migration, the travel time is copied so that the correct time is in both fields. We suggest adding a new field: travelTimeBackward. Thus the migration simply copies the travelTime time into the travelTimeBackward field for the trainrunSection. The travelTimeBackward is per default equal to the travelTime. This must be ensure during creating of new trainrunSection element.
The Netzgrafik-Editor must mark asymmetrical arrival/departure time pairs. This shall be solved using a flag per arrival/departure time pair at source and target nodes. This requires an extension of the trainrunSection element. The flags indicate whether the corresponding time pair is symmetrical or asymmetrical. The flags sourceAsymmetric and targetAsymmetric are set to false by default, this must be resolved in the data migration or whenever a new trainrunSection gets created. If the flag is set to true, the arrival and departure time pair can be asymmetric. User should be able to simply switch a button for the time pair for which he asks for asymmetry. The Netzgrafik-Editor must allow for each arrival/departure time pair this asymmetry.
The user must be able to edit “asymmetric or symmetric” time behavior at any place in the editor – where he currently can edit times.
Switch to asymmetric arrival and departure time pair
The user can allow asymmetry for any section or a node. The user interface must support this feature in a very simple way.
To do this, we add a toggle button that enables the asymmetry. Then the user can enter the asymmetry specifically for the node’s arrival / departure time pair. When the user switch “on” the asymmetry – the Netzgrafik-Editor must enable directional travel times. Thus to achieve asymmetry, an adjustment of the travel time is required. In cases where only one time pair (target or source arrival/departure time pair) on a trainrunSection element is asymmetric the travel time can no longer be identical in both directions. In consequence, we need a directed travel time.
Mockup: Trainrun/TrainrunSection Edit Dialog
 |
 |
| Asymmetric time enabled at Aarau and Lenzburg. Both travel times are equal but can be changed separately for both directions. | Asymmetric time enabled only at Lenzburg. Both travel times are no longer be equal. |
Mockup: Pearls View TrainrunSection Time Editor
 |
 |
 |
 |
| By default the asymmetric button is switched off on and only shown when time editing is enabled. There is no button shown in the header if the trainrun has no asymmetric times. | The button (switch off for the entire trainrun will be placed in the header – top-right) When the user like to modify a time the switch buttons get shown on the left side of the two departure / arrival times. When the system has asymmetric times enabled it allows entering the two-travel direction dependent times | The asymmetry times should be also shown for the connection times (as the example here at the right side). This times are oriented, e.g. - Connection time from OL towards LZ is 17 - Connection time from LZ towards OL is 16 | The UX-Design for the solution, if the amount of stops at the edge is higher than five and there are more than one travel time to display (example on the right between ZF und ZG) must be updated/re-defined - then the current implementation variant doesn't have the required space. |
Mockup: Netzgrafik-Editor visualization of directed travel times
If the travel times are equal in both directions, the Netzgrafik-Editor should visualize the travel time on the sections only once. If the travel times are not equal in both directions, the travel times must be shown on the Netzgrafik. In the edit dialog if one asymmetric switch is “on” both travel times will be displayed. This must also be the case in the pearls view.
Train travels from Olten to Baden and has from Aarau to Baden asymmetric times. From Olten to Aarau the symmetry is given. Open Questions (UX): As the travel time between Lenzburg and Brugg and Brugg – Baden is equal in both directions – but the departure/arrival times are asymmetric – we propose not rendering the travel time twice for each direction due to the equal times in both directions. Thus, only the different travel times between Aarau and Lenzburg need to be rendered (visualized). The question is where to place the two travel times. The lower one will be in the name area of the next (below train run). There is no space left. TODO – find a integration into existing design!
 |
| Detail: Section Aarau – Lenzburg has two different travel times defined. Both travel times have to be shown. |
Switch back to symmetric arrival and departure time pair
The user must be able to disable asymmetric times. Disabling requires updating departure/arrival time pairs and as well travel times.
If, after the user finishes editing, a symmetric solution is provided, the system should automatically switch the asymmetrical button allowance to the default position (symmetrical solution) at all the affected nodes and edges.
Partial switch back to symmetric departure/arrival time pair
When switching the asymmetric button from “on” to “off” (default) and the times are asymmetric, the application has to ask the user which direction is the “master”.
Just in the case when asymmetrical times are given and the user switch the asymmetric button then the application opens an extra dialog window and asks the user which time the master is for the symmetric solution. In the example below, we have two options to enforce the asymmetric time to become symmetric again: 13/47 or 16/44. Thus, the user must select one option. Then the application changes the times of the departure and arrival at node “Lenzburg” (where the switch button is aligned to) and the travel time gets updated. This dialog window must as also be opened when switching the buttons in the pearls view.
Entire trainrun
General requirements
If the user like to disable the asymmetric times for an entire train he should be able to deactivate the asymmetric times for the entire train at once.
The second case when an asymmetry time exists in the entire train. A switch button gets shown that the entire trainrun has a least one asymmetric time.
Mockup: Trainrun/TrainrunSection Edit Dialog
The user can disable the asymmetric times for the entire trainrun. Once he is disabling the asymmetric for the entire trainrun, the user must decide which direction is the master. The user can just select the “forward” Olten – Baden or the “backward” Baden – Olten as the master. Then all times get mirrored in the master’s opposite direction (updated, overwritten). When a time at an intermediate node is still symmetric the application doesn’t need to change for this node the times.
When no asymmetric times are enabled the button is not visible on the trainrun header. The same functionality must be added to the pearls view.
Mockup: Pearls View
Track occupier
Track occupier / Infrastructure estimator
The graphical timetable should mostly work without any changes:
• Track occupier (user manual)
o Turnarounds at start / destination
o Intermediate passing
• Minimum number of tracks on sections (user manual)
The example below shows a asymmetric trainrun. The travel times are in both directions the same, but the arrival and departure times are asymmetric:
Track occupier: Intermediate passing
The track occupancy at intermediate stops or during passing seems to be correct. It looks like no changes need to be made.
Track occupier: Turnarounds at start / destination (Known issue)
The turnarounds at the start and destination are not correct. The train will be mapped to the next symmetric time, e.g., the train arrives at 07:55 in Olten and departs at 08:02, but the turnaround is calculated based on the next symmetric time, which will be at 08:05, which is not true for asymmetric clock-face schedules. The correct time must be taken into account instead. The minimum turn-around times must be respected as well.
 |
 |
Infrastructure Estimator: Minimum number of tracks on sections
The minimal number of tracks on sections looks good. There must no changes be done.
Symbol : Asymetric
When a time is asymetric - there must be a extra symbol added - the time will no be colored with "warning" once the business logic gets changed (enabled assymmetric -> time is correct). Thus we will add the asymmetric symbol.
The same symbol must be added to the pearls view
We studied the symbol asymmetric and suggest to start with Variant 2
