About the spreadsheet I can make one in my nexcloud and share a public link.

Awesome, can you send me the link. maybe @princeofnaxos can add some details about the Swedish signaling system.

Then once it's complete you can move it in your website maybe in the form of a wiki page.

Or we could convert it to markdown an add it to git, e.g. in a docs folder. Then it is easier too keep it in sync with the code.

Instead of extracting an "engine" which controls a generic multipurpose signal tile which could be difficult to do, we could instead do a base class for each signal system and derive it. Like Italian base system has the logic and subclasses set the allowed aspects in constructor. Lime it's currently done for turnouts. Also signals of same system should be "upgradable" by dropping a tile onto another.

The benefit of using a generic multipurpose signal tile would be that changing/upgrading the signal type is easy, just select another type. However when using separate tiles it is easier to support a limited number of upgrades. e.g. disallow change from ITA to NL.

Currently "sub object" are kind of const, these properties are set once at construction but never change afterwards. (The object the property refers to isn't const of course.)

Maybe we can experiment with both and see what works best for developers and end users. The number of signaling systems could easily reach 20 I think. Changing object properties at runtime will also require client modifications as that isn't supported currently. I'm curious if it is a good or a bad idea, so I'll create a branch to do some experiments next week.

p.s. I like to release Traintastic 0.3 soon, mainly to have a new release 0.2 is over a year ago, so this signaling stuff will not go into 0.3. For 0.4 I'd like to make Traintasic have the base minimum features for block / some form of automatic trains. Signaling would be a good addition, as the different systems might give insights on things to take into account for automatic trains.

We can try this: https://ethercalc.net/=x3pz4ie5o997

I added the generic and NL signals and saved a local copy (as anyone reading this can edit it now 😎)

I did't understand the sub object thing...

My bad, I'd hope to build a small demo next week on a branch to demonstrate and try to explain it again :)

About automation we should add a "lengt" property to blocks to calculate brake distance.

And you need block / turnout position speed limits to determine the correct aspect.

Also add a generic way to extract speed limit from any type of signal.

Yeah, for sure. While adding the NL aspects, each aspect is basically a combination of a few things. For the ITA signals it is the same I think, I'd hope there is some overlap :)

@reinder I saw you added NL signals. I like this table approach.
But... I think there might be a bug in ethercalc when saving :(
If I download the file locally in ODS or EXCEL format it's full of garbage, probably wrong character encoding.
Only HTML and CSV seems to be working.

I've updated a new file at: https://ethercalc.net/=railwaysignals
which has the correct sheet name and some initial Italian signals integrated in your table scheme

Yeah, there is indeed a bug in Ethercalc, the ODS I downloaded is garbage too.

Nice work, there are really a lot of aspects!

Proceed, max 30 km/h, brake until 30 km/h, must be reached at next signal

I don't get this one.

• Is the speed limit 30 km/h? (then there is no need to brake) or
• Is it allowed to pass at a higher speed but must the train slowdown until 30 km/h?

I added a few column in the front (not yet complete), I thought it would be nice if we can break down the aspects into "attributes", we can use that more easily for train control.

• Is the speed limit 30 km/h? (then there is no need to brake) or

Yea sorry, I've just copied "brake" from the line above. The meaning is:

• You can pass at 30 km/h
• Next signal will allow passing at 30 km/h

So basically you're always at 30 km/h until maybe next's next signal :)

Instead what does it mean: "Proceed, brake until 60 km/h, not required to be reached at next signal"?
I can pass the signal at any speed and then brake until 60 km/h even after next signal?

Instead what does it mean: "Proceed, brake until 60 km/h, not required to be reached at next signal"? I can pass the signal at any speed and then brake until 60 km/h even after next signal?

That is correct, the next signal then will be "brake until 60km/h must be reached at next signal". I think it is a short block thing, we're one block isn't enough to brake to 60 km/h.

By the way we also have "candle tree" signals (In Italian "Segnali a candeliere") which unfortunately were replaced around 2017 so I've never got to see one in action.
They were used in junctions, station entrances and station departure signal to tell driver which direction will be taken by the train.
This is one example:

But there are many combination, for example in symmetric junction there is not central topmost lamp, like this:

Here (Milan) both paths have speed reduction, i.e. no straight path exists. Left lamps can show "Proceed", "Stop", "Proceed, expect stop". Right side instead has 2 lamps because it can show "Proceed but partially occupied track ahead, max 30 km/h", which is "Red, Yellow, Yellow", Red is placed on the left side lamp.

Or it's only straight/left or only straight/right like this (straight/left):

Hi @reinder, I'm trying to understand Block reservation logic.
They have a ObjectVectorProperty<TrainBlockStatus> trains property but it seems even if multiple inputs are attached to a block, only one train can be assigned to it.
While this is correct for normal mid-line blocks, in stations it should be allowed to let 2 trains enter the same track, provided that block has at least 2 inputs, first train only occupies second input and is stopped, then following train can enter with reduced speed and stop at the end of block's first input limit.
We could add a new boolean property "allowMultipleTrains" which defaults to false and is disabled if there is a single input.
I can remove some of the "return false" inside the BlockTile::reserve() but I want to understand if there could be side effects first.
Also how should client draw block tile if there are multiple trains in it?
This scenario is perfect for merging 2 passenger trains in a station which then go to a common destination.

I'm trying to understand Block reservation logic. They have a ObjectVectorProperty<TrainBlockStatus> trains property but it seems even if multiple inputs are attached to a block, only one train can be assigned to it. While this is correct for normal mid-line blocks, in stations it should be allowed to let 2 trains enter the same track, provided that block has at least 2 inputs, first train only occupies second input and is stopped, then following train can enter with reduced speed and stop at the end of block's first input limit.

That is indeed not supported yet, the trains property is already a vector so it can be supported in the future.

We could add a new boolean property "allowMultipleTrains" which defaults to false and is disabled if there is a single input. I can remove some of the "return false" inside the BlockTile::reserve() but I want to understand if there could be side effects first.

I think it is best that "normal" reservations always fails if a block is occupied. Entering an occupied block is something special with a few use cases which involve other operations too. So I think it is best to handle it as a special thing.
The property allowMultipleTrains is a good idea :)

