[openrailwaymap] Proposal for new Ks signal tagging scheme

[PeterDRS]

mapper999 <osm.mapper999 at ...> 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").