[openrailwaymap] Proposal for new Ks signal tagging scheme

[Rolf Eike Beer]

Am Montag, 27. Juli 2015, 18:38:17 schrieb Peter Hudec:
> Proposal for new tagging scheme for Ks signals

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.

> 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.
> Nowadays, you have to delete all "combined" tags and make "main" tags an
> vice versa

This is just about the tooling, it has little to do with the usefulness of the 
tagging itself as long as the tagging could be made working. I assume it can, 
so if the tooling is broken, then fix the tooling, not the tagging.

> - No need to have 2 (main + combined) namespaces with all the properties of
> signals
> - No need to maintain 2 JOSM preset items
> - Possibility to filter all main aspect signals, no matter whether they are
> "combined" signals or "normal" main signals

If I look at the signal, there is actually one signal. 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
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.

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.

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.

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

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

> That neutral to main or distant.
> 
> 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
> 
> 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.

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

> railway:signal:speed_signal:speed=60

This is already a badly chosen name IMHO: it should have been states right 
from the start. Even if it is a sign and can only show one state, but that 
case can easily be catched.

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

Greetings,

Eike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150728/6bfce6ec/attachment.sig>