[Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Alexander Matheisen]

On Di, 2015-04-14 at 22:34 +0200, fly wrote:
> Am 14.04.2015 um 21:13 schrieb Michael Reichert:
> > Am 2015-04-14 um 19:43 schrieb fly:
> >> Am 09.04.2015 um 08:25 schrieb Rolf Eike Beer:
> >>> Wenn ich das mit dem Tagging vergleiche, bei dem mir auch regelmäßig 
> >>> namespace-Tags begegnen, dann ist es doch leicht anders:
> >>>
> >>> emergency=fire_hydrant
> >>> fire_hydrant:type=underground
> >>>
> >>> railway=signal
> >>> railway:signal:...
> >>
> >> railway:signal:main:state:forward=*
> > 
> > Lass mich raten, das Signal stammt von rayquaza und ist – für
> > OpenRailwayMap-Verhältnisse – schon ewig gemappt?
> 
> Nein, nur meiner Logik entsprungen.

du denkst dir ein Tag selbst aus und kritisierst dann, dass es zu lang
sei, oder wie soll ich das jetzt verstehen?

> > Das sind Versuche,
> > Signale zu mappen, die für verschiedene Richtungen gelten und am selben
> > Mast hängen. Es hat sich nie durchgesetzt (das
> > railway:signal:<TYP>:state:forward/backward=* werten wir nicht aus und
> > wird auch nicht ausgewertet werden), wir mappen stattdessen zwei kurz
> > nacheinander folgende Nodes auf dem Gleis, einer für die eine Richtung,
> > der andere für die andere Richtung.
> 
> Habe ich das im Wiki überlesen ?
> Welche Gründe sprechen denn dafür ?

Das Tagging so zu gestalten, dass Signale an einem Mast für verschiedene
Richtungen eingetragen werden können, würde die Tags noch komplizierter
machen. Da es nur wenige Signale gibt, wo das vorkommt, haben wir uns
entschieden, in diesen Fällen zwei Nodes zu taggen und dafür insgesamt
kürzere Tags zu schaffen. Das ist doch in deinem Sinne, oder?

> Mapped Ihr dann auch noch den Masten ?
> 
> Finde ich inkonsistent und jede Ausnahme/Sonderregel macht es eher
> komplizierter.

Ich finde es deutlich komplizierter, als zwei Nodes zu mappen.

> Warum nicht gleich eine type=node Relation oder ähnliches, dann ist auch
> die Verknüpfung mit der eigentlichen Position (Masten) möglich und wir
> können jedes Signal einzeln eintragen.

Das Thema Signalrelationen haben wir in der Vergangenheit schon öfter
auf diversen Kanälen diskutiert und sowohl für Mapper als auch die
Auswerter für nicht praktikabel befunden. Deshalb habe ich keine Lust,
dieses Thema hier wieder neu auszudiskutieren, nur weil du jetzt
plötzlich meinst, das Taggingschema der Signale in Frage zu stellen.

