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

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

Hello,

Rolf Eike Beer <eike@...> writes:

Just as a preface: I'm not really a railway person. I just have read RL301

and

do some tagging. But I'm an IT guy. I do specs and API designs for a living, so I would say I have quite some experience with this. Additionally I have experience with software internationalization and localization. And that is the viewport from what I will mainly answer this proposal.

The problem is that reading the Ril 301 is not everything. In Ril 301 there are no information about how the signal box works or what is to be done to allow a train to drive (train protection).

...

Advantages:

• When not knowing whether a signal is main or combined, it stays flexible

to change it later. Nowadays, you have to delete all "combined" tags and make "main" tags an vice versa

Of course, everything will work with tools that can do that. But you won't tag a restaurant with cafe as "restaurant_with_cafe", but "restaurant" + "cafe". And if it has a toilet, you will tag "restaurant:toilet=yes" or "toilet=yes" and not "restaurant_with_cafe_and_toilet".

Same with combined signals. They are just main+distant.

If I look at the signal, there is actually one signal.

That's what you see, but that is not the functional side of the train protection process.

Signals are, as the name says, an information (signal) to the train driver. It shows him something. But it is not the device that controls the track and switches. That does the signal box.

If I tag it as combined I get 3 possible states: hp0, ks1, and ks2. So the tagging must be: main: hp0;ks1;off distant: hp2;off

OSM/ORM is not a signal box.

The tagged states do not mean that only they can be shown and only in this way.

Opening hours are tagged as: opening_hours=Mo-Fr 7:00-16:00, and not ...;closed.

Or, if there is a cleaning in between:

opening_hours: Mo 7:00-12:00;cleaning;lunch;Mo 13:00-16:00;closed

So why tagging "off"?

OSM does not represent anything where one can "read" what a signal can show.

It is a database storing important and unique information. It stays unique to tag Hp0;Ks1.

For any other combination of states we would immediately get situations where both the main as well as the distant aspect are active (ks1+ks2 or things

like

that). Now you only have to tell everyone that the distant aspect must be off if the main is not off, and vice versa. One could say "this is always the

case

for signal type DE-ESO:ks", well, ok. But for DE-ESO:hp with main and distant at the same place you have a different (but much more logical) rule: if the main aspect allows passing, the distant aspect is active. If the main aspect is hp0 (i.e. stop), the distant aspect is off. This is logical, since you do not care what the next signals says if you must not pass this one.

The distant aspect in H/V is not always active when the main aspect is active.

If a signal is intermediate and exit depending on the route the distant stays off.

Let's do it entirely another way: the German signalling system does not allow combined and distant signals at the same position. What happens if any other signalling system allows this (regardless what the meaning of the distant aspect in that case would be)? You can't tag 2 distant aspects without inventing a really weird tagging there.

Combined and distant at one place is against all logic. Because combined IS a distant integrated in one device (together with the main).

Or, like above: What if someone tags restaurant_with_cafe and cafe on one node?

There is main+distant signal in Germany at the same pole: H/V light signals. But those are actually 2 different signals. Everyone can see this. A combined signal is one signal.

Not only H/V light. Also H/V semaphore.

The combined is just a simplification in PRESENTATION. It stays main+distant. That's what the "Mastschild" shows.

...

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 tagging says that both hp0 and ks2 are shown at the same time.

See above. The tagging does not "show" anything, OSM is a database, not a signal box or simulator.

...

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

As Michael already said: this is entirely specific to Germany, even if you

give

it an English name. Let's say Poland would let the yellow light blink in the same situation. This would give railway:signal:yellow_blink=yes then? And

what

if yellow blinking light is an entirely different state in Russia? Then you would tag yellow_blink=yes again, and one needs to guess which meaning it has (there are situations where one countries signalling system goes beyond the border for a while). That's why one tags the primary meaning of that things, or a unique thing in states. DE-ESO:kennlicht is unique, and one can easily find out the meaning, as there is only one. marker_light can be different in every signalling system that exists, and it would create more tags that would probably only used in one system. If you want to have a look at such an epic desaster: the tagging for the differnt materials at a recycling point is a

pile

