Bahnschranken wie eintragen

Ja, der muss anders. Steht im englischen Wiki auch nicht. Keine Ahnung, wer sich das ausgedacht hat.

Das steht schon seit 2010 im deutschen Wiki: https://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Abarrier%3Dlift_gate&type=revision&diff=557129&oldid=516218

Ich hab’s mal geändert: https://wiki.openstreetmap.org/w/index.php?title=DE%3ATag%3Abarrier%3Dlift_gate&type=revision&diff=2157577&oldid=2079540

Und für Grenzschranken bleibt es also bei Lift_Gate ?
Mit welchen weiteren Merkmalen werden diese dann eingetragen, ohne daß es beim Routing zu “Grenzsperrungen” kommt.
Access=yes ?

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.

Danke!

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

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.

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 ;-)

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

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

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.