[openrailwaymap] Proposal for new Ks signal tagging scheme

[PeterDRS]

Hello,

Rolf Eike Beer <eike at ...> 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