[Talk-de] Mechanischer Edit an Eisenbahnsignalen in Deutschland

[Rolf Eike Beer]

Am Mittwoch, 15. April 2015, 15:00:40 schrieb fly:
> Fände es ja schön wenn auch alle meine Fragen beantwortet werden.
>
> Insgesamt scheint ja leider kaum Diskussionsbereitschaft vorhanden zu
> sein und auf meine Vorschläge wird sich gar nicht erst eingelassen

Wie es in den Wald schallt… Für meinen Geschmack nehmt ihr euch da beide 
nichts.

Es sind diverse Gegenargumente gekommen, auf die auch nicht wirklich 
eingegangen wurde. Ich persönlich bin da eher leidenschaftslos, und am 
Tagging-Schema auch nicht beteiligt gewesen, also versuche ich es jetzt 
nochmal von "neutraler" Seite aus. Wenn hier beiden Seiten die Lust am 
Diskutieren vergeht kann ich es aber vollkommen verstehen, als wirklich 
konstruktiv habe ich nur wenige Teile der ganzen Diskussion empfunden.

> Am 15.04.2015 um 09:27 schrieb 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:
> >>>> 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?
> 
> Naja, war ja ein Volltreffer und wie willst Du es denn anders
> interpretieren ohne die fehlenden Information der Sonderbehandlung ?

Ich kann mich Michaels Verwunderung hier nur anschließen. Warum soll man 
virtuelle Probleme diskutieren, wenn du doch genug echte Probleme ausgemacht 
haben willst? Lasst uns dann doch auch bitte realitätsnahe Probleme 
diskutieren, Streitpunkte gibt es ja scheinbar genug, das man nicht noch 
unnötig neue erfinden muss.

> >>> 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?
> 
> Wie kürzere Tags. Mir geht es um die nutzlose Wiederholung. In
> Sonderfällen wird dann erweitert. Das heißt doch noch lange nicht, dass
> immer die Richtung im Tag benötigt wird.

Die Richtung würde nur dann nicht benötigt, wenn in beide Richtungen das 
gleiche Signalbild gezeigt würde. Das ist so unwahrscheinlich, das man es 
völlig ignorieren kann. Also braucht es immer die Richtung.

> >> 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.
> 
> Wenn es nicht dokumentiert ist, verwirren zwei Punkte. Selbst wenn es
> dokumentiert ist, müß es erst gefunden und gelesen werden. Sonst schlägt
> Ihr ja auch vor alle Signale auf einen Pubkt zu mappen, nur bei der
> Richtung soll dann Schluß sein ?

Es gibt zwei Möglichkeiten:

1) beides an einem Node, dann heißt das jeweil eine Tag-Ebene mehr. Fände ich 
prinzipiell auch gut, weil es z.B. Schneepflug-Signale gibt, die quasi 
ausschließlich im Doppel auftreten: ein Mast, an einer Seite steht "hoch", an 
der anderen Seite "runter". Wenn man das sinnvoll vereinheitlichen kann: 
gerne, immer her damit. Wie würdest du denn so ein Signal eintragen?

Hier siehst du sowas bildlich:

http://walter-klan.de/signale/08)_ne-signale.html#Ne_7

2) 2 Nodes wie gehabt. Kürzere Tags, dafür liegt das halt nicht direkt 
übereinander.

[Signalrelationen]

> Zumindest Links wären dann wohl angebracht.

Kann ich mir nichts drunter vorstellen, insofern würde ich das auch lesen. 
Nach meiner Erfahrung ist aber alles, was man ohne Relation erschlagen kann, 
ein Gewinn. associatedStreet ist schon schlimm genug, da muss man nicht noch 
mehr von dem Zeug erfinden.

> >> 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.
> 
> Siehe zB :lanes-Tagging
> 
> Was ist bitte an folgendem Beispiel Unsinn ?
> 
> railway=signal
> signal:main=*
> state=*
> height=*
> ref=*
> direction=95

-es sollte IMHO tatsächlich "states" und nicht "state" sein, denn es gibt die 
Gesamtmenge der möglichen Zustände an
-es gibt zuhauf Signalmasten, an denen mehr als ein Signal hängt, die 
verschiedene Zustände haben können, wie willst du das abbilden? Vor allem wenn 
du z.B. 2 Hauptsignale in verschiedene Richtungen am gleichen Mast hast, die 
unterschiedliche Signalzustände anzeigen können?
-ich halte "state" oder "states" für viel zu allgemein, das könnte auch ein 
sinnvoller key für alle möglichen anderen Tags sein. Ein key, der 
kontextabhängig völlig unterschiedliche Werte(-kombinationen) enthalten kann, 
ist für jeden Parser ein graus.
-liest du das Wiki eigentlich selbst? "height" ist Höhenangabe (i.d.R. in 
Metern), d.h. man müsste jedes Signal vermessen?

"ref" ist im übrigen jetzt schon ein Problem, wenn Haupt- und Vorsignal am 
gleichen Mast hängen haben die häufig unterschiedliche Bezeichnungen. "ref" 
gibt dann häufig die Beschreibung am Mast an, also sowas wie "1A/1n" oder 
"G/pII" (beides reale Beispiele, die ich selbst in natura kenne).

> >>> Lektüreempfehlung:
> >>> http://fahrweg.dbnetze.com/file/fahrweg-de/2397820/nwGeHFo3ET6OL80ylv-Jl
> >>> U0vWcI/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.

Das liegt schlicht und einfach daran, dass du die StVO aus praktischer Sicht 
einigermaßen kennst. Ich habe gestern auch mal einen Blick in die 
Bahnvorschrift geworfen und auch nur mit dem Kopf geschüttelt. Aber mit ein 
wenig nachgucken traue ich mir nach nur wenigen Stunden, die ich mich effektiv 
mit dem Thema beschäftigt habe, zu, die meisten in Deutschland vorkommenden 
Eisenbahnanlagen vernünftig erfassen zu können.

Wenn du keinen Bezug zu dem Thema hast, wird dir das nicht sofort 
offensichtlich sein. Kannst du aus dem Stand einen Hydranten vollständig und 
korrekt eintragen? Weißt du, was alles auf dem Hydrantenschild steht, und was 
davon in OSM gehört und was nicht?

> > 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.
> 
> Genau, es sind alles Links zu externen Seiten, und auch dort nur
> Fachabkürzungen und weitere Links. Zu den Beispielen am Ende habe ich
> schon Kommentare abgegeben.
> 
> Das ist mir alles doch recht dürftig und absolut nicht für eine größere
> Gemeinschaft geeignet. Unter solchen Voraussetzungen frage ich mich halt
> warum das alles in OSM soll. TMC wurde ja schon erwähnt als
> abschreckendes Beispiel.

Ich habe auch keine Ahnung, was TMC ist. Die Tags begegnen mir regelmäßig und 
ich ignoriere sie genauso regelmäßig. Wo ist das Problem?

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