Signaling systems

[reinder]

General discussion about implementing different signaling systems in Traintastic, originally started in #119.

Spreadsheet with signals and their aspects: https://ethercalc.net/=railwaysignals

[gfgit]

To summarize we had 2 big options:

Make a generic signal tile which has an "engine" property which can be changed at runtime and implements a specific signalling system

PROs:

• Less subclass code, but possible more duplication inside the engine code
• You can upgrade signal tile to any system

Subclass existing signal tile

PROs

• Limited tile upgrade which could prevent accidental changes to board
• Maybe more flexibility in implementation but this could be also achieved by making more callbacks into the engine

[gfgit]

About the signal aspect there are also 2 choices:

1. Make new aspect enum for each signalling system. This is more flexible but not interoperable between different systems (i.e. cross-country border situation)
2. Use existing SignalAspect enum, keep compatibility of first 3 basic aspects and add more values to it "subclassing" the enum.

Latter approach has issues with OutputMap which stores it's items based on aspect key. When saving it crashes inside to_json() function because aspect value is cast to base SignalAspect enum but it's not one of it's basic 3 values.

In #119 I've made a mixed approach where aspectITA property stores the "full" aspect and aspect gets a "best approximation" aspect which can be used by other signals of different system

[reinder]

Third option, add all aspects to a single enum. There probably is some overlap in aspects by various signaling systems. e.g. Proceed, with speed limit X is a common one I think.

[gfgit]

Yes we could put everything into a single enum but I think it does not end well when we'll have many different signalling systems, each with custom relationship between different aspects.

[reinder]

Over the past few days I have spent some time in the evening on the one signal tile experiment. Although it is possible it also adds some additional complexity and will require a single aspect enum with all aspects. I was also thinking about what would be the best solution for the different signaling systems.

Proposal:

graph TD;
    SignalRailTile-->GenericSignalRailTile;
    GenericSignalRailTile-->Generic2AspectSignalRailTile;
    GenericSignalRailTile-->Generic3AspectSignalRailTile;
    SignalRailTile-->NetherlandsSignalRailTile;
    NetherlandsSignalRailTile-->NetherlandsMainSignalRailTile;
    NetherlandsSignalRailTile-->NetherlandsDwarfSignalRailTile;
    SignalRailTile-->ItalySignalRailTile;

Loading

Remove the aspect property from SignalRailTile and add the aspect property in the base classes for the different signaling systems. Then each signaling system can have their own enum, e.g. GenericSignalAspect, NetherlandsSignalAspect, ItalySignalAspect etc. (or even

The SignalRailTile should have some methods to query the aspect so that can be used for cross border systems and train control. e.g. isStopAspect().

[gfgit]

This is quite like what I was thinking.
Base class SignalRailTile must have some pure virtual functions which are used as generic interface in both:

1. Cross-border signals which should agree on GenericSignalAspect common aspect
2. Automatic trains which should not care about specific signal system in use on the layout.

We could have some functions like:

1. getMaxPassingSpeed()
2. getTargetSpeedForNextSignal()

Which will get used for calculating braking curve, based also on block length and train deceleration rate.
isStopAspect() could be replaced by returning zero as max speed, although maybe it's less elegant.
Also, at least in Italy, signals only show temporary speed restrictions due to turnout positions. When in main line without turnouts or when turnouts are all straight signal show Green (Proceed) which means maximum speed is the railway line speed with no additional restriction.
So each block could have an additional defaultMaxSpeed property and of course a length property which in case of turnouts is tricky to calculate...

[reinder]

Another option is add a const SignalState& state() const method to SignalRailTile. SignalState then is a struct with information about the signal's aspect. Then we don't need a virtual function and can easily add additional fields in the future if required. The struct could also contain a flags field to indicate which fields are valid/supported by the signal (if we need that), for double we can also use NaN and infinite.

I prefer a bool for stop, it is quite an important aspect :) and much more readable :) When setting max speed to 0 you need an epsilon compare if a double type is used.

When in main line without turnouts or when turnouts are all straight signal show Green (Proceed) which means maximum speed is the railway line speed with no additional restriction.

This is also true for the dutch signals.

I think for cross border signals should just use state() also. The GenericSignalAspect is for the Generic signals only.
For real world border crossing we could implement support in the future.