This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.

[openrailwaymap] Proposal for new Ks signal tagging scheme

Peter Reinhart pr-newsletter at web.de
Sun Aug 2 18:41:44 MEST 2015


Hi Peter,

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.

Besides, it appears to be a good idea to consider changing DB/DR to the 
official abbreviations of the underlying rules (DS/DV) in the long run.

Also, some guidelines on naming, such as for switches ("63W12", "W12", 
"12 HV", "12" ...) should be taken into consideration, as well as 
introducing a position field to the JOSM presets for signals.

Last but not least, some way to tage multiple signals at the same pole 
at one node (just as it is out there) should be taken on the TODO list 
as well.

Best wishes
Peter



Am 27.07.2015 um 18:38 schrieb Peter Hudec:
> Proposal for new tagging scheme for Ks signals
>
> 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
> - 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
>
> To tag the states I propose to tag a main aspect signal:
> railway:signal:main=DE-ESO:ks
> That makes a signal identified as Ks signal, no matter of the states
> railway:signal:main:states=DE-ESO:hp0
> That is what every main aspect signal can show
> Optional:
> railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1
>
> Every distant signal can show DE-ESO:ks2
> There is no need to tag this.
> If a distant signal can also show ks1, tag:
> railway:signal:distant:states=DE-ESO:ks1,DE-ESO:ks2
>
> 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
>
> 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
>
> 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.
>
> When tagging signals that are harmonized in DS and DV = Ril301, DO NOT tag this.
>
> Zs6 (Gegengleisanzeiger):
> railway:signal:wrong_road=DE-ESO:zs6
>
> Specify form:
> railway:signal:wrong_road:form=sign
> railway:signal:wrong_road:form=light
> A light can also be Zs8. NO SPECIAL TAGGING, as it is not needed. Every Zs6 can
> technically show Zs8. If the signal box can't do it, there is no need to tag
> this at
>
> the signal.
>
> Zs7 (Vorsichtsignal):
> railway:signal:main:substitute_signal=DE-ESO:zs7
>
> 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.
>
> Zs3/Zs3v:
> Switch over to
> railway:signal:speed_signal
>
> Advantage: Possibility to tag a Lf7 at the same position
>
> railway:signal:speed_signal=DE-ESO:zs3
> railway:signal:speed_signal:speed=60
> railway:signal:speed_signal:form=sign/light (default: sign)
>
> As signals have positions, meaning a km (example: km 18.543) the tag
> railway:signal:position=18.543
> should be used.
>
> 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.
>
> I know that at least Nakaner will be against ALL my ideas. But that is no matter
> for me, as long as he has no real arguments beside of saying that the ideas are
> "from me".
>
> Greets
>
> PeterDRS
> _______________________________________________
> Openrailwaymap mailing list
> Openrailwaymap at openrailwaymap.org
> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap



More information about the Openrailwaymap mailing list