Also how should client draw block tile if there are multiple trains in it? This scenario is perfect for merging 2 passenger trains in a station which then go to a common destination.

That isn't supported yet, but should be supported in the future.

Merging trains really is an advanced operation, something we must take into account, however I think we should first implement the "normal" reservation and train tracking stuff :)

That isn't supported yet, but should be supported in the future.

Merging trains really is an advanced operation, something we must take into account, however I think we should first implement the "normal" reservation and train tracking stuff :)

Sure. In the meantime I've added support for "partially occupied aspect even though it cannot be disabled yet for mainline if it detects multiple inputs for a block. When we'll move to advanced stuff it will be ready.

I've also added "anticipation-only signals" (Avviso) using same base class.
Now things todo:

1. Add tests and properly check edge cases
2. Support 1/2 lamps signals by reducing allowed aspects
3. Fix output map which crashes on save because of enum type mismatch
4. For completeness I could add "blinking yellow" which is for reduced block length but it would be rarely used in model layouts so low priority.

Hi @reinder I've implemented setting signal lamp count. However in client board drawing code signals with 1 lamp look ugly.
They should have a white circle around the lamp and instead the are 2 semi-arcs which intersect each other.
I've tried to keep code generic and easy to understand but now it got complicated I think...

@reinder since this is WIP and becoming a very long conversation, I think we maybe should invite @gfgit to Pumble? Certain things should really be written here for the world to read, but many things could remain internally.

Just created a discussion thread, as this is more about signaling in general now -> #123

I think we maybe should invite @gfgit to Pumble?

Hi, thanks for the invitation but I don't like that platform. I don't think it's so bad to discuss this in #123