[Feature request]: Asymmetric Times in Timetable Concepts

[VXstone]

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

Functionality

Problem Statement:
Currently, the Netzgrafik-Editor (NGE) does not support asymmetric times in timetable concepts. This limits the flexibility in editing and adjusting timetables. It also makes it very difficult to access existing productive timetable data or to import them. Therefore, the Netzgrafik-Editor should allow asymmetric times.

Proposed Solution:
Implement a function that allows asymmetric times in timetable concepts. This function should be disabled by default but can be activated by the user. This should be saved within the variant, ensuring that a variant has a clearly defined state, i.e., whether asymmetry is allowed or not.

Functionality:

• Activation of Asymmetric Times:
  • The editor will have a new option to activate asymmetric times.
  • This option is disabled by default.
  • Users can activate the option if they need asymmetric times.
• Activation of Warnings for Asymmetric Times:
  • The editor will have a new option to enable/disable warnings for asymmetric times (displayed in orange).
  • This option is enabled by default.

Saving Settings:
The activation of asymmetric times, as well as the flag for warnings of asymmetric times, will be saved in the JSON of the variant.
This ensures that the settings are retained for future edits.

Example JSON Implementation:

{  
  
   "metadata": { 
     "asymmetricTimes": false, 
    "warningAsymmetricTimes": true,   
   
   }
}

User Interface:

• A checkbox or a switch in the editor (under Settings) to enable or disable asymmetric times.
• When the option is enabled, users can enter times that are not symmetric.

Technical Requirements:

• Adaptation of the NGE to support the new option.
• Extension of the data model to store the setting for asymmetric times.
• Ensure backward compatibility for existing timetable concepts.
• The route graphic needs to be adjusted or checked to ensure it can handle asymmetric times.
• The propagation function needs to be verified.

Advantages:

• Increased flexibility in creating and adjusting timetables.
• User-friendly with simple activation and deactivation of the function.
• Storing the settings ensures consistent editing.

Example Timetable 2024

Link to design proposal file

No response

[aiAdrian]

Thank you for the feature request regarding the implementation of asymmetric times in the Network Graphic Editor (NGE).

Due to the fundamental concept of the Netzgrafik-Editor, the feature request has at the moment very low prio. (Of course - any development support could increase the current prio.)

The concept of the Netzgrafik-Editor (Regular Interval Timetable) does at current state not accommodate asymmetric times. The symmetry is fixed so far and cannot be adjusted without breaking the basic concept of the regular interval timetable. Furthermore, the zero-minute symmetry is defined as given in the Network Graphic Editor - this must be overworked in the core modules. Therefore, only times that are symmetrical to the zero minute can currently exist in the Netzgrafik-Editor so far (editing/processing/calculation, etc.).

Decision

Conclusion: The desired feature to support asymmetric times cannot be implemented as requested at this stage of development through core development team. And it requires deep analysis how it could be implemented -> But any proposal are very welcome!

Alternative proposal

However, importing timetables from external systems with asymmetric times could be enabled through an import interface. It is necessary, though, that an exact transformation concept is available, detailing how the "erroneous" times can be quickly and easily found and manually corrected by the user, or how the times could potentially be automatically corrected.

A manual correction could be the first and simplest step in this process. If these times are to be edited with standard tools, it must be clearly indicated which times break the zero-minute symmetry. For this purpose, validation including a warning (orange) is available, meaning erroneous times are marked with a warning and rendered in orange.
As long as not all times are correct, i.e., processed/corrected, side effects may occur. It is necessary to determine what this means. An analysis is required to identify what errors might occur if times are asymmetric. This is currently unclear. Therefore, a thorough analysis must be conducted before implementation to assess the potential impacts.

Next steps

• Analytical work required to get deep understand what asym. times would mean.
• Conceptional work required to get a solution proposal
• Ensure that by default only sym. times will be used. Expert mode which could enable asym. tmes would be feasible. Expert sync required
• Avoidance any forking system when users ask for asym. times must be ensured !

[aiAdrian]

• Dependence with [Feature request]: Dwell/Waiting Times at Terminus #278

[aiAdrian]

UPDATE

The feature request is now receiving more attention. SNCF and SBB are currently working on this topic and analyzing how it can be implemented. If anyone is interested in contributing, whether in implementation, UX design, or the technical concept, they should contact the community. The implementation will start in the next few weeks, but details have not yet been finalized.

[aiAdrian]

The requirements and user interface (UX) are documented in [Design/Requirements - Business oriented documentation] Asymmetric times #421