Openrailwaymap January 2021

openrailwaymap@openrailwaymap.org

6 participants
4 discussions

Tagging decision: ebicab, atc, convel, zub123
by JJJ Wegdam 10 Apr '21

10 Apr '21

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.

4 7

Tagging proposal Dutch ETCS stop markers
by JJJ Wegdam 11 Feb '21

11 Feb '21

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

5 5

Re: Tagging proposal Dutch ETCS stop markers
by JJJ Wegdam 23 Jan '21

23 Jan '21

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

1 0

Railroad Signals, Specifically the ISO
by Natfoot 08 Jan '21

08 Jan '21

Hello Discussion List, Could someone fill me in on a chart of examples of this: https://wiki.openstreetmap.org/wiki/Key%3Arailway%3Asignal%3Adistant%3Astat… And This: https://wiki.openstreetmap.org/w/index.php?title=Key:railway:signal:speed_l… I am in the USA / North America. Thank You, Nat P email: natfoot(a)gmail.com

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

Openrailwaymap January 2021