Hello Peter and others,

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.

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.

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.

Combined signals:

You may be right that the function of a combined signal is the same as a main and a distant signal. Even though I see the following problems:

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. There might even be a signal system where combined and main/distant on the same pole are both valid signals. 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.
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)
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.
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:*=*

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. In different signalling systems marker/additional lights might be used for different functions.

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.

And why is it railway:signal:marker_light and not railway:signal:distant/main:marker_light like with every other signal tag?

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

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.

BTW: many railway mappers probably don't know that there are hp signals that can not show hp0 (meaning stop).

Use ds and dv namespace instead of db and dr, as DB and DR no longer exists

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.

This could have done together with the DE-ESO mechanic edit, but I think when (German railway) mappers agree on this, it shouldn't be too difficult to have another mechanical edit. These are also keys that are probably not used by a lot of applications yet (if any), so changing it now is much easier than changing it later.

Tagging of the signal ref

This might be an interesting information. Even though i think that ref=* should be the ref as it is shown at the signal. I'm also against using German keys, for me it wouldn't even be obvious what "kennzahl" means. My alternative proposal:

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

I don't insist on these keys, so if anybody has a better idea for the keys instead of "area_code" and "signal", go ahead.

railway:signal:speed_signal

I don't like to separate zs3 and lf7 to separate keys.

First it's not obvious when to use speed_signal and when speed_limit, so mappers get confused.
If somebody wants to count all speed signals, you need to check for speed_signal and speed_limit
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.

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.

Anyway, I don't think it's a good idea to use railway:signal:position instead of railway:position as we also don't tag railway:milestone:position or railway:crossing:position. So as railway:signal:position is already used nobody should get the idea to use railway:signal:position for the longitudinal position.

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.

Happy (railway) mapping!

Steffen

On 2 August 2015 at 20:56, PeterDRS <mail@wp10771142.server-he.de> wrote:

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.

_______________________________________________
Openrailwaymap mailing list
Openrailwaymap@openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap