11:42 p.m.
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(a)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(a)openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap