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)
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:zsi90tags 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)
- 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
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)
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)
- 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)
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
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)
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)
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;2too. --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:
| 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)