Hello Peter and others,
thank you for your proposal. Despite that I welcome new ideas, I cannot judge yours. The Dutch situation simply does not have abbreviations like Hp0.
In the case you are interested in the Dutch signals, here's a summary. If described with the direction of driving, our signals behave like: green, yellow, red, train, green, etc. All signals are able to display all three colours and main/distant signals are not distinguished. Most of the signals are working purely on train detection, but some signals can be kept red or yellow by the 13 so called traffic control command centres.
Kind regards, Jeroen
Op 28 jul. 2015 om 23:00 heeft Christian Wendel mail@christianwendel.de het volgende geschreven:
Hi Peter, Michael, these are a lot of proposals. Mostly, I am not convinced of their advantage. (Think of me as a heavy Joe Average-Mapper)
But the point to merge combined with main signal types could work. Why? In fact, any combined signal can be tagged as a main signal also showing Ks2. But tagging would be lots easier as described. It's lot of work to change signals from "main" to "combined", if the distant state had missed. I hate this kind of work.
On the other hand, there a lots of more annoying definitions in OSM tagging. The current railway tagging works well in most of the cases, even if many functions are combined on one signal.
Christian PS: I try to be polite even when opposing proposals.
Am 28.07.2015 um 20:52 schrieb Michael Reichert: TL;DR I strongly oppose any tagging changes which are
- not backward compatible to existing tagging
- just changes of wording to fit better to professional literature
- make contributing more difficult for people with less or no knowledge
of signalling rules.
Hi Peter,
Am 2015-07-27 um 18:38 schrieb Peter Hudec: Proposal for new tagging scheme for Ks signals
A. Problem
Today there are 3 different signal "types" for tagging:
- distant
- main
- combined
signals.
The only participant in train protection are main and combined signals.
Distant signals do not manage the movement authority. They "just" announce the state of the following main aspect signal.
Combined signals are no special "type" of signal, they just be "intelligent" with showing the signal states.
That means, the aspects of signals can show the following:
- main: Hp0, Ks1
- distant: Ks1, Ks2
When combining two aspects, some states are suppressed:
Main + Distant = Shown state Hp0 + Ks1 = Hp0 Hp0 + Ks2 = Hp0
Ks1 + Ks1 = Ks1 Ks1 + Ks2 = Ks2
B. Solution
It would be much more logical to map both aspects, main and distant, at one node.
Advantages:
- When not knowing whether a signal is main or combined, it stays flexible to
change it later.
Do you know fixme=*? There are even special maps which highlight this tag. If I am not sure if a signal is a main or combined signal (sometimes I just have to look 1000 m ahead if there is the next main/combined signal), I tag it as a main signal and add fixme="may be a combined signal, please check and correct".
Nowadays, you have to delete all "combined" tags and make "main" tags an vice versa
- No need to have 2 (main + combined) namespaces with all the properties of
signals
- No need to maintain 2 JOSM preset items
That's a problem of JOSM's preset structure and should be solved at JOSM's source code. I think that the pain is not hard enough at the moment.
- Possibility to filter all main aspect signals, no matter whether they are
"combined" signals or "normal" main signals
Why don't you change railway=station/halt to railway=passenger_entry_point + passenger_entry_point=station/halt? :-) It's a very similar problem because most customers do not care if the place where they enter the train has a switch or not.
To tag the states I propose to tag a main aspect signal: railway:signal:main=DE-ESO:ks That makes a signal identified as Ks signal, no matter of the states railway:signal:main:states=DE-ESO:hp0 That is what every main aspect signal can show Optional: railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1
Btw, we use semicolons to separate multiple values. That is the common way OSM does. railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1 should not be optional. If you do not know all states a signal can show, you have to use "railway:signal:main:states"="DE-ESO:hp0;?". (question mark as placeholder)
Every distant signal can show DE-ESO:ks2 There is no need to tag this.
Our tagging system is designed to be as international/as portable as possible. That's why some things have to been tagged even if they seem to be obvious in one country. Mandatory tags for each signal are:
- railway=signal (except buffer stops and derailers)
- railway:signal:direction=*
- railway:signal:TYPE=COUNTRY-COMPANY/RULESET:NAME
- railway:signal:TYPE:form=light/sign/semaphore
railway:signal:TYPE:states=COUNTRY-COMPANY/RULESET:NAME1;COUNTRY-COMPANY/RULESET:NAME2 (only light and semaphore signals)
Very recommended but, from my point of view, not mandatory and therefore not enforced by style sheets and validation rules:
- railway:signal:position=left/right/in_track/overhead
It may be look like a waste of storage for you that we tag railway:signal:speed_limit:form=sign for every Lf 7 speed limit signal but the data should be usable with less or without knowledge of the signalling systems.
What about users who want just count the number of semaphore main signals in a country? Following your suggestions, this would not be a problem in Germany because we already and still add railway:signal:main:form=semaphore because both light and semaphore Hp signals are tagged railway:signal:main=DE-ESO:hp. But there are other countries which may have different names for semaphore and light main signals. If they follow your suggestions (because we want to be consistent beyond country borders), this will result in an information loss. Communities of these countries would not tag railway:signal:main:form=* and therefore this query would not return useful information. http://overpass-turbo.eu/s/aCx
It is never a good idea at OSM to change a already heavily used tag. Your proposal conflicts with existing tagging. [1] At the moment the signals you modified in order to match your proposal are rendered wrong by OpenRailwayMap because their tags are wrong. (rendered as Ks distant or main signal although it is a combined signal)
I think that the benefits are not high enough to justify a different tagging of Ks combined signals.
If a distant signal can also show ks1, tag: railway:signal:distant:states=DE-ESO:ks1,DE-ESO:ks2
There are signals before a buffer stop that can only show Hp0 and Ks2.
They would be tagged as follows: railway:signal:main=DE-ESO:ks railway:signal:main:states=DE-ESO:hp0 railway:signal:distant=DE-ESO:ks railway:signal:distant:states=DE-ESO:ks2
This is already possible with the current tagging scheme and has been supported by our JOSM presets for a few days or weeks. railway:signal:combined:states=DE-ESO:hp0;DE-ESO:ks2 It may be a good idea to add a note=* to such signals because the usually get attention by users using data validation tools to prevent questions and disimprovements. ;-)
A marker light should not be tagged as "DE-ESO:kennlicht", as it is not clear if it is a property of main or distant aspect.
I propose to go back to the past with: railway:signal:marker_light=yes
That neutral to main or distant.
This tag was too German-centric. I hope you already read the discussion at the archive of this mailing list.
The minor signal should distinguish between Ra 12 (DV) and Sh 1 (DS).
I propose to tag: railway:signal:minor=DE-ESO:ds:sh1 or railway:signal:minor=DE-ESO:dv:ra12
Why? Just because it has another name in East Germany or because it has different rules? When Alex designed the tagging scheme in 2011/2012, he decided only to use prefixes if the same signal abbrevation has a different appearance or rules in West and East Germany.
Use ds and dv namespace instead of db and dr, as DB and DR no longer exists, DV and DS are the official abbreviations used by DBAG.
When tagging signals that are harmonized in DS and DV = Ril301, DO NOT tag this.
I do not see any benefit of ds and dv over db and dr. db and dr are easier understandable for people who don't know Ril 301 (German signalling rules) by heart. It would only result in a unnecessary mechanical renaming edit without no benefit for data users and most mappers.
Zs6 (Gegengleisanzeiger): railway:signal:wrong_road=DE-ESO:zs6
Specify form: railway:signal:wrong_road:form=sign railway:signal:wrong_road:form=light A light can also be Zs8. NO SPECIAL TAGGING, as it is not needed. Every Zs6 can technically show Zs8. If the signal box can't do it, there is no need to tag this at
the signal.
What you wrote above about Zs 6 only affects Zs 6 signals at Ks signals, doesn't it?
If every Zs 6 can shown Zs 8, it should be tagged as such. Please remember that local defaults should be tagged because they are no global defaults. That's why following tagging is IMHO better:
Zs 6 /light/ signals at Ks signals: railway:signal:wrong_road=DE-ESO:zs6 railway:signal:wrong_road:states=DE-ESO:zs6;DE-ESO:zs8 railway:signal:wrong_road:form=light
Zs 6 /signs/ at all main signals: railway:signal:wrong_road=DE-ESO:zs6 railway:signal:wrong_road:form=sign
Tagging of the signal ref: Distinguish between ESTW-Kennzahl and signal ref. 16P3 = 16 + P3 ref:kennzahl=16 ref=P3
That makes it possible to show only the P3 in special applications. When one needs the 16 he can take it from ref:kennzahl.
I think that this separation should be done by the data users, not by the mappers. Joe Average-Mapper would tag railway=signal + ref=16P3 or railway=signal + ref="16 P3" + no other tags. How do you want to explain him that he has to use ref:kennzahl=16?
We must keep the entrance level for a OSM contributor who already has some editing experience as low as possible. He should be able to enter as much data as possible without using the JOSM presets. There are lots of signals in North Rhine-Westphalia where local mappers (having no knowledge of railway signalling) just added railway=signal + ref=<number> because OSM mappers have been used to add reference numbers as ref=* for many years. (ref=* is the numeric brother of name=* at OSM)
Please note that German keys and values should be avoided as much as possible!
Zs3/Zs3v: Switch over to railway:signal:speed_signal
Advantage: Possibility to tag a Lf7 at the same position
railway:signal:speed_signal=DE-ESO:zs3 railway:signal:speed_signal:speed=60 railway:signal:speed_signal:form=sign/light (default: sign)
At railway:signal:TYPE*=* TYPE is the function, not the appearance. If you really want a differentiation between Lf 7 and Lf 6 (distant signal of Lf 7) vs. Zs 3 and Zs 3v (distant signal of Zs 3), you have to differentiate these signals by their a scope of application.
Example (for non-Germans and people with less knowledge about signalling) showing the exit of a simple station, train runs to the right:
-D--P1-----+1-----E----- ----P2----/
P1: main exit signal P2: main exit signal + speed limit signal Zs 3 showing digit "5" D: Lf 7 speed limit signal showing digit "8" E: Lf 7 speed limit signal showing digit "9"
Speed limit signal at P2 is only valid until the last axle of the train has passed swich 1. Speed limit signal D is valid until E (or another speed limit is indicated in the timetable.
If the example is between Augsburg and Donauwörth, Zs 3 at P2 is valid until E and therefore has the same function as an Lf 7 (just a different location where it is mounted). (Augsburg–Donauwörth has special signalling rules) That's why I oppose a differentiation between Zs 3 and Lf 7 at the used OSM key. How do you explain a railway fan who started contributing that he has to tag Zs 3 at Mering station railway:signal:speed_on_switch=DE-ESO:zs3 and at Gablingen station railway:signal:speed_limit=DE-ESO:zs3? http://www.openrailwaymap.org/?lang=de&lat=48.362864571600966&lon=10...
We should keep our tagging system as easy as possible but also as powerful as possible. Sometimes you need tweaks and dirty hacks at OSM. Mapping POIs sometimes as nodes and sometimes as areas is an example.
As signals have positions, meaning a km (example: km 18.543) the tag railway:signal:position=18.543 should be used.
We already have railway:position:exact=* which can be tagged to every node of a track. Why not use this tag?
The "Standort" should be tagged as railway:signal:location=left/right/bridge
Why do you want to change railway:signal:position=* to railway:signal:location=*? I do not see any benefit. Just every, EVERY data user has to adapt his software, style sheets and config files just because one guy thinks that "location" sounds nicer!
The direction should be tagged as railway:signal:direction=nominal/reverse regarding to the OSM way.
Why do you want to change railway:signal:position=* to railway:signal:location=*? I do not see any benefits. It just changes the values to words which are used in professional literature. When I read your proposal, some power refinement proposals by user fanfouer are called to my mind. He tries/tried to rename lots of keys and values because the where different to those used in professional literature.
I strongly suggest everyone (not only you, Peter) to read a posting of Andy Allan, maintainer of OSM Carto, about changing tags and consequences of tagging changes. https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-... (I fully agree with that posting)
Best regards
Michael
[1] There are some do-not-does for tagging proposals
- read tagging discussions at least a few months before you try to
invent great changes or lots of new tags – it will benefit YOU
- don't try to change existing tagging
- use British English at keys and values
- no spaces (apart from names and reference numbers)
- avoid abbreviations
Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
Openrailwaymap mailing list Openrailwaymap@openrailwaymap.org http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap