[openrailwaymap] Zehn Abfragen gegen schlechtes Signaltagging / Ten Overpass Queries to search bad signal tagging

[Michael Reichert]

Hallo,

da ich bei meinem "mechanischen" (haha [2]) Edit viele Signale sichte,
fallen mir Taggingfehler in nennenswerter Zahl auf. Einen Teil kann ich
korrigieren, weil die Mapper note=* getaggt haben, einen Teil aber auch
nicht. In letzteren Fällen habe ich die Signale oft nicht auf das neue
Präfix umgetaggt (damit sie später noch auffallen) und die schuldigen
Changesets kommentiert.

So wie es unter präfix-losen Signalen Fehler gibt, dürfte es diese
Fehler auch bei präfix-habenden Signalen geben. Wer Zeit und Lust hat,
kann mal mit der Overpass-API auf Fehlerjagd gehen. Die Abfragen geben
XML mit Metadaten aus, d.h. über Export -> JOSM könnt ihr euch die
Abfrageergebnisse direkt in JOSM laden.

(1) Signalnummern, die als railway:ref=* erfasst sind. Beispiel-Abfrage:
http://overpass-turbo.eu/s/8JM

(2) Signale, die sowohl mit railway:signal:main!=DE-ESO:hp als auch
railway:signal:distant=* getaggt sind. Gegebenenfalls andere
Hauptsignal-Vorsignal-Mischungen mit Ks- und Hl-Anteil ausprobieren.
http://overpass-turbo.eu/s/8JN

(3) Ähnlich (2), aber die Kombination railway:signal:main!=DE-ESO:hp und
railway:signal:combined=*.

(4) Ähnlich (2), aber die Kombination railway:signal:distant=* und
railway:signal:combined=*. (Geht in der Realität einfach nicht, da das
Mehrabschnittsignal schon eine Vorsignalfunktion hat)

(5) Signalen mit name=* statt ref=*.
http://overpass-turbo.eu/s/8JO

(6) Weichen mit name=* statt ref=*
http://overpass-turbo.eu/s/8JP

(7) Signale ohne railway:signal:direction=*.
http://overpass-turbo.eu/s/8JR
Ich spreche mich dafür aus, diese nicht mehr zu rendern, denn Renderer
haben Macht. [1]

(8) Signale ohne railway:signal:position=*.
http://overpass-turbo.eu/s/8JS

(9) Sh 1-Licht als eigenständiges Sh-Signal gemappt. In den
Signalschirmen von Hp-, Ks- und Hl-Signalen sind oft Sh 1-Lichter
integriert (sodass dann Hp 0 + Sh 1 gezeigt werden kann). Viele dieser
Signale wurden jedoch so gemappt, als wären es zwei eigenständige
Schirme am gleich Masten (gibt es zwar, aber nur bei Sv-Signalen und
sehr alten Hp-Signalschirmen).

Falsches Tagging (denkt euch das DE-ESO ggf. einfach weg):
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh
railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde
statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen
falsch ist)
railway:signal:minor:form=light

Richtiges Tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh1
railway:signal:minor:form=light

Man kann bei Hp-Signalen aus der Ferne eigentlich schlecht diesen Fehler
korrigieren. Es bedarf Ortskenntnis. Beim Rest (Hl, Ks) kann man das
eigentlich aus der Ferne tun, sollte jedoch sehr vorsichtig sein und
ggf. den Mapper kontaktieren.

(10) Ein weiteres Problem, das mir aufgefallen ist, sind Verwechslungen
zwischen Signaltypen. Besonders gerne:
(a) Ks-Haupt- und Ks-Mehrabschnittsignale werden als Hp-Lichtsignale
erfasst. Man erkennt auch ohne Ortskenntnis potentielle Fälle an
Signalnummern, die nach folgenden Schema aufgebaut sind. Sie enthalten
meistens einen Nummer am Anfang, die im gesamten Bahnhof gleich ist.

Einfahrsignale: 53A, 53AA, 53B, 53BB, 53F, 53FF, 53G, 53GG
(Doppelbuchstaben immer im Gegengleis)

Ausfahrsignale: 53N1, 53N2, …, 53P1, 53P2, … (nach N/P steht die
Gleisnummer, gerne auch zwei- oder dreistellig; in einigen Stationen
wird neben N und P auch noch zusätzlich O oder M verwendet, z.B. Krefeld
Hbf)

