I would like to add my two cents to this topic.  I am starting to realize by going through this email that it appears that Track Authorization (Traffic Control) is completely omitted from OSM.  I hope to use the railway tags from OSM/OHM data in a future project. With this in mind here are my comments. 

1) The description of railway:train_protection=no is inherently wrong. 
       Train protection is given or accepted by a set of rules either provided by the rule book or the track territory.   Now in the case of GCOR (https://en.wikipedia.org/wiki/General_Code_of_Operating_Rules) Rule 6.28 it says
"...trains or engines must move at a speed that allows them to stop within half the range of vision short of: Train, Engine, Railroad car, Men or equipment fouling the track, a Stop signal or Derail or switch lined improperly." (6-13 GCOR—Seventh Edition—April 1, 2015) 

This rule basically says it's a free for all and that it is the responsibility of the train crew to provide the train protection. 

In the case of Positive Train Control this then becomes an additional responsibility of the computer or system. 
 

2) I am working on my own data set with as many details as possible. 
      Below are the issues of this topic. We have two layers of information to be provided, one is Authorization, Track Authority or permission that is given to a train and we have oversight or digital control.  Another thing to consider is that more than two options below could be in effect on any one track. 

     a) Authorization, Track Authority or permission
          1) non signaled territory 
              GCOR Rule 6.28 
              Form_D (DCS) NORAC
         
          2) signaled territory https://en.wikipedia.org/wiki/Railway_signalling
              CTC https://en.wikipedia.org/wiki/Centralized_traffic_control
              ABS / Rule 251 https://en.wikipedia.org/wiki/Automatic_block_signaling
        
         3) Could be in both
              Yard Limits
              Restricted Limits
              Time Table
              Train Orders
              OCS  and Verbal OCS, Occupancy Control System 
              Record Book or Block Book
              Form_D (DCS) NORAC    
              TWC / ATCS https://en.wikipedia.org/wiki/Track_Warrant_Control
              Interlocking
              DTC Directional Traffic Control   
    
      b)  Oversight or Digital Control 
               PTC Positive Train Control https://en.wikipedia.org/wiki/Positive_train_control
Trip Optimizer   https://en.wikipedia.org/wiki/Train_speed_optimization

In conclusion in the USA we have lots of "dark territory" which lacks signals or oversight/digital control and is controlled by Track Warrant Control which is a form of train protection.   This is important to get ironed out in my data set as I hope to use OSM/OHM data as part of my project.  

Regards
Nathan Proudfoot


On Sun, Jun 7, 2020 at 1:59 PM Michael Reichert <osm-ml@michreichert.de> wrote:
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@openrailwaymap.org/thread/6IOOVCKWBJ3CPOQK7LP2OJIQEMUVB5JU/

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-154743215,
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