Priority of rendering on railway:nexteo=yes + railway:kvb=yes #496
Replies: 1 comment 2 replies
-
This should be easy, we can change the priority of the signalling systems in OpenRailwayMap-vector/features/train_protection.yaml Lines 115 to 121 in 71fc72b
This is not possible at the moment yet, but it might be implemented. Currently the present train protection system is stored, and also the train protection under construction. We could make that to be multiple train protection systems. This matches the proposal in https://wiki.openstreetmap.org/wiki/Proposal:Railway:train_protection (single tag, multiple systems). |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi,
My observations
I saw on ORM that the rendering is prioritizing the kvb signaling over the Nexteo signalling. The fact is that Nexteo is more efficient and use an advanced technology compared to kvb. Furthermore, where nexteo is installed, the kvb system will apparently not be used in normal exploitation (but will be kept functional).
Due to this problematic, the RER E line (wich is totally equipped with a fully functionnal Nexteo system on the main part) appear only as equipped with the kvb.
Then my proposal:
Firstly
When the Nexteo system is on a same way than kvb, the Nexteo should be priorized in the rendering.
As there are the exact same problem with railway=sacem on RER A, the same logic could be applied.
Secondly
When a user click on a way, all the signalling functional are written, not only the one rendered.
It is really usefull. For exemple a lot of highspeed railways in Europe are equipped with the national system, plus the highspeed national system, plus the ETCS.
I think it's more a dev problem than a logic problem, but all the comments are welcome, there is never a unique solution to a problem.
Have a nice day,
Beta Was this translation helpful? Give feedback.
All reactions