of yes/no tags, which should have been a simple list instead IMHO.

A marker light is a marker light, even in Poland. It is a light that "marks" the signal.

WHY it is marked is not said. It stays flexible.

...

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.

This makes sense, but I fear that it is already too late for this. The other tagging is already out in the wild, and it will be hard to fix this up. There are still new nodes tagged with amenity=fire_hydrant popping up in the database, even if emergency=fire_hydrant is the preferred tagging for years.

It is never too late and with JOSM presets it should work fine.

...

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.

A simple regular expression allows the opposite already: ([0-9]+ ?)([^ ].*). Probably limited to Ks-Signals, as others are not controlled from ESTW.

The Kennzahl is a number between "00" and "99".

Block signals can have 2-3 numbers in ESTW areas.

What is the signal 525? Kennzahl: 5 Signal: 25

And 16183? Kennzahl: 16 Signal: 183

And 1812? Kennzahl: 18 Signal: 12 or Kennzahl: 1 Signal 812

So it is needed. And it is better to filter all signals with a specific Kennzahl.

...

As signals have positions, meaning a km (example: km 18.543) the tag railway:signal:position=18.543 should be used.

The wiki suggest it should be "distance" without any prefix. No idea why ORM does not use this.

...

The "Standort" should be tagged as railway:signal:location=left/right/bridge

The direction should be tagged as railway:signal:direction=nominal/reverse regarding to the OSM way.

This is just renaming without any added value, so you are too late for this. Same as the DR/DB-prefix renaming.

Rename position to location means to have position take the posibility to carry the information about position in longitudinal, not lateral way.

PeterDRS

Hallo Pete,

Peter Reinhart <pr-newsletter@...> writes:

after thinking quite a bit about your proposal, I am not convinved to transform Ks combined signals to Ks main signals with Ks distant signals attached.

While applications making use of main signals need to be able to handle combined signals as well, there are some applications (such as the OpenRailwayMap) that would need to recombine single-node Ks main and distant signals to a combined signal.

That is not an argument FOR combined tagging.

Look at this pull request https://github.com/rurseekatze/OpenRailwayMap/pull/265 that would "fix up" rendering.

Example:

node|z14-["railway"="signal"]["railway:signal:main"="DE-ESO:ks"] ["railway:signal:distant"="DE-ESO:ks"]

No other thing easier than this.

I just wait for a big argument AGAINST my proposal, whereas I have a big argument FOR my proposal, namely the easiness of clean distinguishing main and distant FUNCTION of a signal.

In reality there are 2 "Mastschilder" at a combined signal: The one for main and the yellow triangle.

Do you think that is for fun? No, that makes clear: This signal is a combination of 2 signals showing only one (compiled) state.

Look at the station Priestewitz with the example tagging.

And here is the used JOSM preset for that:

<item type="node" icon="de-ks-combined-32.png" name="Ks-Signal (Vor-/Haupt-/Kombinationssignal)">

<label text="Ks-Signal (Signal nach dem Ks-Signalsystem)"/>

<key key="railway" value="signal"/> <key key="railway:signal" value="DE-ESO:ks"/>

<combo values="right,left,bridge" display_values="Rechts,Links,Signalbrücke oder Ausleger" text="Standort (in Bezug auf OSM-Wegrichtung)" key="railway:signal:location" default="right"/> <combo values="nominal,reverse" display_values="Nominal,Reverse" text="Richtung (in Bezug auf OSM-Wegrichtung)" key="railway:signal:direction" default="nominal"/>

<check text="Hauptsignalfunktion (Signalzustände siehe unten)" key="railway:signal:main" value_on="DE-ESO:ks" value_off=""/> <check text="Vorsignalfunktion (Signalzustände Ks 1 und Ks 2 vorhanden)" key="railway:signal:distant" value_on="DE-ESO:ks" value_off=""/>

<check text="Bei Hauptsignalfunktion: Signal kann Ks 1 zeigen" key="railway:signal:main:states" value_on="DE-ESO:hp0;DE-ESO:ks1" value_off="DE-ESO:hp0"/>