> >> Wenn möglich sollte doch der ein oder andere Tag auch mit weniger
> >> Pre-/Postfixen auskommen (siehe auch :lanes-Tagging).
> >>
> >> state:main:forward=*
> >>
> >> bzw wenn möglich sogar nur
> >>
> >> state=*
> >> height[:TYPE][:DIRECTION]
> >> Eindeutig ist das ganze doch schon durch railway=signal
> >>
> >>> Das macht die Zuordnung "interessiert mich der key" für den Benutzer etwas 
> >>> einfacher, aber andere Dinge wir "ref" fallen da trotzdem aus der Reihe[1]. 
> >>
> >> Welche Benutzer*innen meinst Du ?
> >>
> >> Bei Vorlagen ist es erstmal egal aber aufgelistet füllen solche langen
> >> Schlüssel schon eine Menge Platz aus und die wichtige Information steht
> >> am Ende.
> >>
> >>> Ich sehe nicht, dass der Verzicht auf "railway:" bei den key-Namen eine große 
> >>> Verwirrung stiften würde, da der Rest der Keys, zumindest so weit ich das 
> >>> überblicken kann, zu Kollisionen mit anderen Taggings führen würde.
> >>
> >> Wolltest wohl "zu keinen Kollisionen" schreiben
> >>
> >> Kann mir auch nicht richtig Probleme vorstellen in Bezug auf railway=signal
> > 
> > An einem Hauptsignalmasten hängen oft (Signaltyp laut Taggingschema in
> > eckigen Klammern):
> > - ein Vorsignal (v.a. in Bahnhöfen und auf stark befahrenen Strecken)
> >   [distant]
> > - ein Geschwindigkeitsanzeiger [speed] und/oder
> >   Geschwindigkeitsvoranzeiger [speed_limit]
> > - ein Gegengleisanzeiger (bei Ausfahrsignalen) [wrong_road]
> > - ein Richtungsvoranzeiger [route_distant] und/oder Richtungsanzeiger
> >   [route](bei Streckenverzweigungen und mancherorts auch bei
> >   Gleiswechseln)
> > - eine Haltetafel [stop] (die mit dem H)
> > - Ein Hauptsignal hat oft auch noch die Funktion eines Rangiersignals
> >   [minor].
> 
> Was war denn jetzt an meinen Vorschlägen jetzt falsch ?
> 
> state:main:forward=* resp. state:main=*
> height[:TYPE][:DIRECTION] resp. height[:TYPE]
> 
> Warum reicht nicht state=* wenn es sich nur um ein Hauptsignal dreht ?
> (railway:signal:main:state=*)

Wie soll man denn so etwas auswerten? Oder JOSM-Vorlagen für so ein
Tagging erstellen? Denke erstmal etwas über deine Vorschläge nach, bevor
du solchen Unsinn schreibst.

> > Lektüreempfehlung:
> > http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-JlU0vWcI/8332992/data/rw_301_aktualisierung_8.pdf
> > :-) Ein gleichzeitiger Aufenthalt auf einem Bahnhof ist empfehlenswert
> > für Nicht-Bahnaffine.
> 
> Nein danke, wenn die Zeit reicht, mache ich mal einige Fotos und
> versuche dann mein Glück
> 
> Solch ein Regelwerk ist nicht zumutbar und sollte übersetzt werden, Lese
> ja auch nicht die gesamte STVO um eine Ampel bzw Verkehrsschild einzutragen.

Wenn du ein wenig im Internet recherchieren würdest, würdest du recht
schnell auf einfachere Erklärungen stoßen. Wikipedia ist ein guter
Anfang, ebenso die auf den ORM-Wikiseiten bei jedem Signal vorhandenen
Links zu weiterführenden Informationen. Wenn du dennoch damit
überfordert bist, dann lass es doch einfach. Es zwingt dich doch
niemand, Bahnsignale einzutragen.

> Habt Ihr mal die Möglichkeit Tags an die Linien (railway=*) zu setzten
> gedacht, so wie wir das auch bei Straßen mit maxspeed, maxheight und
> ähnlichen Verkehrschildern machen ?

Bei maxspeed machen wir das schon so, wobei trotzdem die Signalstandorte
erfasst werden. Eine maxspeed-Angabe am Gleis reicht allein nicht aus,
weil es verschiedene Signaltypen gibt und diese Information sonst fehlen
würde. Und die restlichen Signale lassen sich nicht wirklich über die
Linien abbilden.


Gruß
Alex
-------------- nächster Teil --------------
Ein Dateianhang mit Binärdaten wurde abgetrennt...
Dateiname   : signature.asc
Dateityp    : application/pgp-signature
Dateigröße  : 490 bytes
Beschreibung: This is a digitally signed message part
URL         : <http://lists.openstreetmap.org/pipermail/talk-de/attachments/20150415/8d5729a3/attachment.sig>