10:57 p.m.
Hi,
Am 01/06/2020 um 14.08 schrieb Rolf Eike Beer:
Am Montag, 1. Juni 2020, 11:13:54 CEST schrieb Rainer:
> Hi Maarten,
>
> I agree that the tags railway:pzb, railway:etcs etc. are chosen
> awkwardly. The tag should express that these are train control systems;
> now with railway:pzb=* you have to know that pzb is a train control
> system. If somewhere in the world the system xyz is added, it is not
> recognisable from the tag as train protection.
> Therefore I suggest to change railway:pzb|etcs|lzb|atc|...=yes|no into
> railway:train_protection:pzb|etcs|lzb|atc|...=yes|no . This would
> provide more clarity and make it possible to actively set a
> railway:train_protection=no to express that no train protection system
> exists and to distinguish it from the lack of information.
How about
railway:train_protection=pzb;lzb;etcs
railway:train_protection:etcs:level=2
That would be only _one_ key to check.
We had this discussion years ago, but I don't remember the outcome anymore.
There was no real discussion. It was a GitHub ticket and an email by
myself on 27 November 2014 asking for comments but I did not get any.
https://lists.openrailwaymap.org/mailman3/hyperkitty/list/openrailwaymap@...
The current system of tagging train protection is designed
in a bad way in two aspects:
1. We have one key per train protection system. As long as a map style
developer knows all train protection systems (i.e. a map limited on
Germany and Austria), this works. Current display of train protection
is, as documented in
https://github.com/OpenRailwayMap/OpenRailwayMap/issues/64#issuecomment-1...,
still a temporary, Germany centric solution. :-( However, there is a
large number of different train protection systems in use all over the
world. In order to render a true "no train protection here", a special
"there is no train protection here" tag is required because a map style
developer cannot have knowledge of all train protection systems. A tag
such as railway:train_protection=no as Rainer suggested, would fix that.
2. Using one key per train protection system is not a good design. It
requires a style developer to know all keys used for train protection
systems. This does not scale well. If we used an unlimited number of
keys with a common prefix as suggested by Rainer, it would counteract
the idea of a key-value based systems where keys are used to query their
values.
Back in 2014, I suggest to use a limited number of keys only (about
three or four) where each key would represent one level of safety.
However, it introduces duplication and stores the safety level of a
system in OSM. I doubt that people might disagree on the safety level of
a certain train protection system and therefore agree with Eike's simple
(and therefore OSM-like) solution for the problem.
Best regards
Michael