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.

Translated with www.DeepL.com/Translator (free version)

- Rainer

Am 31.05.20 um 23:31 schrieb Maarten Deen:

On 2020-05-31 21:04, JJJ Wegdam via Openrailwaymap wrote:

...

Dear ORM community,

As far as I know, the signalling layer renders train protection absence as soon as a way contains railway:pzb=no and railway:lzb=no. I implemented this throughout over 10 European countries. A user from Belgium is now complaining about this. He argues that Belgium doesn't have the PZB nor the LZB system anywhere in the country and that thus these tags should not be in the country. Could you please provide your thoughts on this complaint? You can contribute to the discussion at https://www.openstreetmap.org/changeset/85628039#map=13/50.8173/4.3336 or reply to this email.

I agree completely that you should not tag railway:pzb=no or railway:lzb=no in countries where there is no PZB or LZB. There is no default saying that having no train protection tags means it has PZB or LZB. Even in countries using PZB or LZB it should be considered superfluous to tag this since the default is no. Also tags like railway:etcs=no and railway:tbl=no that are still on some ways there I would like to disencourage very much. The default is no, so you don't have to tag that it is not there.

It I look at the openrailwaymap signalling layer it says "no information" or "no protection" or PZB/ATB/LZB/ETCS. I assume that the renderer knows which tags are for train protection (a bad scheme IMHO, see 1) below) and only renders lines without any of those systems as "no information" and renders lines without PZB/ATB/LZB/ETCS as "no protection". If that is so then the solution is easy: change the legend tag "no protection" to "other train protection". And "no information" should be "no protection" if there is no positive tag saying there is train protection. Sure, you will have a lot of false negatives, but people will notice and will amend the tags.

I wholeheartedly agree with Eimai. Do not go out and tag all the railway lines in the world with railway:pzb=no and/or railway:lzb=no just to get that map looking like you want to. He is right, this is tagging for the renderer. I see an area around Laon as well: railway:etcs=no, railway:kvb=no, railway:lzb=no, railway:pzb=no. Come one. There are 60 other train protection tags, add them as well, or why not?

1. It should be more like railway:train_protection:pzb=yes/no. Why is

railway:pzb a train protection tag and railway:gnt not. This makes automation around these tags very difficult. When you add a new train protection tag, the program needs to know about it. If you use railway:train_protection:xyz, then everything starting with railway:train_protection: is about train protection, and if you don't recognize the type, then you know it is "other" for your purposes. If you add railway:xyz as a new train protection tag, you have to reprogram everything that is working with these tags.

Maarten

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.

Eike

Thanks for your input everyone. I also agree with Eikes proposal.

...

Op 1 jun. 2020 om 15:49 heeft Rainer Elbing r.elbing@gmx.de het volgende geschreven:

Yes Eike, I agree, one key that can is sufficient and more clear in my opinion.

Rainer

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 email: natfoot@gmail.com

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@ope...

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-1547... , 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

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.995133...

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 email: natfoot@gmail.com

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

Hi Nathan,

On 2020-06-09 7:21 p.m., Natfoot wrote:

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?

ETCS systems have Eurobalises/Euroloops on the track for odometry and other messages, and LZB has cable loops. These are both visible on the ground. PTC and rules are not.

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.*)*?

I think this is where we need to separate the discussion between rules and train protection. Taking the ETCS example, one can affirmatively assert that a railway line is ETCS-equipped by pointing out Eurobalises/Euroloops. Similarly in the US, one can affirmatively assert that a line is ACSES-equipped by pointing out its balises.

Operating rules are not train protection systems. Using the same two examples, I couldn't tell by looking at what's on the ground whether an ETCS-equipped railway line is operating in Level 1, 2, or 3. Similarly, I couldn't tell by looking at what's on the ground whether a North American railway line is OCS or Rule 105/non-main track (or indeed whether it is PTC-equipped in the US).

In _some_ circumstances, one may be able to tell where CTC or OCS territory begins and/or ends. While signs for these exist (in some locations), they are not properties of the railway line itself: rather, they are properties of how movements on the railway line are conducted.

