Hi Michael,
After reading through this further, I could make the counter argument that modern systems like (ETCS Level 2, LZB) include cab signalling where
signals along the line are not necessary and everything is shown on a display in the engine does not meet the very On The Ground Rule of OpenStreetMap. To map this information you will need additional knowledge to identify the technology through government or company documents to make a correct assessment on the specific system in use.  

How is this different from what I am suggesting? 

If we can both assume that we both have extensive working knowledge of railroads or railways and that we can identify correctly the system in use. Can we assume that we should be allowed to map it if we can look at the ground and see that it is what it is? Or do we need to make the assumption that we don't have a working knowledge of railroads or railways and that we need to assume a role as an outsider when mapping railroads and only map what we can see (signals, switches, balises, magnets, contacts etc.)? 

This discussion appears to skirt around the On The Ground Rule of OpenStreetMap.  

Cheers, 


On Tue, Jun 9, 2020 at 3:38 PM Natfoot <natfoot@gmail.com> wrote:
Hi Michael,
Here in America what you are describing in train protection is Positive Train Control (PTC). Positive train control has GPS based land stations and locomotive GPS attachments and hardware. 

As you say OpenStree Map has a very On The Ground Rule which would be hard to identify PTC technology as it does not have significantly different structure than the existing structures. 

 What is identifiable is CTC or ABS (Centralized Traffic Control) (Automatic Block Signal) as it has on track equipment and signals (balises, magnets, contacts etc.)  Here the operating rules are often displayed with signs along the right of way or will let you know when existing or entering a specific territory. (Yard Limits, Restricted Limits, CTC, ABS, etc.) We have signs that say "Begin CTC" Example from Mapillary:  https://www.mapillary.com/app/user/natfoot?lat=39.762375&lng=-104.99513333333333&z=17&pKey=GDmK3f1fVHR22Gt59iH4gw&x=0.27772407542856226&y=0.825802077356415&zoom=2.9199206040680172&focus=photo    

In our case a "Company Rule Book" would be needed to identify PTC as that is not common knowledge. The only identifiable visual systems are GPS receivers on railroad hardware, which could be PTC or just a GPS tracker. Unless this information can be requested through the FRA, STB or the general Federal Transportation Commission.  Either way you are unlikely to get detailed information needed and this continues to lack the on the ground requirements of OpenStreetMap. 

Best Regards,
Nathan P


On Tue, Jun 9, 2020 at 2:00 PM Michael Reichert <osm-ml@michreichert.de> wrote:
Hi Nathan,

Am 08/06/2020 um 17.49 schrieb Natfoot:
> 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.

Train protection in the context of this discussion means technical
equipment installed in or very close to the track ensuring that

- trains do not pass signals showing a stop aspect
- distant signals with warning aspect are recognized by the driver
- trains break between the distant and main signal
- trains do not exceed speed limits

Many modern systems (ETCS Level 2, LZB) include cab signalling where
signals along the line are not necessary and everything is shown on a
display in the engine.

In some cases, there can be no equipment on the line. Imagine a train
protection system stopping trains of opposite direction on a
single-track line based on GPS measurements on the engine.

Train protection systems ensure that trains do not violate movement
authoritations by the dispatcher.

What you describe are the operational rules and interlocking.
Operational rules are difficult to map in a project as OpenStreetMap
which has a strong On The Ground Rule (i.e. things need to be verifiable
on the ground). One can see equipment on the track (balises, magnets,
contacts etc.) but the detailed operation rules are not reflected by
signs (e.g. a board with something like "Company A Rulebook ends here").

Best regards

Michael