This tagging discussion is relevant for PR703 so I added a copy of this email there.
Dear community,
EBICAB is a trademark for on-board equipment, from a specific supplier (Bombardier). The entire train protection system contains some other things [1]. The entire system is called ATC in Norway and Sweden, while Portugal calls the exact same system CONVEL. To add more confusion: Denmark calls [its own system](https://de.wikipedia.org/w/index.php?title=ZUB_123) ATC [2], while it is incompatible with the Norse/Swedish/Portuguese system.
Also the current situation in OSM is different than you currently envision (with adding the `railway:ebicab=700` tag): in the past I already added `railway:atc=yes` tags to relevant tracks in both Portugal and Norway with the same purpose. You also envision the `railway:ebicab=900` tag (probably for Finland) while Finland uses the `railway:jkv=yes` tag with the same purpose. Denmark is a bit of a blank slate, because Denmark doesn't have train protection tags yet.
OpenRailwayMap has 2 options:
1. Render compatible systems
consequences:
a) we proceed with this PR as is
b) we have to retag Portugal, Sweden, Norway and Finland (I'm willing to help)
c) we should create an additional PR to also render `railway:zub=123`
d) Denmark should be tagged with `railway:zub=123`
2. Render local names
consequences:
a) this PR should change to `railway:convel=yes`
b) we should retag portugal from `railway:ebicab=700`/`railway:atc=yes` to `railway:convel=yes`
c) we need an additional PR to render `railway:atc=yes`
c) Denmark should be tagged with `railway:atc=yes`
I am in favor of option 1, because my opinion is that the goal of ORM signalling layer should be to show compatibility.
Best regards,
JJJWegdam
[1] Overview of train protection systems in PT, DK, NO, SE, FI as far as I currently understand them
[2] Danish border, seen from Germany. Note the start-of-ATC signs.
Dear contributors,
The Dutch national law (https://wetten.overheid.nl/BWBR0017707/2020-04-01 appendix 2, chapter 13) allows two types of ETCS stop marker signs under the same signal reference number:
This makes tagging a bit harder than usual. Normally we would just say:
railway:signal:train_protection = nl:227b
Because there are two types of signs I propose the tags:
railway:signal:train_protection = nl:227b_triangle
railway:signal:train_protection = nl:227b_arrow
In case we agree about this, I will proceed with changing the wiki and my (currently 'paused') pull request.
Best regards,
JJJWegdam
Dear Eike,
Thanks for your amendment. I agree with your proposed improvements. I'll change the relevant part of the wiki and my recent pull request to match your tagging scheme proposal:
railway:signal:train_protection = NL:227b
railway:signal:train_protection:shape = triangle
I won't do this immediately; I'll do it as soon as this mail discussion had no new input for one week.
Best regards,
JJJWegdam
Op 22 januari 2021 om 17:42 uur schreef Michael Kümmling <michael(a)kuemmling.eu>:
Am 22.01.21 um 13:46 schrieb Rolf Eike Beer:
Am Dienstag, 19. Januar 2021, 22:49:52 CET schrieb JJJ Wegdam via
Openrailwaymap:
The Dutch national law
(https://wetten.overheid.nl/BWBR0017707/2020-04-01 appendix 2, chapter 13)
allows two types of ETCS stop marker signs under the same signal reference
number:
This makes tagging a bit harder than usual. Normally we would just say:
railway:signal:train_protection = nl:227b
Because there are two types of signs I propose the tags:
railway:signal:train_protection = nl:227b_triangle
railway:signal:train_protection = nl:227b_arrow
In case we agree about this, I will proceed with changing the wiki and my
(currently 'paused') pull request.
I think this needs a bit more context. First, this is the PR he is talking
about: https://github.com/OpenRailwayMap/OpenRailwayMap/pull/701
It started with an innocent "let's add the ETCS stop marker rendering as used
in NL". But then I came up with this:
According to the German Wikipedia this is an older version of the signal
which has been replaced in newer versions of the ETCS standard because it
could be confused with a France signal of different meaning.
It looks like both are permitted in NL at the moment and this will not change
shortly:
The Netherlands has two ETCS level 2 trajectories (railway lines with ETCS
block markers). The high speed line between Amsterdam and Antwerp has (both
on Dutch and Belgian soil) the triangle-shaped signs. The cargo line from
Rotterdam to the Ruhrgebiet area has arrow-shaped signs. There are no plans
to change the triangle-shaped block marker boards on the high speed line.
My current solution is to use
"railway:signal:train_protection"="DE-ESO:ne14"on the Germany-bound line and
"railway:signal:train_protection"="NL:227b" on the Belgium-bound line.
And that is the point where I started to disagree:
Any tagging of DE-ESO signals on a railway line in the Netherlands is plain
wrong, this is just "tagging for the renderer".
So, the question is, what are we doing now. In my eyes the whole situation is
very similar to what we have regarding H/V light signals in Germany, where
there are at least 3 types all tagged the same as they have the same meaning,
they just differ in how they are built.
I would think adding another subtag like ":version", ":generation", ":shape"
or something for all of these cases, and then do something like
railway:signal:train_protection = nl:227b
railway:signal:train_protection:shape = triangle
Shouldn't this be NL instead?
railway:signal:main = DE-ESO:hp
railway:signal:main:form = light
railway:signal:main:shape = compact
The same also applies for the newer signals where entirely different shapes
are in use if mounted inside a tunnel or beneath a platform roof:
railway:signal:main = DE-ESO:ks
railway:signal:main:shape = tunnel
The advantage is that noone has to do case switching if the actual form of the
signal isn't relevant, e.g. when doing some sort of routing, you only need to
know there _is_ a signal. Renderers then can look at the subtags and decide to
use whatever default fits best if it is not present.
I support your proposal. If a signal has different variants, which share
the same number, name and meaning, it should have one value in OSM/ORM
as well.
Regards,
Micha
