[openrailwaymap] Proposal for new Ks signal tagging scheme

[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



-- 
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)



-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openrailwaymap.org/archives/openrailwaymap/attachments/20150728/9ff30687/attachment.sig>