Bahnschranken wie eintragen

Das Prinzip ist jedoch im Grund das Gleiche wie bei einem Bahnübergang. Bei der dargestellten Brücke handelt es sich um eine Schwenkbrücke, die zur Seite geschwenkt wird, um Schiffe hindurchzulassen. Für diese Zeit wird die Brücke mit den Schranken vorübergehend gesperrt.

Man kann das Thema “Bahnschranken als seperaten Node eintragen” natürlich weiterhin ungeklärt lassen - das fördert dann aber den Wildwuchs. Noch wäre es meines Erachtens zeitig genug, sich hier das bestmögliche Tagging zu überlegen.

1 Like

Danke!

Sehe ich auch so. Ampeln können auch zusammen mit dem Kreuzungspunkt oder separat (Haltelinie) erfasst werden.

1 Like

Keine Ahnung. Ich hab einfach nur die Bahnschranken rausgenommen.

Interessanterweise sind die Schranken an der Schwenkbrücke “Tomnahurich Bridge”, die in dem Wiki-Artikel als Beispielfoto genutzt werden, in OSM nicht eingetragen, weder als extra Node noch als Merkmal an der Brücke selbst.
https://www.openstreetmap.org/way/26654474

Ich kan nur vermuten, dass dies deswegen so ist, weil es auch für Schwenkbrücken kein festgelegte Tagging für die Schranken gibt.

Insofern ist das Beispielfoto aus meiner Sicht unglücklich ausgewählt bzw. zeigt, dass es offensichtlich Klärungsbedarf gibt, wie solche Schranken (vor beweglichen Brücken, vor Bahnübergängen, …) in OSM eingetragen werden.

1 Like

Ich kann diesbezüglich nur beiden allen drei Beiträgen von Galbinus 100% zustimmen, insbesondere

dachte ich wäre mehr als ausreichend, dass man in diese Richtung weiterdiskutieren würde. Stattdessen sind jetzt alle damit zu Frieden, dass im Wiki halt entfernt wird, dass ein barrier=lift_gate auch an Bahnübergängen existieren kann - obwohl es doch faktisch klar ist, dass Schranken nunmal an Bahnübergängen existieren. Ja, man kann viele diesbezüglich ausreichend erfassen mit

, weil die meisten halt 08/15-Bahnübergänge sind. Aber eben nicht alle.

Es gibt auch Bahnübergänge, wo die Schranke einseitig mal 100m vorher sich befindet, beispielsweise weil der Bahnübergang direkt nach einer schlecht einsehbaren Kurve kommt. Oder es gibt auch völlig komische Zusammentreffen von Schienen, Straßen und Fuß-/Radwegen, wo dann die Schranken arg wild gesetzt sind wie z.B. hier zu sehen: https://www.youtube.com/watch?v=ryf5pxQJK4k (in OSM).
Da halte ich durchaus für nachvollziehbar, dass dies mal jemand genauer mappen möchte.

Ist ja nachvollziehbar, dass man jetzt nicht was so kurzfristig mappt, dass plötzlich Router damit nicht klarkommen, nur ist das eigentlich ja ein Mappen für den Renderer/Router/Verarbeiter was ja ein klar bezeichnetet Antipattern von OSM ist. Ich empfinde es daher irgendwie als … unschön zu sagen mit der Wikiänderung ist jetzt alles im Lot, nur weil’s einen somit selbst nicht mehr betrifft. Letztlich verschleiert das Entfernen aus dem Wiki den problematischen Sachverhalt nur. Was ist mit den Mappern die’s halt genauer nun erfassen möchten? Was ist mit dem Renderer der vl. schon eher Interesse daran hat zu wissen, wo genau die Schranken nun stehen?
Egal - Hauptsache die Navi-App geht noch?

Gruß,
asca

Edit: Ich sollte schneller Beiträge schreiben, sodass Galbinus mit weiteren Beiträgen meine Zählung nicht kaputt macht ;-)

1 Like

