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