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