Bahnschranken als Einzelobjekte zu erfassen, erscheint mir nicht ratsam.
Sie wären dann doppelt vorhanden, als Eigenschaft des level_crossing und als Einzelobjekt.
Vergisst ein Mapper die access-Werte richtig zu setzten, macht es das Routing kaputt.

Es wäre sinnvoll, wenn man einen Bahnübergang nicht nur als unzusammenhängende Kreuzungspunkte zwischen highway und railway sondern als auch Fläche erfassen würde.
Dies könnte ähnlich wie bei man_made=bridge geschehen, wo die bridge-Fläche die Wege auf der Brücke umfasst und alle Wege unterhalb überdeckt.
Bei einem Bahnübergang könnte man als Fläche über den äußeren Rand der Fahrbahn bzw. des Bürgersteigs sowie über die Haltelinien, ersatzweise Schranken, ersatzweise Verbindungslinie der Andreaskreuze definieren.
Die Eigenschaften “beschrankt” und “mit Lichtsignal” könnte man mit der Fläche verknüpfen.

Bei einem großen Bahnübergang wie hier (https://osm.org/go/0HsY8haJ5) würden zwölf Kreuzungspunkte von highway und railway zu einem Bahnübergangsobjekt zusammengefasst.

Damit wäre die Position der Schranken recht gut definiert.

Damit könnte man die Bahnübergänge auf einer Strecke zählen und nicht nur die Kreuzungspunkte mit highways.

Damit könnte man die Ansagen der Navigationssysteme verbessern.
Statt “Achtung Bahnübergang, Achtung Bahnübergang, Achtung Bahnübergang” würde “Achtung Bahnübergang mit drei Gleisen” angesagt.

Ich habe die deutsche Version der Wikiseite an die englische (und alle anderen Sprachen) angeglichen. Es ist vollkommen unüblich, auch in Deutschland, Bahnschranken separat zu mappen. Folge war im konkreten Fall ein Routingproblem.

Dem stimme ich zu. Aber bei so etwas bedeutsamen wie Bahnschranken sollte erstmal ein Taggingschema dokumentiert+vereinbart werden, bevor man die Welt mit barrier=lift_gate zupflastert. Zum Beispiel muss erkennbar sein, dass die Schranke Teil des Bahnübergangs ist.

Als Fläche macht das mMn wenig Sinn und passt nicht zum OSM-Datenmodell. Einzelobjekte für die Schranken plus eine Relation um alle Obekte des Bahnübergangs zusammenzufassen?
Um keine Routing-Probleme zu verursachen, könnte man die Schranken nicht als barrier=* mappen, sondern als railway=*.

Reicht nicht die Information, dass es sich um eine Bahnschranke handelt?

Klar, dann weiß man automatisch, dass die Schranke Teil irgendeines Bahnübergangs ist. Woanders sollten keine Bahnschranken stehen.
Aber schöner ist es, diese zusätzlich per Relation an den Bahnübergang zu binden.

Aber wenn man ein Tag einführt, der eine Schranke als Bahnschranke identifiziert, dann ist die Zugehörigkeit zu einem Bahnübergang auch vorhanden. Bei Ampeln packen wir die separaten highway=traffic_signals auch nicht in eine Relation.

Was nicht ist kann ja noch werden :wink:

Genau so sehe ich das auch. Es müsste jemand mit Englischkenntnissen übernehmen, über ein Proposal eine Klärung herbeizuführen. Dabei sollte dann aber auch ein wenig weiter gedacht und auch Schranken wie die an der im Wikibeitrag über Schranken als Foto aufgeführte Schranken an eine Dreh- oder Hubbrücke mit berücksichtigt werden

1 Like

Ich muss sagen, ich glaube, man kann das auch verbinden. Was ist, wenn man die Bahnübergangsfläche als “area:highway=railway_crossing” und die Schnittpunkte der area:highway mit den Straßen mit railway=barrier bezeichnet werden?

Warum soll die Erfassung als Fläche dem OSM-Datenmodell widersprechen?
Ich darf die Gleise im Bereich des Bahnübergangs überqueren.
Wenn ein Zug sich nähert, muss ich den Bahnübergang verlassen, selbst wenn zwischen den Gleisen genug Platz wäre.
Diese Restriktionen lassen sich über eine Relation von Einzelobjekten nicht abbilden.

Eine Repräsentation als Fläche ist einfach zu erstellen und für jeden Mapper verständlich.
Eine Relation aus Kreuzungspunkten und Schrankenobjekten ist komplex und fehleranfällig.
Wir sollten, wenn möglich, dem KISS-Prinzip folgen.

Weil wir in OSM im Allgemeinen kein Flächenmapping betreiben. Straßen sind bei uns Linien und keine Flächen.

Brücken werden neuerdings per Flächenmapping erfasst, wobei die Fläche dem Grundriss (Wort?) der Brücke entspricht.
Aber wie würde die Fläche eines Bahnübergangs aussehen? Soll man dort die Fläche der Straße nachmalen? Was ist, wenn die Nebenflächen versetzte Mini-Schranken haben? Wenn eine Nebenstraße ebenfalls noch eigene Schranken hat? Dann werden letztlich irgendwelche Flächen eingezeichnet, die so in der Realität nicht existieren.

Für mich sieht diese Anforderung wie eine relativ simple Routingaufgabe aus: Wege die direkt zwischen Schranke, Bahnübergang und gegenüberliegender Schranke liegen, gehören zum Bahnübergang.

Auch das Flächenmapping via area:highway ist Bestandteil des OSM-Datenmodels. Sie ist aber nur eine Ergänzung zum Linienmapping. Von daher wird beides benötigt.

Ich finde: Aus einem an sich überschaubaren Problem wird hier ein zu großes Problem gemacht.

Unser in dieser Diskussion offensichtlich gewordenes Problem:

Es gibt ein etabliertes und funktionierendes Tagging für manuelle Schranken, die z.B. Waldwege für unberechtigten Fahrzeugverkehr sperren und für automatische Schranken, wie sie z.B. an gebührenpflichtigen Parkplätzen stehen.

Es gibt für Ampeln zwei etablierte Tagging-Möglichkeiten: Pauschal auf dem jeweiligen Knotenpunkt einer Kreuzung oder alternativ an jeder Haltelinie einzeln. (Wohlgemerkt an der Haltelinie und nicht da, wo die Ampel steht)

Würde man das Tagging-Schema von Ampeln auf Bahnübergänge übertragen, würde sich daraus ergeben, dass man Schranken und Lichtsignale auch an der jeweiligen Haltelinie alternativ zum zentralen Eintrag am Kreuzungspunkt zwischen Bahngleis und Straße eintrüge. Doch da Ampeln von Routern grundsätzlich als temporäre Sperren interpretiert werden (und damit nicht gemieden sondern bei der Rotuen wahrscheinlich lediglich mit einer pauschalen Verweilzeit berücksichtig werden) wird eine Schranke als dauerhafte Sperre interpretiert, so dass eine Alternativroute unter Umgehung der Schranke gesucht wird.

Im Grunde muss nur dieses eine Problem gelöst werden, dann wäre ein Tagging von Schranken an Schwenk- und Hubbrücken und an Bahnübergängen nach dem gleichen Prinzip möglich wie das von Ampeln.

Statt also das Bahnübergangstagging aufwändig vollkommen neu (mit Relationen und Flächen) zu denken, wäre es meiner Meinung viel einfacher und zielführender, sich darauf zu konzentrieren, wie man dafür sorgt, dass solche Schranken eben nicht als dauerhafte Sperren interpretiert werden. Ein einfahres Zusatzattribut würde dafür reichen - wenn, ja wenn es denn allgemein anerkannt und bekannt wäre, so dass es von den Entwicklern von Routing-Software berücksichtigt werden könnte.

Und ich finde, es gibt gute Gründe, die Information “hier muss man ggf. an eine Schranke oder an einem Lichtzeichen halten” vom Kreuzungspunkt auf die jeweiligen Haltelinien zu verschieben, da bei manchen Bahnübergängen (z.B. mit mehrern Gleisen oder mit komplexen Straßensituationen) Haltelinien und Kreuzungspunkt manchmal relativ weit auseinander liegen.

2 Likes

Das Zusatzattribut gibt es im Grunde schon: access=yes.

Aber ich bin natürlich auch dafür, dass man eine Bahnschranke anders kenntlich macht, dann könnte man sich (nach einer Übergangszeit) das access sparen.
Ich denke aber, man sollte kein barrier-Tag hierfür verwenden, sondern eher etwas wie highway=railway_barrier- Dann hat man auch keine Probleme mit Routern.

Das ist meiner Meinung nach ein guter Vorschlag, er würde auch dem Tagging von Ampeln entsprechen: highway=traffic_signals

Wobei man aber klären müsste, was der passende englischsprachige Begriff für Bahnschranke und für eine Schranke vor einer Brücke wäre (gibt es für letzteres überhaupt einen deutschen Begriff?).

Wenn man den Google-Translator bemüht, spuckt der als Übersetzung für Bahnschranke den Begriff “bridge barrier”, ebenso wenn man Brückenschranke eingibt “bridge barrier” - so eine Übersetzung ist mit Vorsicht zu genießen. Ich habe daher mal “Schlagbaum” eingegeben und als Ergebnis “turnpike” erhalten…

Das Tagging-Schema für Bahnübergänge den Begriff “barrier”. Daraus würde sich dann highway=barrier ergeben. Aber das erscheint mir wiederum missverständlich zu sein, was man wiederum nur mit Zusatzattributen klarstellen können. Die dürften aber nicht barrier=… lauten, denn dann hätte man wieder eine ganz normale Straßensperre daraus gemacht.

Als Abgrenzung zu einer Parplatzschranke, einer Schranke an einer Mautstation oder einer Schranke an einem Waldweg sehe ich den Umstand, dass bei Parkplatzschranken… das zum Durchfahren eine bestimmte Bedingung erfüllt werden muss: Gebühr zahlen oder Zugehörigkeit zu einem berechtigten Personekreis, der den Schlüssel für die Schranke besitzt.

Bei einer Bahnschranke oder darf aber jeder durchfahren, solange sie nicht vorübergehend geschlossen ist. Man muss dafür keine Gebühr zahlen, keine Berechtigung nachweisen und keinen Schlüssel besitzen. Es ist im Grunde von der Funktion her nichts anderes als eine Ampel. Bei Bahnübergängen werden ja auch Lichtzeichen und Schranke folgerichtig in der gleichen Funktion genutzt.

Leider ist das Tagging-Schema von Bahnübergängen nicht so einfach hierauf zu übertragen. Dort gibt es “railway=level_crossing” für den Bahnübergang für Autos, daneben “railway=crossing” für Bahnübergänge für Fußgänger und “railway=railway_crossing” für zwei sich ohne Weiche kreuzende Bahngleise.

Auch gäbe es einen Konflikt, wenn ein Bahnübergang mit Lichtzeichen und Schranke versehen ist. Was trägt man dann ein? highway=“Lichtzeichenanlage” oder highway=“Schranke”? (Wobei es meines Wissens auch unüblich ist, highway=give_way einzutragen, wenn man highway=traffic_signals eingetragen hat, obwohl an vielen Ampeln zusätzlich ein Vorfahrt-gewähren- oder ein Stoppschild angebracht ist für den Fall, dass die Ampel aus ist. Entsprechend könnte man bei einer Bahnschranke auf das Erwähnen des roten Blinklichts verzichten, wenn eine Schranke eingetragen ist)

Wie geht man mit Bahnübergängen um, bei dem es weder Schranke noch Lichtzeichen gibt, bei denen es aber eine Haltelinie gibt, an der man zu warten und zu schauen hat, ob gerade ein Zug kommt (highway=give_way oder highway=stop oder etwas anderes, weil dort ja weder ein Vorfahrgewähren-Schild noch ein Stopschild steht sondern statt dessen ein Andreaskreuz? Wobeim eines Wissens zumindest in Deutschland das Andreaskreuz eher dem Vorfahrt-gewähren-Schild entspricht. Meines Wissens gibt es keine Pflicht, grundsätzlich zum Stehen zu kommen wie bei einem Stopschild.)