Proposal talk:Railway:train protection

Values for specific systems

ETCS

Should ETCS be called ETCS or EU:ETCS?

ETCS is quite an international system. In fact, there are more ETCS-equipped outside of Europe than in Europe. So we should rather not add a "EU" prefix.

What is a "sublevel"? Is that supposed to be a [European_Train_Control_System#Baseline_3 Baseline]? Should be rather consider to (optionally) include ETCS modes, in particular "Full Supervision" and "Limited Supervision". Both might be added later.

Yes, I thought of baseline there. --Dakon (talk) 05:21, 12 April 2021 (UTC)

If already now advances can be thought of, I would suggest to think about ways to do that to not again later change everything if its not possible to integrate it in the recent system? But I could be wrong as well. What about the (in wikipedia) mentioned level STM/NTC? --bjoern_m (talk) 20:46, 24 March 2023 (UTC)

CTCS

A Discord user suggested to drop the CN prefix, like for ETCS.--Rokolell (talk) 21:41, 13 October 2024 (UTC)

Vendor systems

Maybe call them VND:something or VND:VendorName:something, e.g. VND:Bombardies:EBICAB? What happens if the company is renamed or the producing section is sold to another company?

I would not use vendor information, just the system name. Even if a system is highly proprietary from a single vendor it will have a unique commercial name. --DavideZH (talk) 09:05, 30 January 2023 (UTC)

I think using VND: prefix without the company name would make sense to avoid name clashes in the future.--Rokolell (talk) 21:41, 13 October 2024 (UTC)

There's no need to invent a unclear "VND" and mix it with ISO Alpha-2 country codes. That's not clean and organized.
When there's a renaming, or acquisition, the legacy code should continued to be supported. A new code could be considered the synonymous replacement.
I don't understand your argument. If 2 companies uses the same name, they will both be railway:train_protection=VND:ABC . This doesn't work.
Anecdotally, "VNM" is Vietnam's Alpha-3 country code. This makes it appears to be some variation about Vietnam.
—— Kovposch (talk) 06:11, 28 November 2024 (UTC)

Swiss narrow gauge systems

Call it (CH:ZSI90 and CH:ZSI127) or (CH:ZSI, CH:ZSI:90, and CH:ZSI:127)?

Vote for ZSI, ZSI:90 and ZSI:127 --DavideZH (talk) 09:01, 30 January 2023 (UTC)

I'm not sure if having them in the same namespace really makes sense. Sure, they use the same three letters and a different number, but ZSI-127 also supports ZST-90 inputs (on the train side, which should be irrelevant for mapping), not just ZSI-90 and uses completely different track side equipment (Eurobalises and Euroloops as opposed to just magnets). ZST-90 and ZSI-90 seem much closer related than ZSI-127 is to either, since the ZS(I|T)-90 systems are both based on magnet polarization, with ZSI-90 having one more electromagnet per point by default. And if we look at it from a mapping perspective either of the system has a unique appearance in the track (two magnets behind each other, two magnets besides each other, Eurobalises). The track side hardware can, to my knowledge, be shared between ZSI-127 and ETCS Level 1 (ZSI-127 is on packet 44). It also seems both ZSI-90 and ZST-90 have "enhanced" versions that add more information, more capabilities, and sometimes non-protection-system information is transmitted with similar hardware in a different position. The other factor to consider is that at least for now there will be places that have two track side systems, where ZSI-127 is overlaid over the existing equipment to enhance protection, while keeping costs low. This means that the same track might have both ZSI-90 and ZSI-127 equipment or ZST-90 and ZSI-127 equipment. There's also multiple modes of how they are mixed on an operational level from what I understand (where you can have trains that use either system, or where trains need to have ZSI-127 equipment). While ZSI-90 and ZST-90 are supposed to be replaced operationally, I don't think there's any hard limit on when the hardware has to stop being used, that will depend on replacement parts stock (I'm not read up on ZBMS though). As such, these values will probably stick around for a good while. Lastly I'd like to point out that there's already some railway:zsi90 tags in the wild, so it might make sense to document the tag here: https://taginfo.openstreetmap.org/keys/?key=railway%3Azsi90. --Freaktechnik (talk) 12:06, 14 May 2023 (UTC)

ATC in Sweden and Norway

I suggest the value SE:ATC to be used for railways in Sweden. That's the common name of the train protection system used here. The omboard equipment could be either Bombardier Ebicab 700 or Ansaldo L10000 [1], but the whole system is commonly referred to as ATC. Norway uses the same system, but differentiates between full ATC (FATC) and partial ATC (DATC) [2]. Therefore, I suggest the values NO:FATC and NO:DATC for Norway. Currently, railways in both Sweden and Norway are tagged with railway:atc=yes. Kildor (talk) 20:56, 14 April 2021 (UTC)

I suspect they have been tagged as ebicab until now? Makes sense to me otherwise. --Dakon (talk) 09:49, 17 April 2021 (UTC)

No, they have been tagged with atc. We could also consider using the same tag in Norway as in Sweden since they use the same system (with the exception that DATC is not used in Sweden). Kildor (talk) 22:34, 17 April 2021 (UTC)

Has any final decision been reached on this topic? It has been two years and the confusion is still the same. An unsuspecting user might start tagging Denmark with ATC rather than ZUB123 seeing as ATC is a valid tag... --1993matias (talk) 08:22, 12 April 2023 (UTC)

PZB and LZB

The proposal has the values of DE:PZB and DE:LZB for the former tags pzb=yes and lzb=yes. But these systems are not only used in Germany. Should the value still be DE:PZB when used in Austria and Serbia as example? And it seems as there are different versions of PZB, i.e. Indusi I-60 in some countries. Perhaps a different value should be used there? Kildor (talk) 09:42, 17 April 2021 (UTC)

Regarding the usage in other countries I'm actually not sure how this is best done. This likely depends if those countries just copy/translate the German rulebook or if they define things just the same way. We may end up either way.

I don't think it makes sense to have different versions for PZB otherwise as the differences are to my limited knowledge only the train side components, the track equipment is the same for all versions. --Dakon (talk) 09:54, 17 April 2021 (UTC)

Perhaps it would be sufficient only to use prefix, either for country or vendor, for systems where there is a name conflict, as with "ATC"? Kildor (talk) 22:46, 17 April 2021 (UTC)

I agree with the above, not using any prefix unless there is a real need for clarification. In this case I would use PZB and LZB, allowing for small regional variations, unless a country has a heavily customized version (although in this case it's likely it will have its own name). --DavideZH (talk) 09:00, 30 January 2023 (UTC)

Yup, I think we should use country specific prefixes if a system is only used in that specific country and normed by the its authorities. e.g. PL:SHP --Rokolell (talk) 01:27, 23 August 2024 (UTC)

Use

Regarding having a system in multiple countries: I am often not sure whether the systems are always completely the same, so it wouldn't distract if multiple country-codes would be combined with the system-code. Maybe it could as well be documented in the same way? > It would allow distinction and searching in countries if necessary, and they should be able to be regex'ed as well for rendering. I see a problem at the place that it's not always directly possible to exclude the use of a train protection system. (so in some cases I'm sure that pzb is used, but have not seen yet whether lzb is used). How can I say that (and I would likely avoid to use to many fixme or note tags..). Furthermore I would suggest that in the documentation it could(!) be specified per country which system is the most sophisticated (should be easier with on-the-ground/country-based knowledge) Would you like to integrate information on (e.g. balise like) GNT systems as well? Furthermore I have seen a new version of the table in which also block technology is mentioned. I would like to keep that one outside of this proposal, but maybe there could be another one? (see tags like railway:bm) --bjoern_m (talk) 20:50, 24 March 2023 (UTC)

Regarding uncertainties: my understanding it is that at the moment we should tag what we are sure it is present, and then the rendering will try to draw it. If something is not present we simply should not tag it, otherwise the list of things that are not present will be huge (and we see that e.g. with lzb=no used in countries where lzb was never used, and similar). If something may be present but we don't know, IMHO we also should not tag it at all. The motivation is: what should the rendering algorithm do with tags like "lzb=maybe"? We have ways to clarify uncertainties before tagging, e.g. documentation from infrastructure owners.

So yes, for entries that are never entirely in use in the country, I completely agree. (I hope noone wants to use all the tags everywhere..) But we have quite a lot of lzb tracks that are not yet tagged with it and it would be quite inconvenient to not know where one has clearly seen on the ground that there is no lzb. (I'm going to discuss only german systems as I'm convenient with them. And yes, the main tracks are mainly covered, but crossovers and all the other small stuff is a bit more difficult..) And that was quite convenient on the tagging side of view. (and makes rendering potentially a bit more complicated). But that scheme won't work with the ":"-separated list as in train_protection. --bjoern_m (talk) 20:50, 25 March 2023 (UTC)

Regarding the use: Do we know who else uses those tags (e.g. for rendering). If it's only ORM it should be all fine. If not, maybe one has to tlak to them not that their pipelines crash.. --bjoern_m (talk) 20:50, 25 March 2023 (UTC)

basic train stop systems

wikipedia:Train stop

Since these systems are fairly simple, by just fully stopping a train passing a signal at danger or driving too fast in a speed restricted area (meaning: no acknowledgement buttons, vehicle side speed checks, etc.), I'd suggest to tag mechanical train stops with "tripcock" and inductive/magnetic train stops with "ATS" (i.e Automatic Train Stop) --Rokolell (talk) 01:27, 23 August 2024 (UTC)

Separate out grade of automation from CBTC/train protection in general

Currently the CBTC tag can also specify the Grade of Automation with the values uto for GoA 4, dto for GoA 3 and sto for GoA 2. However other train systems that don't even have any train protection might also have a grade of automation. As such, it might make sense to move the grade of automation to a separate tag. --Freaktechnik (talk) 20:03, 14 May 2023 (UTC)

The better summary is GoA1 manually doesn't need CBTC (it will still have other protection). ATO/STO doesn't exactly require CBTC per se, as it's unclear what CBTC includes. Inductive loops has been used before wireless radios, and those were sometimes termed TBTC (Transmission, or Track circuit) in the past. Blocks are another independent aspects, which can be fixed block(, virtual fixed block), or moving block.
In the name, CBTC's "Train Control" shows it's more than railway:train_protection=* . They need more differentiation.
—— Kovposch (talk) 05:57, 28 November 2024 (UTC)

Is there already a proposal for it? For me it would make sense to be introduced independly of this proposal, even if we completely stick to the current train protection tagging Bauer33333 (talk) 22:50, 5 December 2023 (UTC)

Train protection systems fixes.

It should be listed as UK:AWS and not UK:ATC becuase the Great Western Railway had a safety system called ATC which is different from the British rail AWS and therefore it should be UK:AWS, also the British Rail AWS is not an ATC system. Also It should include London Underground Train stops as a safety system becuase London overground and Chiltern railways uses them on the Watford DC Line between Kilburn High Road and Harrow & Wealdstone and between Harrow-on-the-hill and Amersham. It is missing RETB which is used on the West Highland Line, Kyle line and Far North Line. A Trainspotter From Berkshire (talk) 11:21, 13 June 2023 (UTC)

Furthermore, it should be railway:train_protection=GB:* , not railway:train_protection=UK:*
—— Kovposch (talk) 06:13, 28 November 2024 (UTC)

seperating the specification in a seperate key

I'm not sure if having an entire new value for every specification is the right approach. Eg. looking at the Russian ALS there are 7 different values to check if you just want to know if a track has ALS. Doing this for every value bloats stuff up quite a bit, especially since you usually don't need the type. Eg. ORM renders all ETCS level the same.

Looking at ETCS there is an other issue. If we allow dropping both the country code and the specification a xy:xy value could either be country:protection_system or protection_system:specification. No way for a data user to tell once we get a worldwide system(s) with two letters. And even if not, needing to check if someone added an (previously unused) ISO code or introduced a new train protection system is a struggle we don't need.

I suggest putting the specification in a seperate value similiar to ETCS currently. As example a track with RU:ALS:O and ETCS level 2 would be tagged: railway:train_protection=RU:ALS;ETCS railway:train_protection:RU:ALS=O railway:train_protection:ETCS=2

If you don't know a specification you can just leave the seperate tag away without any effect on the content of the first key.

This is still a really valid concern. I'm for a separate specification key like railway:train_protection:ETCS=1;2 too. --Rokolell (talk) 17:58, 30 October 2024 (UTC)

US values need help

The values for the US don't make a lot of sense right now (either in some of the existing tagging or in this proposal, which seems to pick up on several theoretical brainfarts such as early ETMS while ignoring the fact that PTC is a performance standard for systems to meet, not a system unto itself). Setting metro systems (tripcocks, analog ATO, CBTC) aside for now save for PATH, which we'll get to, we can look at US train protection systems as subtypes of wikipedia:Positive Train Control as the legacy systems (intermittent inductive trainstops, analog pulse coded cab signaling with trainstop support) are all but gone from the mainline network save for the latter being the basis for some forms of PTC. With this in mind, we can reorganize the train protection values for the various PTC systems generally used in the US per the following table:

US PTC train protection values

Type of system	Train protection value	Wiki link/explanation	Where found
Cab Signal Augmentation	US:PTC:ACSES	wikipedia:Advanced Civil Speed Enforcement System	US Northeast Corridor, with most commuter networks attached to the NEC also using it or a variation thereof. (The wikipedia:Long Island Rail Road uses a variant system called Automatic Speed Control that is sort-of-cross-compatible with ACSES, for instance.)
	US:PTC:E-ATC	Enhanced Automatic Train Control	a few commuter systems, such as the wikipedia:WES Commuter Rail in Portland, OR
Radio Overlay	US:PTC:I-ETMS	the Interoperable Electronic Train Management System (although for some reason Wikipedia seems loathe to talk about it)	almost everywhere freight runs on PTC-equipped territory, including all territory that has been fitted with PTC by the Class I's
	US:PTC:ITCS	Incremental Train Control System	Amtrak Michigan Line only. (the Chicago-to-St. Louis corridor in Illinois is fitted with some ITCS equipment under the name X-ITCS, but this is only for grade crossing activation -- the actual train protection heavy lifting on that corridor is done using I-ETMS.)

We can add the special value of "US:PTC:CBTC" to this to denote that a "mainline" railway (i.e. one that falls under the jurisdiction of the Federal Railroad Administration) is using a train protection and control system that conforms to the IEEE 1474 wikipedia:CBTC standard. This value is only necessary to support PATH, and shouldn't be present anywhere else. (Other CBTC implementations should just be "CBTC" or "CBTC:".)

--UrbanUnPlanner (talk) 03:24, 10 May 2024 (UTC)

Is the E-ATC tag you propose here a replacement for the currently widely used railway:atc tag in the US, or is that an other system? It probably isn't the same as the Scandinavian and Portugiese railway:atc--Bauer33333 (talk) 17:00, 18 November 2024 (UTC)

Alternatives for arguement on absence and generality

Proposal:Railway:train_protection#Rationale why not have railway:train_protection=* *=yes / *=no , alongside railway:train_protection:*:*=* suffixes? Furthermore, payment:*=* has a special meta *:others=* to show completion. Personally prefer to avoid semicolon multivals.
—— Kovposch (talk) 10:01, 20 April 2024 (UTC)

Styling and mixing types

It's not needed to uppercase railway:train_protection=tripcock and railway:train_protection=FR:crocodile etc. This gives a false impression that they are abbreviations. There's already railway:train_protection=CH:Integra_Signum for the format.
A specific problem is railway:train_protection=FR:crocodile being country-prefixed. It's already mentioned to be used in multiple countries.
railway:train_protection=VND:* is similarly confusing, a random invented code. I also don't understand how it's supposed to use. Clearly, the instruction "For EBICAB 500 use PZB and for EBICAB 2000 ETCS " shows they orthogonal, mixing different aspects. They should co-exist somehow. You have the opposite situation with PTC, where the implementation is used instead of railway:train_protection=US:PTC .
Personally, I don't like mixing categories, standards, and named systems. ATS, tripcock, CBTC; ETCS, PTCS; and specific systems. An obvious disadvantage of not accommodating PTC is new implementations needs to be supported before their level is understood.

• Ideas
  • railway:train_protection=* : Reserved for the most generic systems
  • railway:train_protection:brand=* : Implementations
  • railway:train_protection:standard=* : National, and international standards
• Examples
  • EBICab 500
    • railway:train_protection:brand=Bombardier:EBICab
    • railway:train_protection:brand:Bombardier:EBICab=2000
    • railway:train_protection:standard=ETCS (It would be fine to use railway:train_protection:standard=EU:ETCS to say ETCS is from EU)
  • ACSES
    • railway:train_protection:brand=Alstom:ACSES
    • railway:train_protection:standard=US:PTC

—— Kovposch (talk) 06:28, 28 November 2024 (UTC)