[openrailwaymap] Proposal for new Ks signal tagging scheme

[Christian Wendel]

Hi Peter, Michael,
these are a lot of proposals. Mostly, I am not convinced of their 
advantage. (Think of me as a heavy Joe Average-Mapper)

But the point to merge combined with main signal types could work. Why? 
In fact, any combined signal can be tagged as a main signal also showing 
Ks2. But tagging would be lots easier as described. It's lot of work to 
change signals from "main" to "combined", if the distant state had 
missed. I hate this kind of work.

On the other hand, there a lots of more annoying definitions in OSM 
tagging. The current railway tagging works well in most of the cases, 
even if many functions are combined on one signal.

Christian
PS: I try to be polite even when opposing proposals.

Am 28.07.2015 um 20:52 schrieb Michael Reichert:
> TL;DR I strongly oppose any tagging changes which are
> - not backward compatible to existing tagging
> - just changes of wording to fit better to professional literature
> - make contributing more difficult for people with less or no knowledge
> of signalling rules.
>
> Hi Peter,
>
> Am 2015-07-27 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.
> Do you know fixme=*? There are even special maps which highlight this
> tag. If I am not sure if a signal is a main or combined signal
> (sometimes I just have to look 1000 m ahead if there is the next
> main/combined signal), I tag it as a main signal and add
> fixme="may be a combined signal, please check and correct".
>
>> 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
> That's a problem of JOSM's preset structure and should be solved at
> JOSM's source code. I think that the pain is not hard enough at the moment.
>
>> - Possibility to filter all main aspect signals, no matter whether they are
>> "combined" signals or "normal" main signals
> Why don't you change railway=station/halt to
> railway=passenger_entry_point + passenger_entry_point=station/halt? :-)
> It's a very similar problem because most customers do not care if the
> place where they enter the train has a switch or not.
>
>> 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
> Btw, we use semicolons to separate multiple values. That is the common
> way OSM does. railway:signal:main:states=DE-ESO:hp0,DE-ESO:ks1 should
> not be optional. If you do not know all states a signal can show, you
> have to use "railway:signal:main:states"="DE-ESO:hp0;?". (question mark
> as placeholder)
>
>> Every distant signal can show DE-ESO:ks2
>> There is no need to tag this.
> Our tagging system is designed to be as international/as portable as
> possible. That's why some things have to been tagged even if they seem
> to be obvious in one country. Mandatory tags for each signal are:
> - railway=signal (except buffer stops and derailers)
> - railway:signal:direction=*
> - railway:signal:TYPE=COUNTRY-COMPANY/RULESET:NAME
> - railway:signal:TYPE:form=light/sign/semaphore
> -
> railway:signal:TYPE:states=COUNTRY-COMPANY/RULESET:NAME1;COUNTRY-COMPANY/RULESET:NAME2
> (only light and semaphore signals)
>
> Very recommended but, from my point of view, not mandatory and therefore
> not enforced by style sheets and validation rules:
> - railway:signal:position=left/right/in_track/overhead
>
> It may be look like a waste of storage for you that we tag
> railway:signal:speed_limit:form=sign for every Lf 7 speed limit signal
> but the data should be usable with less or without knowledge of the
> signalling systems.
>
> What about users who want just count the number of semaphore main
> signals in a country? Following your suggestions, this would not be a
> problem in Germany because we already and still add
> railway:signal:main:form=semaphore because both light and semaphore Hp
> signals are tagged railway:signal:main=DE-ESO:hp. But there are other
> countries which may have different names for semaphore and light main
> signals. If they follow your suggestions (because we want to be
> consistent beyond country borders), this will result in an information
> loss. Communities of these countries would not tag
> railway:signal:main:form=* and therefore this query would not return
> useful information. http://overpass-turbo.eu/s/aCx
>
> It is never a good idea at OSM to change a already heavily used tag.
> Your proposal conflicts with existing tagging. [1] At the moment the
> signals you modified in order to match your proposal are rendered wrong
> by OpenRailwayMap because their tags are wrong. (rendered as Ks distant
> or main signal although it is a combined signal)
>
> I think that the benefits are not high enough to justify a different
> tagging of Ks combined signals.
>
>> 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
> This is already possible with the current tagging scheme and has been
> supported by our JOSM presets for a few days or weeks.
> railway:signal:combined:states=DE-ESO:hp0;DE-ESO:ks2
> It may be a good idea to add a note=* to such signals because the
> usually get attention by users using data validation tools to prevent
> questions and disimprovements. ;-)
>
>> 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.
> This tag was too German-centric. I hope you already read the discussion
> at the archive of this mailing list.
>
>> 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
> Why? Just because it has another name in East Germany or because it has
> different rules? When Alex designed the tagging scheme in 2011/2012, he
> decided only to use prefixes if the same signal abbrevation has a
> different appearance or rules in West and East Germany.
>
>> 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.
> I do not see any benefit of ds and dv over db and dr. db and dr are
> easier understandable for people who don't know Ril 301 (German
> signalling rules) by heart. It would only result in a unnecessary
> mechanical renaming edit without no benefit for data users and most mappers.
>
>> 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.
> What you wrote above about Zs 6 only affects Zs 6 signals at Ks signals,
> doesn't it?
>
> If every Zs 6 can shown Zs 8, it should be tagged as such. Please
> remember that local defaults should be tagged because they are no global
> defaults. That's why following tagging is IMHO better:
>
> Zs 6 /light/ signals at Ks signals:
> railway:signal:wrong_road=DE-ESO:zs6
> railway:signal:wrong_road:states=DE-ESO:zs6;DE-ESO:zs8
> railway:signal:wrong_road:form=light
>
> Zs 6 /signs/ at all main signals:
> railway:signal:wrong_road=DE-ESO:zs6
> railway:signal:wrong_road:form=sign
>
>> 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.
> I think that this separation should be done by the data users, not by
> the mappers. Joe Average-Mapper would tag railway=signal + ref=16P3 or
> railway=signal + ref="16 P3" + no other tags. How do you want to explain
> him that he has to use ref:kennzahl=16?
>
> We must keep the entrance level for a OSM contributor who already has
> some editing experience as low as possible. He should be able to enter
> as much data as possible without using the JOSM presets. There are lots
> of signals in North Rhine-Westphalia where local mappers (having no
> knowledge of railway signalling) just added railway=signal +
> ref=<number> because OSM mappers have been used to add reference numbers
> as ref=* for many years. (ref=* is the numeric brother of name=* at OSM)
>
> Please note that German keys and values should be avoided as much as
> possible!
>
>> 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)
> At railway:signal:TYPE*=* TYPE is the function, not the appearance. If
> you really want a differentiation between Lf 7 and Lf 6 (distant signal
> of Lf 7) vs. Zs 3 and Zs 3v (distant signal of Zs 3), you have to
> differentiate these signals by their a scope of application.
>
> Example (for non-Germans and people with less knowledge about
> signalling) showing the exit of a simple station, train runs to the right:
>
> -D--P1-----+1-----E-----
> ----P2----/
>
> P1: main exit signal
> P2: main exit signal + speed limit signal Zs 3 showing digit "5"
> D: Lf 7 speed limit signal showing digit "8"
> E: Lf 7 speed limit signal showing digit "9"
>
> Speed limit signal at P2 is only valid until the last axle of the train
> has passed swich 1. Speed limit signal D is valid until E (or another
> speed limit is indicated in the timetable.
>
> If the example is between Augsburg and Donauwörth, Zs 3 at P2 is valid
> until E and therefore has the same function as an Lf 7 (just a different
> location where it is mounted). (Augsburg–Donauwörth has special
> signalling rules) That's why I oppose a differentiation between Zs 3 and
> Lf 7 at the used OSM key. How do you explain a railway fan who started
> contributing that he has to tag Zs 3 at Mering station
> railway:signal:speed_on_switch=DE-ESO:zs3
> and at Gablingen station
> railway:signal:speed_limit=DE-ESO:zs3?
> http://www.openrailwaymap.org/?lang=de&lat=48.362864571600966&lon=10.991992950439453&zoom=12&style=standard
>
> We should keep our tagging system as easy as possible but also as
> powerful as possible. Sometimes you need tweaks and dirty hacks at OSM.
> Mapping POIs sometimes as nodes and sometimes as areas is an example.
>
>> As signals have positions, meaning a km (example: km 18.543) the tag
>> railway:signal:position=18.543
>> should be used.
> We already have railway:position:exact=* which can be tagged to every
> node of a track. Why not use this tag?
>
>> The "Standort" should be tagged as
>> railway:signal:location=left/right/bridge
> Why do you want to change railway:signal:position=* to
> railway:signal:location=*? I do not see any benefit. Just every, EVERY
> data user has to adapt his software, style sheets and config files just
> because one guy thinks that "location" sounds nicer!
>
>> The direction should be tagged as
>> railway:signal:direction=nominal/reverse
>> regarding to the OSM way.
> Why do you want to change railway:signal:position=* to
> railway:signal:location=*? I do not see any benefits. It just changes
> the values to words which are used in professional literature. When I
> read your proposal, some power refinement proposals by user fanfouer are
> called to my mind. He tries/tried to rename lots of keys and values
> because the where different to those used in professional literature.
>
> I strongly suggest everyone (not only you, Peter) to read a posting of
> Andy Allan, maintainer of OSM Carto, about changing tags and
> consequences of tagging changes.
> https://github.com/gravitystorm/openstreetmap-carto/issues/230#issuecomment-29238913
> (I fully agree with that posting)
>
> Best regards
>
> Michael
>
>
> [1] There are some do-not-does for tagging proposals
> - read tagging discussions at least a few months before you try to
> invent great changes or lots of new tags – it will benefit YOU
> - don't try to change existing tagging
> - use British English at keys and values
> - no spaces (apart from names and reference numbers)
> - avoid abbreviations
>
>
>
>
>
> _______________________________________________
> Openrailwaymap mailing list
> Openrailwaymap at openrailwaymap.org
> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap