6:38 p.m.
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
8:52 p.m.
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...
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#issuecomme...
(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)
11 p.m.
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...
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#issuecomme...
(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(a)openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
11:30 p.m.
Hi Christian,
Am 2015-07-28 um 23:00 schrieb 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.
I agree that changing a signal from a main into a combined signal is not
as comfortable as it could be. The pain was too less to force me to do
something until now. :-)
We have just to add
<check text="Remove railway:signal:main=*"
key="railway:signal:main"
value_on="" />
<check text="Remove railway:signal:main:states=*"
key="railway:signal:main:states" value_on="" />
<check text="Remove railway:signal:main:form=*"
key="railway:signal:main:form" value_on="" />
<check text="Remove railway:signal:main:function=*"
key="railway:signal:main:function" value_on="" />
<check text="Remove railway:signal:main:height=*"
key="railway:signal:main:height" value_on="" />
<check text="Remove railway:signal:main:substitute_signal=*"
key="railway:signal:main:substitute_signal" value_on="" />
to the section of the JOSM preset XML file where the combined Ks signal
is defined. This removes all main signal tags listed above if the users
leaves the preset of a combined signal by clicking onto OK. (In history,
there would have been delete_if_empty="true" necessary, but this
nowadays obsolete)
For usage inside JOSM download this file and load it
https://paste.kde.org/pouyerlpb
Diff: https://paste.kde.org/pufuia181
I decided to use a checkbox which has to be selected manually by the
user in order to prevent accidental deletions. This functionality can be
outsourced into a separate section of the German signal preset, i.e.
below "Zugfunk-Kanalhinweis" because it will not be used very often.
I still think that changing a JOSM preset is easier and goes faster than
doing a mechanical edit with all its consequences and bureaucracy.
Best regards
Michael
--
Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
ausgenommen)
I prefer GPG encryption of emails. (does not apply on mailing lists)
11:36 p.m.
Hello Peter and others,
thank you for your proposal. Despite that I welcome new ideas, I cannot judge yours. The
Dutch situation simply does not have abbreviations like Hp0.
In the case you are interested in the Dutch signals, here's a summary. If described
with the direction of driving, our signals behave like: green, yellow, red, train, green,
etc. All signals are able to display all three colours and main/distant signals are not
distinguished. Most of the signals are working purely on train detection, but some signals
can be kept red or yellow by the 13 so called traffic control command centres.
Kind regards,
Jeroen
Op 28 jul. 2015 om 23:00 heeft Christian Wendel
<mail(a)christianwendel.de> het volgende geschreven:
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...
>
> 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#issuecomme...
> (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(a)openrailwaymap.org
> http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
_______________________________________________
Openrailwaymap mailing list
Openrailwaymap(a)openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
11:31 p.m.
Am Montag, 27. Juli 2015, 18:38:17 schrieb Peter Hudec:
Proposal for new tagging scheme for Ks signals
Just as a preface: I'm not really a railway person. I just have read RL301 and
do some tagging. But I'm an IT guy. I do specs and API designs for a living,
so I would say I have quite some experience with this. Additionally I have
experience with software internationalization and localization. And that is
the viewport from what I will mainly answer this proposal.
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
This is just about the tooling, it has little to do with the usefulness of the
tagging itself as long as the tagging could be made working. I assume it can,
so if the tooling is broken, then fix the tooling, not the tagging.
- 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
If I look at the signal, there is actually one signal. If I tag it as combined
I get 3 possible states: hp0, ks1, and ks2. So the tagging must be:
main: hp0;ks1;off
distant: hp2;off
For any other combination of states we would immediately get situations where
both the main as well as the distant aspect are active (ks1+ks2 or things like
that). Now you only have to tell everyone that the distant aspect must be off
if the main is not off, and vice versa. One could say "this is always the case
for signal type DE-ESO:ks", well, ok. But for DE-ESO:hp with main and distant
at the same place you have a different (but much more logical) rule: if the
main aspect allows passing, the distant aspect is active. If the main aspect
is hp0 (i.e. stop), the distant aspect is off. This is logical, since you do
not care what the next signals says if you must not pass this one.
Let's do it entirely another way: the German signalling system does not allow
combined and distant signals at the same position. What happens if any other
signalling system allows this (regardless what the meaning of the distant
aspect in that case would be)? You can't tag 2 distant aspects without
inventing a really weird tagging there.
There is main+distant signal in Germany at the same pole: H/V light signals.
But those are actually 2 different signals. Everyone can see this. A combined
signal is one signal.
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 tagging says that both hp0 and ks2 are shown at the same time.
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
As Michael already said: this is entirely specific to Germany, even if you give
it an English name. Let's say Poland would let the yellow light blink in the
same situation. This would give railway:signal:yellow_blink=yes then? And what
if yellow blinking light is an entirely different state in Russia? Then you
would tag yellow_blink=yes again, and one needs to guess which meaning it has
(there are situations where one countries signalling system goes beyond the
border for a while). That's why one tags the primary meaning of that things,
or a unique thing in states. DE-ESO:kennlicht is unique, and one can easily
find out the meaning, as there is only one. marker_light can be different in
every signalling system that exists, and it would create more tags that would
probably only used in one system. If you want to have a look at such an epic
desaster: the tagging for the differnt materials at a recycling point is a pile
of yes/no tags, which should have been a simple list instead IMHO.
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.
This makes sense, but I fear that it is already too late for this. The other
tagging is already out in the wild, and it will be hard to fix this up. There
are still new nodes tagged with amenity=fire_hydrant popping up in the
database, even if emergency=fire_hydrant is the preferred tagging for years.
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.
A simple regular expression allows the opposite already: ([0-9]+ ?)([^ ].*).
Probably limited to Ks-Signals, as others are not controlled from ESTW.
railway:signal:speed_signal:speed=60
This is already a badly chosen name IMHO: it should have been states right
from the start. Even if it is a sign and can only show one state, but that
case can easily be catched.
As signals have positions, meaning a km (example: km 18.543) the tag
railway:signal:position=18.543
should be used.
The wiki suggest it should be "distance" without any prefix. No idea why ORM
does not use this.
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.
This is just renaming without any added value, so you are too late for this.
Same as the DR/DB-prefix renaming.
Greetings,
Eike
10:49 a.m.
Hello,
Rolf Eike Beer <eike@...> writes:
Just as a preface: I'm not really a railway person. I just have
read RL301
and
do some tagging. But I'm an IT guy. I do specs and API designs
for a living,
so I would say I have quite some experience with this. Additionally I have
experience with software internationalization and localization. And that is
the viewport from what I will mainly answer this proposal.
The problem is that reading the Ril 301 is not everything. In Ril 301 there
are no information about how the signal box works or what is to be done to
allow a train to drive (train protection).
> 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
Of course, everything will work with tools that can do that.
But you won't tag a restaurant with cafe as "restaurant_with_cafe", but
"restaurant" + "cafe".
And if it has a toilet, you will tag "restaurant:toilet=yes" or
"toilet=yes"
and not "restaurant_with_cafe_and_toilet".
Same with combined signals. They are just main+distant.
If I look at the signal, there is actually one signal.
That's what you see, but that is not the functional side of the train
protection process.
Signals are, as the name says, an information (signal) to the train driver.
It shows him something. But it is not the device that controls the track and
switches. That does the signal box.
If I tag it as combined
I get 3 possible states: hp0, ks1, and ks2. So the tagging must be:
main: hp0;ks1;off
distant: hp2;off
OSM/ORM is not a signal box.
The tagged states do not mean that only they can be shown and only in this way.
Opening hours are tagged as: opening_hours=Mo-Fr 7:00-16:00, and not ...;closed.
Or, if there is a cleaning in between:
opening_hours: Mo 7:00-12:00;cleaning;lunch;Mo 13:00-16:00;closed
So why tagging "off"?
OSM does not represent anything where one can "read" what a signal can show.
It is a database storing important and unique information. It stays unique
to tag Hp0;Ks1.
For any other combination of states we would immediately get
situations where
both the main as well as the distant aspect are active (ks1+ks2 or things
like
that). Now you only have to tell everyone that the distant aspect
must be off
if the main is not off, and vice versa. One could say "this is always the
case
for signal type DE-ESO:ks", well, ok. But for DE-ESO:hp with
main and distant
at the same place you have a different (but much more logical) rule: if the
main aspect allows passing, the distant aspect is active. If the main aspect
is hp0 (i.e. stop), the distant aspect is off. This is logical, since you do
not care what the next signals says if you must not pass this one.
The distant aspect in H/V is not always active when the main aspect is active.
If a signal is intermediate and exit depending on the route the distant
stays off.
Let's do it entirely another way: the German signalling system
does not allow
combined and distant signals at the same position. What happens if any other
signalling system allows this (regardless what the meaning of the distant
aspect in that case would be)? You can't tag 2 distant aspects without
inventing a really weird tagging there.
Combined and distant at one place is against all logic. Because combined IS
a distant integrated in one device (together with the main).
Or, like above: What if someone tags restaurant_with_cafe and cafe on one node?
There is main+distant signal in Germany at the same pole: H/V light
signals.
But those are actually 2 different signals. Everyone can see this. A combined
signal is one signal.
Not only H/V light. Also H/V semaphore.
The combined is just a simplification in PRESENTATION. It stays
main+distant. That's what the "Mastschild" shows.
> 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 tagging says that both hp0 and ks2 are shown at the same time.
See above. The tagging does not "show" anything, OSM is a database, not a
signal box or simulator.
> 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
As Michael already said: this is entirely specific to Germany, even if you
give
it an English name. Let's say Poland would let the yellow light
blink in the
same situation. This would give railway:signal:yellow_blink=yes then? And
what
if yellow blinking light is an entirely different state in Russia?
Then you
would tag yellow_blink=yes again, and one needs to guess which meaning it has
(there are situations where one countries signalling system goes beyond the
border for a while). That's why one tags the primary meaning of that things,
or a unique thing in states. DE-ESO:kennlicht is unique, and one can easily
find out the meaning, as there is only one. marker_light can be different in
every signalling system that exists, and it would create more tags that would
probably only used in one system. If you want to have a look at such an epic
desaster: the tagging for the differnt materials at a recycling point is a
pile
of yes/no tags, which should have been a simple list instead IMHO.
A marker light is a marker light, even in Poland. It is a light that "marks"
the signal.
WHY it is marked is not said. It stays flexible.
> 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.
This makes sense, but I fear that it is already too late for this. The other
tagging is already out in the wild, and it will be hard to fix this up. There
are still new nodes tagged with amenity=fire_hydrant popping up in the
database, even if emergency=fire_hydrant is the preferred tagging for years.
It is never too late and with JOSM presets it should work fine.
> 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.
A simple regular expression allows the opposite already: ([0-9]+ ?)([^ ].*).
Probably limited to Ks-Signals, as others are not controlled from ESTW.
The Kennzahl is a number between "00" and "99".
Block signals can have 2-3 numbers in ESTW areas.
What is the signal 525?
Kennzahl: 5
Signal: 25
And 16183?
Kennzahl: 16
Signal: 183
And 1812?
Kennzahl: 18
Signal: 12
or
Kennzahl: 1
Signal 812
So it is needed. And it is better to filter all signals with a specific
Kennzahl.
> As signals have positions, meaning a km (example: km 18.543) the
tag
> railway:signal:position=18.543
> should be used.
The wiki suggest it should be "distance" without any prefix. No idea why ORM
does not use this.
> 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.
This is just renaming without any added value, so you are too late for this.
Same as the DR/DB-prefix renaming.
Rename position to location means to have position take the posibility to
carry the information about position in longitudinal, not lateral way.
PeterDRS
6:41 p.m.
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(a)openrailwaymap.org
http://lists.openrailwaymap.org/lists/listinfo/openrailwaymap
8:56 p.m.
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.
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
1:09 p.m.
mapper999 <osm.mapper999@...> writes:
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.
To say that some ideas are too late would mean that nearly 99% of all German
signals are mapped.
The reality is that 1% of alls signals are mapped, so it is a good time to
change things in this early (!) state.
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.
I just wrote the JOSM preset from scratch, I admit I have not meantioned all
changes yet.
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.
That's ok but if the OSM database should be "good" it is neccessary to
change "bad" mapping to technical correct mapping.
The focus of mapping in past was graphics in my opinion, but it is time to
do a change to functionality. The graphics fraction can extract all
information from a well-formed functional mapping, but the other way is more
difficult.
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.
I think the other way round is easier.
Merging means adding main and distant.
When seperating, how to know what belongs to what?
There might even be a signal system where combined and main/distant
on the
same pole are both valid signals.
That's absolutely out of logic. That would mean 2 main aspects on one node.
That's not possible.
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.
Why is that important. When rendering the renderer has to know the signal
system. When only using the logic information it is not neccessary.
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)
That's not true.
All states can be divided into main and distant, although they might be
redundant.
It is a difference if a signal shows Hl10 just as a distant signal or if it
is also a main signal showing Hl10 meaning: Here driving, next stopping.
Why not tagging:
railway:signal:main:states:DE-ESO:Hl1;DE-ESO:Hl10
railway:signal:distant:states:DE-ESO:Hl10
BTW: HL signal system is not contained in German ESO. ;) Only in DV 301!
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.
It saves time as you need only 2 clicks where now you need 20-30 clicks.
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:*=*
A weak argument, because tagging without preset is not neccessary and why
should there be support for people who do not want to use presets.
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.
OSM is not the right place to describe a signal system.
So why mapping to a node:
railway:signal:system="In German signal system, a marker light means ... At
this node, the marker light means ..."
As a consequence you would have to tag on every node a maschine readable
description.
A post box is not tagged as:
post_box:operator=Deutsche Post AG
post_box:color=yellow /* Every post box of Deutsche Post is yellow */
post_box:Schlitz=yes /* Every post box has a Schlitz */
post_box:to_send_mail=open_Schlitz /* That's how to use a post box */
post_box:description=This is a post box where you can send your mail. /*
Description of a post box */
Same with Ks signals:
railway:signal:main=DE-ESO:ks
railway:signal:main:form=light /* Every Ks signal is a light signal */
railway:signal:additional_light=shortened /* An additional_light means
shortened */
railway:signal:additional_light:color=white /* In Germany it is a white light */
railway:signal:how_to_drive=Wait for Ks 1 and then go ahead /* How to use
the signal */
railway:signal:description=This is a Ks signal. It is always a light signal.
It shows Hp 0 or Ks 1. You may drive when it shows Ks 1.
I hope it is clear what I mean:
Why using tags to DESCRIBE a signal system? That would be a huge redundancy
when tagging the same thing to every node.
If someone invents a semaphore combined signal (System Ks+) it is possible
to tag
railway:signal:main=DE-ESO:ks_plus
railway:signal:main:form=semaphore
There is no need to tag light when declaring it as default.
In different signalling systems marker/additional lights might be
used for
different functions.
The function is not tagged in this case.
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.
In that case by using the value "yes" or trying to determine the function.
And why is it railway:signal:marker_light and not
railway:signal:distant/main:marker_light like with every other signal tag?
Because a marker light should only be used as tag to declare a signal as
being able to be disabled. Then it is independent of the function.
A distant signal at the position of a main signal is not disabled by marker
light, it just stays completely off.
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).
It is ok, when optimizing it you can think where the light is for (it is
unique in most cases).
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.
When someone changes the rules the tagging scheme must be changed.
I don't think that OSM should invent new rules, it should implement the
rules that exist.
BTW: many railway mappers probably don't know that there are hp
signals
that can not show hp0 (meaning stop).
I even don't know this too. ;)
I only know the case that a Hp signal is not needed any longer and until it
is removed it is mechanically fixated at this state.
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.
Although this is just naming it is quite important.
ref = 16P3
ref:area_code = 16
ref:signal = P3
I have a problem with redundancy.
What if someone tags:
ref=18P4
ref:area_code=16
ref:signal=A
Why supporting this?
area_code is a good name for "Kennzahl".
I started building relations for all things a signal box manages:
- switches
- signals
- tracks
Look at Priestewitz or Dresden-Neustadt to know what I mean.
That could support seeing that a Kennzahl is wrongly tagged. Or to
automatically extract all signals belonging to a specific signal box.
railway:signal:speed_signal
I don't like to separate zs3 and lf7 to separate keys.
As long as on a specific geographic position a node can only exist once it
seems neccessary.
First it's not obvious when to use speed_signal and when
speed_limit, so
mappers get confused.
speed_signal: Can be dynamic (light)
speed_limit: Only static (form), only for the main track line (not
sidings!), only the highest possible speed (not for different ways over
switches).
In Germany that is where nice to see by dividing into Lf7 and Zs3.
In other countries it may be different, but the principle is international
the same.
Lf7 and Zs3 can be comined, look in Meißen or Tharandt.
If somebody wants to count all speed signals, you need to check for
speed_signal and speed_limit
Merging things is easier than dividing, because dividing is not unique,
while merging is.
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.
Tram is not my area. If it doesn't collide with tram mapping it is not my
problem.
In Germany it is not possible to have two Lf7 or two Zs3 on the same node in
the same direction.
Do not try to construct things that are out of any logic! ;)
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.
It is not consequent to use position for longitudinal and lateral in the
same database.
railway:position is longitudinal and
railway:signal:position is lateral
That's not a good idea.
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.
Ok that's just a naming thing.
But it can prevent people being confused thinking that a train drives to the
back controlled from the front ("geschobene Rangierfahrt").
9:51 a.m.
The direction should be tagged as
railway:signal:direction=nominal/reverse
regarding to the OSM way.
This is very easy: it will not happen. This is neither a decision of you or
me, this is just about 10 years too late to be of any chance. The existing
terms "forward" and "backward" are used in OSM about everywhere for
"in/against direction of OSM way". (Old style) public transport relations?
Check. Tagging how many lanes an in which direction a given piece of highway
has? Check. You get the idea. Inventing something new for railway tagging is
just an invitation for another flamewar[1], so we will just stick with it.
Eike
1) look at Michaels mail about his mechanical edit to introduce DE-ESO:
prefixes for German signal names/states on talk-de(a)openstreetmap.org
3428
days inactive
3435
days old
openrailwaymap@openrailwaymap.org
11 comments
7 participants
participants (7)
-
Christian Wendel
-
JJJ Wegdam
-
mapper999
-
Michael Reichert
-
Peter Reinhart
-
PeterDRS
-
Rolf Eike Beer