<check text="Bei Vorsignalfunktion: Signal kann Ks 1 zeigen" key="railway:signal:distant:states" value_on="DE-ESO:ks1;DE-ESO:ks2" value_off="DE-ESO:ks2"/>

<combo text="Bei Vorsignalfunktion: Angaben zum Bremswegabstand/Vorsignalwiederholer" key="railway:signal:distant:additional_light"> <list_entry value="shortened" display_value="Weißes Zusatzlicht oben (verkürzter Bremswegabstand)"/> <list_entry value="repeater" display_value="Weißes Zusatzlicht unten (Vorsignalwiederholer) - nur am reinen Vorsignal"/> </combo>

<combo text="Nur alleinstehendes Vorsignal - kein Vorsignalwiederholer: Anzahl der Vorsignalbaken. Leer wenn keine vorhanden" key="railway:signal:distant:daymarks" values="5,4,3,2,1" default=""/>

<check text="Gegengleisanzeiger (Zs 6/Zs 8) vorhanden" key="railway:signal:wrong_road" value_on="DE-ESO:zs6" value_off=""/> <combo text="Gegengleisanzeiger (Zs 6/Zs 8) Typ (leer wenn nicht vorhanden)" key="railway:signal:wrong_road:form" values="light,form" display_values="Lichtsignal (Nutzung als Zs 8 möglich),Formsignal"/>

<combo text="Fahrt mit besonderem Auftrag (Zs 8 nur über Gegengleisanzeiger, siehe oben)" key="railway:signal:main:substitute_signal" values="DE-ESO:zs1,DE-ESO:zs7" display_values="Ersatzsignal (Zs 1),Vorsichtsignal (Zs 7)"/>

<combo text="Lichtsignal für Rangierfahrten" key="railway:signal:minor" default=""> <list_entry value="DE-ESO:ds:sh1" display_value="Sh 1 (Licht) (DS 301) (2 weiße Lichter nach rechts steigend)"/> <list_entry value="DE-ESO:dv:ra12" display_value="Ra 12 (DV 301) (2 weiße Lichter nach rechts steigend)"/> </combo>

<multiselect text="Betriebliche Funktion (nur bei Hauptsignalfunktion)" key="railway:signal:main:function"> <list_entry value="entry" display_value="Einfahrsignal"/> <list_entry value="exit" display_value="Ausfahrsignal"/> <list_entry value="intermediate" display_value="Zwischensignal"/> <list_entry value="entry;exit" display_value="Ein- und/oder Ausfahrsignal (je nach Fahrstraße)"/> <list_entry value="intermediate;exit" display_value="Zwischen-/Ausfahrsignal (je nach Fahrstraße)"/> <list_entry value="destination" display_value="Zielsignal"/> <list_entry value="block" display_value="Blocksignal"/> <list_entry value="automaticblock" display_value="Selbstblocksignal/Automatikblocksignal"/> </multiselect>

<check text="Signal betrieblich abschaltbar (Kennlicht)" key="railway:signal:marker_light"/>

<check text="Signal Ne 14 (ETCS Halt-Tafel) vorhanden" key="railway:signal:main:stop_marker" value_on="DE-ESO:ne14"/>

<check text="Signal Zs 13 (Stumpfgleis- und Frühhaltanzeiger) vorhanden" key="railway:signal:short_route" value="DE-ESO:zs13"/> <check text="Signal Zs 13 (Stumpfgleis- und Frühhaltanzeiger) als Lichtsignal (sonst Formsignal)" key="railway:signal:short_route:form" value_on="light" value_off="sign"/>

<text key="ref:kennzahl" text="ESTW-Kennzahl"/> <text key="ref" text="Signalbezeichnung (ohne Kennzahl)"/>

<check text="Tiefstehend (sonst hochstehend)" key="railway:signal:height" value_on="dwarf" value_off=""/>

<preset_link preset_name="Zs 2 - Richtungsanzeiger"/> <preset_link preset_name="Zs 2v - Richtungsvoranzeiger"/> <preset_link preset_name="Zs 3 - Geschwindigkeitsanzeiger"/> <preset_link preset_name="Zs 3v - Geschwindigkeitsvoranzeiger"/> <preset_link preset_name="Zp 9/Zp 10 - Abfahrtssignal" />