For example, consider the difference between OCS+ABS and CTC. By simply observing the railway in situ, could you tell the difference between the two? (And the signs don't count, because they could simply be overridden in Special Instructions (or the US equivalent). Moreover, there are no signs that differentiate -- for example -- siding control territory (SCT) from CTC sidings in Canada.)

While I could *maybe* see a future schema where things like cautionary limits, yard limits, CTC/OCS limits, station name signs etc. are defined, they certainly don't fall under the existing train protection schema.

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

While we're talking about skirting the rule, I find it peculiar that ITCS is included in the train protection systems schema, since (AFAIK) its main selling point is that it has no trackside infrastructure. Surely if we're going for a consistent "on the ground" approach, we should remove this, no?

(I've been following the project and mailing list for a while but can't seem to recall this being discussed recently, and haven't found anything in the archives.)

Cheers, --Tyson

I am having difficulties with this nitpicking of what is on the ground and the whole discussion whether or not we are allowed to map it or not. We can also not check the speed of highspeed lines on the ground since they usually have no speed signs. Yet we still do map that.

I would be very pissed off if we come to a conclusion that we need absolute 100% on the ground verifiability for each and every item that we map when there are multiple (for OSM legally) usable sources where we can verify the correctness. There is no rule saying we can only map things that are physically observable. The "Map what's on the ground" rule is about what to do when conflicting information is presented, not a ban to not map things you can not observe.

Regards, Maarten

On 2020-06-10 08:07, Natfoot wrote:

...

Hi Tyson,

Here is the issue I have. You say that you can tell whether a ETCS-equipped railway line is operating in Level 1, 2, or 3. How do you know it is an ETCS-equipped line? Your response would be that, "one can affirmatively assert that a railway line is ETCS-equipped by pointing out Eurobalises/Euroloops." How do you know that? This sounds like special knowledge rather than information I can pick up by standing next to it or looking directly at it. If I may for a moment look at CTC how do I know that that is by looking at the signals and shunts. Do I have special knowledge? Yes, I do. Does this change your argument? This is what I was asking when I said. "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.)?"

I will agree that understanding if you are looking at a CTC line or not is a specialized characteristic of a mapper. And I will also assert that understanding if you are looking at an ETCS-equipped line and Level 1, 2, or 3 is also a specialized characteristic of a mapper.

Be Careful about the use of terminology as it may not be the same. I will not assume that the OCS that you are using here means Occupancy Control System as I found a completely different meaning on Wikipedia.

I would be the first to agree that Train Protection in this context primarily aligns with PTC as I described in my previous email: " 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. " ACSES is a specialized version of PTC and not wide spread here. I had to look this up to find this out. I think we can both agree that the detail in your statement is too much detail for OpenStreetMap "(And the signs don't count, because they could simply be overridden in Special Instructions (or the US equivalent). Moreover, there are no signs that differentiate -- for example -- siding control territory (SCT) from CTC sidings in Canada.)" Your statement is like saying we should not map the seasonal roads as they could be closed. Seasonal roads here are tagged as "access:conditional" rather than leaving it without a tag. Of course those tags are general and not specific and the road department can close the road or make it one way at any time.

In your statement: "While signs for these exist (in some locations), they are not properties of the railway line itself: rather, they are properties of how movements on the railway line are conducted." So what is ACSES, ETCS, and LZB? These are not descriptors of the line; these are descriptors in your words of wayside equipment (Eurobalises/Euroloops, balises, and signals) attached to a system of train protection for train moments. I would conclude that "they are not properties of the railway line itself: rather,they are properties of how movements on the railway line are conducted."

Are these two arguments clear? OpenStreetMap is not an ideal place for a lot of the railway data we want to add to OpenRailwayMap. I would reconsider the use of "Signalling" to "Train Protection" on OpenRailwayMap, if your argument stands. Signalling is train movement.

Cheers,

Nathan P

email: natfoot@gmail.com

Reference: As*sert _verb_

state a fact or belief confidently and forcefully.

"the company asserts that the cuts will not affect development"

Hi Nathan,

I don't think it's productive to discuss the similarities/differences between specific operating rules or train protection systems in the US and Canada on-list. Clearly, we have differing views on what does or doesn't qualify as being directly observable on the ground, but that's not something I think we need to reconcile for reasons I'll lay out.

I agree with your and Maarten's assessments that there is immense value in including non-directly-observable information in ORM, no matter where we draw the line. As wayside infrastructure starts to disappear in favour of radio communication, I think the "on-the-ground" rule/principle will become increasingly difficult to adhere to.

My sticking point with your original proposal is including operating rules in the train protection systems tagging schema. I'm not necessarily trying to nitpick anything else; I'm more thinking out loud about where more description (good!) would fit in (purely from a user's perspective). On this point though, I have to agree with Michael: ETCS, LZB, AWS/TPWS, ACSES, PTC, etc. are clearly distinct from OCS, CTC, TWC, cautionary limits, etc. and IMO should have a distinct tagging schema.

I would gladly support a proposal to add tagging for operational rules *iff* it can be done in a sensible way that doesn't conflate these two concepts.

I'll keep monitoring the discussion.

Cheers, --Tyson

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").

It seems to me that in regards to mapping train protection/train control/operating rules, that we have several considerations going for us:

- There may be no physical infrastructure to an operating rule, but there is consistent behavior.  Consistent behavior can be observed, physically.

- It is appropriate to map speed limits on roads.  While these are generally accompanied by speed limit signs, legally (at least in the United States) it is not the sign that governs, it is the legal status of the limit.  If protesters remove or change the signs, the legal speed limit does not change.  Thus when mapping operating rules, the "legal" status of the tracks is what governs, not the presence of infrastructure.  If some vandal removed the signal, train crews are still required to stop for it.

- legal operating rules also matter for roadways that are public or private.  They should be mapped differently to avoid confusion even though there may be no physical infrastructure to distinguish them.

- This is information which would be useful to the community (including myself, personally) and would not interfere with any existing features.  It is the kind of information that already appears on other maps and has for at least a hundred years (I have such maps in my collection).  Seems to me that the default should be to favor usefulness.

Christopher Parker

Please disregard my last - my mail client managed to hiccup and somehow attach that reply to not only the wrong thread, but the wrong list. Apologies for the confusion. Chuck

On Fri, Jun 12, 2020, 11:17 PM Chuck Sanders nathhad@gmail.com wrote:

I'd love any information you can send regarding any sort of route number in use here like you're discussing. I've worked around the US rail industry for several decades (federal bridge engineer), and have never heard of such a thing, so I'm very curious.

You're not talking about the FRAARCID in the FRA dataset, right?

And I have to say, while "don't tag for the renderer" is almost always right, it also doesn't mean that a tag that works well already is automatically wrong, provided it also doesn't damage the validity of integrity of your dataset.

Thanks! Chuck

On Fri, Jun 12, 2020, 10:53 PM Christopher Parker < conductorchris@gmail.com> wrote:

...

...

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").

It seems to me that in regards to mapping train protection/train control/operating rules, that we have several considerations going for us:

• There may be no physical infrastructure to an operating rule, but

there is consistent behavior. Consistent behavior can be observed, physically.

• It is appropriate to map speed limits on roads. While these are

generally accompanied by speed limit signs, legally (at least in the United States) it is not the sign that governs, it is the legal status of the limit. If protesters remove or change the signs, the legal speed limit does not change. Thus when mapping operating rules, the "legal" status of the tracks is what governs, not the presence of infrastructure. If some vandal removed the signal, train crews are still required to stop for it.

• legal operating rules also matter for roadways that are public or

private. They should be mapped differently to avoid confusion even though there may be no physical infrastructure to distinguish them.

• This is information which would be useful to the community (including

myself, personally) and would not interfere with any existing features. It is the kind of information that already appears on other maps and has for at least a hundred years (I have such maps in my collection). Seems to me that the default should be to favor usefulness.

Christopher Parker