Zwischensignale: 53ZU1, 53ZU2, … (markant ist das Z, davor die
Bahnhofsnummer, dahinter ein Buchstabe für den Bereich im Bahnhof,
gefolgt von der Gleisnummer)

Regex für Ks-Signalnummern: [0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2})
Diese Regex matcht nicht in Potsdam Hbf!

Wenn also ein Bahnhof vor dem A, B, N, P, Z* usw. eine Nummer hat,
sollte man Googlen, ob dort in den vergangenen Jahren ein ESTW errichtet
wurde. Es gibt auch bei H/V-Signalisierung Bahnhöfe mit Nummern vor den
Buchstaben, diese Bahnhöfe sind dann ferngesteuert, z.B.
Karlsruhe–Graben-Neudorf oder z.B. Mühlhausen (Wern).


(b) Ks-Mehrabschnittsignale werden als Ks-Hauptsignale erfasst. Das
erkennt man nicht aus der Ferne, wenn nur wenige Signale erfasst sind.
Statistisch dürfen Einfahr- und Zwischensignale meist
Mehrabschnittsignale sein, Ausfahrsignale und Blocksignale sind nur
Mehrabschnittsignale, wenn die Blockabstände kurz sind oder der nächste
Abzweig/Bahnhof weniger als Vorsignalabstand + Durchrutschweg + ein
Bisschen entfernt ist.

Viele dieser Fehler (ausgenommen Abfrage 6, 9 und 10) stammen von iD-Usern.

Siehe auch https://github.com/rurseekatze/OpenRailwayMap/issues/192

Viele Grüße

Michael


PS Die OpenRailwayMap-Vorlagen sind mittlerweile in den
Vorlagenverzeichnissen der JOSM-Entwickler gelistet.

[1] Nicht umsonst spricht man von "Mappen für den Renderer".
[2] Da ich sehr viele Signale sichte und viele Fehler finde, fühlt sich
das alles andere als mechanisch an.

-------------------
Hi,

I have found lots of tagging errors during my mechanical edit which adds
the prefix "DE-ESO:*" to a lot of German signals. Following eight
queries might dig out errors in your area:


(1) Signal numbers tagged as railway:ref=* instead of ref=*
http://overpass-turbo.eu/s/8JM

(2) *Germany only* Signals tagged both railway:signal:main!=DE-ESO:hp
and railway:signal:distant=*. You might try other combinations with Hl
and Ks signals.
http://overpass-turbo.eu/s/8JN

(3) *Germany only* SSimilar to (2), but the combination of
railway:signal:main!=DE-ESO:hp und railway:signal:combined=*.

(4) *Germany only* SSimilar to (2), but the combination of
railway:signal:distant=* und railway:signal:combined=*. (It's impossible
in reality that a combined signal shares a its pole with a distant
signal because the combined signal is already a distant signal.)

(5) Signals tagged name=* instead of ref=*.
http://overpass-turbo.eu/s/8JO

(6) Switches tagged name=* instead of ref=*.
http://overpass-turbo.eu/s/8JP

(7) Signals without railway:signal:direction=*.
http://overpass-turbo.eu/s/8JR
I support not to render signals without railway:signal:direction=* (they
are rendered at the moment) because people often only map things which
are rendered.

(8) Signals without railway:signal:position=*.
http://overpass-turbo.eu/s/8JS

(9) *Germany only* If a Hp, Ks or Hl light signal can show Sh 1 the
following is the right tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh1
railway:signal:minor:form=light

The wrong tagging:
railway:signal:main=DE-ESO:hp
railway:signal:main:form=light
railway:signal:minor=DE-ESO:sh
railway:signal:minor:states=DE-ESO:hp0;DE-ESO:sh1 (bis vor Kurzem wurde
statt Hp0 noch Sh0 getaggt, was laut Ril 301 aber bei Lichtsignalen
falsch ist)
railway:signal:minor:form=light

The "wrong" tagging should only be used if the minor signal is a
separate signal which is mounted below the main/combined signal at the
same pole.


(10) *Germany only* Some Mappers mix up Hp light signals with Ks light
singals and Hl light signals with Ks light signals. You cannot correct
the tagging without local knowledge but you can create a "review list"
because Ks signals inside stations have different numbering system than
Hp and Hl signals. Inside stations Ks signals have a number which
follows the following regex:
[0-9]+(([M-Q]{1}|Z[R-V]{1})[0-9]+|[A-K]{1,2})

Most of these errors are done by iD users (except no. 6, 9 and 10).

See also https://github.com/rurseekatze/OpenRailwayMap/issues/192

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)


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