</item>

That would speed up tagging by miles without losing flexibiliy.

mapper999 <osm.mapper999@...> writes:

I also thought about your proposals and looked at Priestewitz station.

Some of your ideas seem reasonable, some are just a bit too late, others seem to be very German/Deutsche Bahn centric and not internationally compatible.

To say that some ideas are too late would mean that nearly 99% of all German signals are mapped.

The reality is that 1% of alls signals are mapped, so it is a good time to change things in this early (!) state.

I have the feeling that your tagging scheme is not really thought through

and not always consistent. Most of your tagging changes I found in Priestewitz did not come up, yet, so I leave it to you to start the discussion about them and only discuss the things you already brought up.

I just wrote the JOSM preset from scratch, I admit I have not meantioned all changes yet.

BTW: Most of my knowledge about signals are from the internet and

"learning by mapping". This is probably the case for many railway mappers. And I think it is more important that these people understand the tagging scheme than having the correct technical terms.

That's ok but if the OSM database should be "good" it is neccessary to change "bad" mapping to technical correct mapping.

The focus of mapping in past was graphics in my opinion, but it is time to do a change to functionality. The graphics fraction can extract all information from a well-formed functional mapping, but the other way is more difficult.

As an application it is always easier to separate a combined signal, than

merging a main and distant signal without knowing anything of the signal system.

I think the other way round is easier. Merging means adding main and distant. When seperating, how to know what belongs to what?

There might even be a signal system where combined and main/distant on the

same pole are both valid signals.

That's absolutely out of logic. That would mean 2 main aspects on one node. That's not possible.

So we would need a key which tells the application whether the signal is

combined into one or if it is separated into main and distant.

Why is that important. When rendering the renderer has to know the signal system. When only using the logic information it is not neccessary.

There might be states of a combined signal that can't be separated into a

main and a distant state (see e.g. German Hl signals)

That's not true. All states can be divided into main and distant, although they might be redundant.

It is a difference if a signal shows Hl10 just as a distant signal or if it is also a main signal showing Hl10 meaning: Here driving, next stopping. Why not tagging: railway:signal:main:states:DE-ESO:Hl1;DE-ESO:Hl10 railway:signal:distant:states:DE-ESO:Hl10

BTW: HL signal system is not contained in German ESO. ;) Only in DV 301!

I'm not convinced your combined josm preset is really that much easier

than the current preset. It might lead to people tagging invalid combinations of e.g. main signals with tags that belong to distant signals.

It saves time as you need only 2 clicks where now you need 20-30 clicks.

Most of your arguments are just about the comfort of tagging and

applications. Most of these can be solved on the software site. BTW I often tag without presets, so for me it's much easier to type only railway:signal:combined:*=*, compared to railway:signal:main:*=* and railway:signal:distant:*=*

A weak argument, because tagging without preset is not neccessary and why should there be support for people who do not want to use presets.

railway:signal:marker_light,

railway:signal:distant:additional_light=shortened/repeater

I think here it makes more sense to tag the meaning of the signal and not

how it is shown.

OSM is not the right place to describe a signal system.

So why mapping to a node: railway:signal:system="In German signal system, a marker light means ... At this node, the marker light means ..."

As a consequence you would have to tag on every node a maschine readable description.

A post box is not tagged as: post_box:operator=Deutsche Post AG post_box:color=yellow /* Every post box of Deutsche Post is yellow */ post_box:Schlitz=yes /* Every post box has a Schlitz */ post_box:to_send_mail=open_Schlitz /* That's how to use a post box */ post_box:description=This is a post box where you can send your mail. /* Description of a post box */

Same with Ks signals: railway:signal:main=DE-ESO:ks railway:signal:main:form=light /* Every Ks signal is a light signal */ railway:signal:additional_light=shortened /* An additional_light means shortened */ railway:signal:additional_light:color=white /* In Germany it is a white light */ railway:signal:how_to_drive=Wait for Ks 1 and then go ahead /* How to use the signal */ railway:signal:description=This is a Ks signal. It is always a light signal. It shows Hp 0 or Ks 1. You may drive when it shows Ks 1.

I hope it is clear what I mean: Why using tags to DESCRIBE a signal system? That would be a huge redundancy when tagging the same thing to every node.

If someone invents a semaphore combined signal (System Ks+) it is possible to tag railway:signal:main=DE-ESO:ks_plus railway:signal:main:form=semaphore

There is no need to tag light when declaring it as default.

In different signalling systems marker/additional lights might be used for

different functions.

The function is not tagged in this case.

How do you distinguish between a marker and an additional light? For me

they look the same and on German vr distant signals they are even at the same position.

In that case by using the value "yes" or trying to determine the function.

And why is it railway:signal:marker_light and not

railway:signal:distant/main:marker_light like with every other signal tag?

Because a marker light should only be used as tag to declare a signal as being able to be disabled. Then it is independent of the function.

A distant signal at the position of a main signal is not disabled by marker light, it just stays completely off.

BTW: I found the railway:signal:marker_light tag really confusing and at

my first signals I tagged railway:signal:marker_light=yes at every vr signal that had a marker light regardless of its function (repeater mostly).

It is ok, when optimizing it you can think where the light is for (it is unique in most cases).

Don't tag states that every signal can show Very bad idea. How can you be sure that nobody is gonna come and change

the rules, so that a special signal can not show this state? There might even be some special case where this already happens.

When someone changes the rules the tagging scheme must be changed. I don't think that OSM should invent new rules, it should implement the rules that exist.

BTW: many railway mappers probably don't know that there are hp signals

that can not show hp0 (meaning stop).

I even don't know this too. ;)

I only know the case that a Hp signal is not needed any longer and until it is removed it is mechanically fixated at this state.

This sounds reasonable. Actually I was quite confused when I tried to look

up the meaning/appearence of a signal on wikipedia, I only found the abbreviations ds and dv and didn't know which one was which.

Although this is just naming it is quite important.

ref = 16P3 ref:area_code = 16 ref:signal = P3

I have a problem with redundancy.

What if someone tags: ref=18P4 ref:area_code=16 ref:signal=A

Why supporting this?

area_code is a good name for "Kennzahl".

I started building relations for all things a signal box manages: - switches - signals - tracks

Look at Priestewitz or Dresden-Neustadt to know what I mean. That could support seeing that a Kennzahl is wrongly tagged. Or to automatically extract all signals belonging to a specific signal box.

railway:signal:speed_signal I don't like to separate zs3 and lf7 to separate keys.

As long as on a specific geographic position a node can only exist once it seems neccessary.

First it's not obvious when to use speed_signal and when speed_limit, so

mappers get confused.

speed_signal: Can be dynamic (light) speed_limit: Only static (form), only for the main track line (not sidings!), only the highest possible speed (not for different ways over switches).

In Germany that is where nice to see by dividing into Lf7 and Zs3. In other countries it may be different, but the principle is international the same.

Lf7 and Zs3 can be comined, look in Meißen or Tharandt.

If somebody wants to count all speed signals, you need to check for

speed_signal and speed_limit

Merging things is easier than dividing, because dividing is not unique, while merging is.

This doesn't solve the problem you are trying to solve. There might still

be several same speed signals on one position, e.g. often found for tram signals.

Tram is not my area. If it doesn't collide with tram mapping it is not my problem. In Germany it is not possible to have two Lf7 or two Zs3 on the same node in the same direction.

Do not try to construct things that are out of any logic! ;)

railway:signal:location Even though I think that location is better than position, this is just

rewording and is not necessary. This should have been done when the tagging scheme was developed, but now you would need to do an international mechanical edit of currently about 30.000 elements. This might also affect quite a few applications.

It is not consequent to use position for longitudinal and lateral in the same database.

railway:position is longitudinal and railway:signal:position is lateral

That's not a good idea.

railway:signal:direction I think we should stay with forward and backward as these are common OSM

values and if we ever get editor support for changing forward/backward when reversing a way, this will be for forward/backward and not nominal/reverse. Forward/backward are also easier to remember than nominal/reverse.

Ok that's just a naming thing.

But it can prevent people being confused thinking that a train drives to the back controlled from the front ("geschobene Rangierfahrt").