"tracks" für Bahngleise überflüssig

Hallo jaimemd,

Die Karten von ITO sind “relativ alt”. Die gab es schon, als ich vor knapp vier Jahren mit dem Mappen angefangen habe. Damals war in Deutschland die Umstellung auf zweigleisiges Mappen von Bahnstrecken noch nicht ganz fertig (v.a. User BurnyB hat dafür bundesweit große Beiträge geleistet, auf die ich vielerorts beim Mappen heute noch stoße). Andere Länder waren vermutlich noch nicht so weit. Die Karte wurde also entworfen, als tracks=* noch “richtig” verwendet wurde und hatte also eher – vermute ich – QA-Zwecke. Am liebsten würde ich ITO bitten, die Karte einfach abzuschalten, aber andere Regionen sind halt noch nicht so weit wie wir und können die Karte daher sinnvoll nutzen.

Anekdote am Rande: Es gab Zeiten, da diskutierte man in der deutschen Community, ob man überhaupt bei Bahnstrecken jedes Gleis einzeln mappen sollte.

Das Folgende ist bloß ein grobes Konzept, dazu gibt es noch keine Versuche und keinen Code!

  1. Man könnte um alle Gleise einen Buffer legen, der einen etwas größeren Radius als der übliche Gleismittenabstand hat.
  2. Diese Buffer verschneiden.
  3. Die Schnittfläche wird als Rastergrafik gerendert.
  4. Mittels Skelettierung wird die Mittelachsen dieser meist länglichen Flächen ermittelt. [1]
  5. Kurze Linien werden verworfen. Diese entstehen nämlich, wenn ein Way gesplittet ist. Speichere die übrigen Linien. (Diese Linien sind Strecken mit zwei oder mehr parallelen Gleisen)
  6. Bilde um diese Linien wieder Buffer mit demselben Radius wie in 2.
  7. Verschneide diese Buffer und ermittle die Mittelachsen.
    1. Kurze Linien werden verworfen. Diese entstehen nämlich, wenn ein Way gesplittet ist. Speichere die übrigen Linien. (Diese Linien sind Strecken mit drei oder mehr parallelen Gleisen)
  8. Wiederhole 6. bis 9. so oft, bis keine Linien mehr übrig bleiben.

Es gibt neben der ITO-Karte noch eine zweite Karte die tracks=* auswertet – der Railway-Infrastructure-View des OSMI. (siehe Taginfo-Projekt-Tab) Außerdem wissen wir nicht, ob nicht auch andere Datennutzer diese Daten intern nutzen. Daher sollte man sich an die Definitionen halten und nicht einfach das Tag anders verwenden, denn das ist Tagging für den Renderer.

Ich bin einer der OpenRailwayMap-Entwickler. Bisher habe ich tracks=* nicht so auf dem Schirm gehabt, aber ich könnte mir vorstellen tracks=2 entsprechend der klassischen Definition zu nutzen und bei Gleisen mit tracks=2 zwei parallele Linien zu zeichnen.

Viele Grüße

Michael

[1] ggf. müssen kurze Zweige des Graphenbaums entfernt werden

Es gab auch den Vorschlag, die Schienen einzeln zu mappen und damit die Angabe der Spurweite einzusparen :wink:

Dieser Algorithmus liefert nicht das gewünschte Ergebnis. Damit werden auch eingleisige Strecken mit parallelem Industriegleis als zweigleisig errechnet.
Selbst wenn es einen korrekten Algorithmus gäbe, müsste er für jede Datennutzung (Mapnik, Overpass Abfrage, JOSM Filter, …) eingebaut werden.
Warum sollte man gerade in diesem Fall auf ein einfach auszuwertendes Tag verzichten?
Wir speichern in diversen Tags sehr viele redundante Informationen, die sich (im Gegensatz zu diesem Problem) trivial errechnen lassen.

Hier stimme ich Nakaner zu. Wer “tracks” entgegen der Definition benutzt, verursacht Probleme und erzeugt keine auswertbaren Daten.

das würde zumindest eine positive Antwort auf meine hier mehrmals gestellte Frage ergeben

Da würde man wahrscheinlich so ab zoom level 16 oder 17 was sehen (bei Mapnik immerhin schon ab etwa 14)
Ich hatte eher an so etwas wie zoom level 11 gedacht, um zu meinen vorgenannten Streckenbeispielen etwas sehen zu können.

Am Rande: OpenRailwayMap füllt sich ja international gesehen doch langsam mit Informationen. Der Teil Signale und Sicherungssysteme ist aber wohl eine weitgehend deutsche (um nicht zu sagen westdeutsche) Angelegenheit? Ein EZMG-Signal als Hp-Lichtsignal zu zeigen finde ich schon etwas betrüblich. Aber das du in Nebra warst ist schon cool …
Als in Kanada das schwere Unglück mit dem Kesselwagenzug gab, habe ich versucht mir die Gegebenheiten in osm anzusehen. Interessante Vorstellung, dass da auch Signale hätten dabei sein können. Da sind wir aber noch recht weit davon entfernt.

Grüße aus dem Osten

Wenn du genau hinschaust, siehst du, dass bei den Icons für Hp-Lichthauptsignale, die kein Hp 2 anzeigen können, das grüne Licht oben links ist. Die Icons für Hl-Signale fehlen noch in der Legende. Die EZMG-Signale in Nebra habe ich nach einer Ortsbefahrung vor gut einem Jahr als Hl-Signale gemappt, weil sie funktional solche sind.

Viele Grüße

Michael

Moin,

Schon bei der von Dir zitierten ITO-Karte:
Sie zeigt nur in kleinen Zoom-Stufen vermeintlich korrekte Daten an.
Zoomt man weit genug herein, kann man auch dort die Probleme erkennen:
2 doppelgleisige Strecken nebeneinander - einfach, weil die ITO-Karte sich an die Definition hält!

+1
Es spricht ja nichts dagegen, sich ein passendes neues Tag auszudenken - Vorschlag siehe oben.
Auch damit kann man dann entsprechende Karten erstellen - sogar relativ einfach mit Overpass und CSS.

Gruß
Georg

Das kommt darauf an, womit man den Algorithmus “füttert”. Wenn man nur die durchgehenden Hauptgleise zählen möchte, dann kommt dürfen die Ausgangsdaten für Schritt 1 nur Gleise sein, die ein usage=* und kein service=* haben.

Oder es gibt halt einen Dienst, der diese Daten berechnet und als vorverarbeitete Daten zur Verfügung stellt.

Noch ein Hinweis: Es gibt auch noch das (recht junge) Tag railway:preferred_direction=forward/backward/both. Damit wird die Regelfahrtrichtung eines Gleises getaggt (in Bezug auf die Richtung des OSM-Ways).

Ich finde diese Idee sehr gut und als Lösung sicherlich die beste.
Falls jemand das Umwandeln zentral erledigen will, kann er alles einbeziehen, was ich jemals mit tracks=* gekennzeichnet habe. Eigentlich auch von WJtW und evtl. leojth, aber die haben mir noch nicht geantwortet. Wenn es dann eine Karte dazu gibt, mache ich damit auch weiter. Dass beim Hereinzoomen dann immer noch zwei als zweigleisig gekennzeichnete Linien zu sehen sind, wird dann aber evtl. auch so sein. Ich finde das auch nicht schlecht, weil man dann leichter (wenn auch nicht mit letzter Sicherheit) zwei zusammengehörige Gleise erkennen kann. Das ist auch interessant, wenn sie etwas auseinander liegen, zum Beispiel bei zwei einröhrigen Tunnels, mit etwas Abstand errichtete Brücken (kommt in Russland ganz häufig vor) oder Ein- bzw. Ausfädelungen.

Die tracks-Definition in der bisherigen Form wird zwingend für Straßenbahn/Tram benötigt.
Die Schienen sind sehr oft in der Straße eingebettet.
Liegt keine bauliche Trennung vor, so wird die Straße durch eine Linie repräsentiert.
Das gleiche gilt für die Gleise der Tram! Daher tracks=2 bzw. Anzahl Gleise die da vorhanden sind.

Die Position, Darstellung, usw. wird mit tracks=* natürlich nicht beschrieben. Der Renderer könnte aber im Zweifel einfach 2 Gleise aus dem Mittelwert berechnen was häuftig gar nicht mal so verkehrt ist. Ganz genau wird es natürlich nur wenn man einzelne Gleise mappt.
→ tracks=1 macht überhaupt keinen Sinn → entfernen.

Analog zum lanes-Schema gibt es ein tram:lanes-Schema.
Es können damit x-beliebig viele tracks auf einer Straße, die ausschließlich eine Linie ist (wie die meisten Straßen), definiert werden.

Mich wundert die Diskussion auch deshalb weil die meisten mehrgleisigen Strecken mal mit “einem” Gleis und tracks=2 angefangen haben.
Und das ist immer noch per Definiton korrekt! Entspricht halt nur nicht dem Micromapping…

Die Anzahl an vorhandenen Gleisen an jedes Gleis zu pappen ist außerdem blanke Redundanz der Informationen. Das wäre ein klassischer Fall für eine Relation. Streckenabschnitte defininieren und da dann alle relevanten Informationen reinpacken. Spurbreite, Elektrifizierung, Sicherungssystem, Geschwindigkeiten, … Nur mal so als Idee…

Wenn in osm die Entwurfsgeschwindigkeit sagen wir mal des Streckenbauprojektes gemappt würde, könnte ich mir das vorstellen. Jedoch die Geschwindigkeit wechselt immerzu und die Anzahl der Gleise auch manchmal. Das gäbe entsetzlich viele Schnipsel für die man je eine Relation bräuchte. Diese könnte schwerlich sinnvoll benannt werden. Ich glaube kaum, dass man sich da noch zurechtfindet. Für Sicherungssystem und Elektrifizierung geht das vielleicht.

Ich war schon kurz davor zu schreiben “Akzeptiert”. Wenn hier mal doch zwei Gleise gezeichnet sind, der Renderer bei tracks=2 darstellt und fälschlicherweise tracks=2 hinzugefügt wird, gibt es ein echtes Problem.

Dann habe ich doch gedacht, es wäre doch mal nett, schnell die Straßenbahnsysteme mit zweigleisigen Strecken durchzusehen, wie sich die Situation in etwa darstellt, da ich mich mit Straßenbahnen in osm bisher kaum beschäftigt habe.

Ergebnis (wie gehabt ohne Sicherheit, dass es nicht doch irgendwo anders sein könnte): Meistens sind schon jetzt 2 Gleise gezeichnet, was den Bedarf an Renderen die zwei Gleise für einen Weg darstellen schon mal gering hält. tracks wird so gut wie nie vergeben. Solch eine Renderer wäre also etwas für so weit ich gesehen habe 2 Exoten.

Wenn es den Renderer für die Doppelspur geben würde, wäre das sicher ein Anreiz, mehr tracks=* zu vergeben. Da könnten noch 9 von meinen besuchten Städten dazukommen. Ich denke, das lohnt sich trotzdem nur, um dem Prinzip Genüge zu tun. Wenn es wirklich Bedarf gäbe, hätte es schon jemand gemacht.

Die Wahrscheinlichkeit, dass tracks=2 hier falsch vergeben wird und daraufhin falsch gerendert wird, halte ich somit für äußerst gering.

Hier meine Liste zweigleisiger Straßenbahnen straßenbündig in Mittellage,
falls das jemanden interessiert (wie gesagt nur Stichproben, sieht mir aber so aus als würde das je Stadt einheitlich gehandhabt):

  • zwei Wege für zwei Gleise:

zwei Gleise einzeln gezeichnet rechts und links neben dem Weg für die Straße: Jena, Erfurt, Freiburg im Breisgau, Bremen, Dresden, Halle, Leipzig, Bielefeld, Duisburg, Mülheim, Bochum, Bonn (gilt eigentlich als Beispielstadt für korrektes ÖPNV-Mapping), Chemnitz, Plauen im Vogtland, Görlitz, Berlin, Rostock, Köln, Frankfurt am Main, Heidelberg, Stuttgart, Krakow, Poznan, Szczecin, Breslau, Mailand, Olomouc, Moskau, St. Petersburg, Brüssel, Ulan-Ude, Wien, Bratislava, Budapest, Basel, Zürich, San Francisco, San Diego

Richtungsfahrbahnen der Straßen einzeln gemappt jeweils mit einem Straßenbahngleis: Amsterdam, Zwickau

zweit Gleise sepaarat gezeichet, immer in Mittellage, Richtungsfahrbahnen für Straßenverkehr in Seitenlage: Strasbourg, Dessau

  • ein Weg für zwei Gleise

eigener Weg mit denselben Wegpunkten wie die Straße ohne tracks: Duisburg

eine Line ohne tracks tag neben der Straße: Kairo

Straße auch als Straßenbahn getaggt ohne tracks tag: Krefeld, Schwerin, Potsdam, Liberec, Prag, Lwow, Rom, Cluj-Napoca, Alexandria

gleiches mit tracks=2: Düsseldorf, Riga
Das sind diejenigen, um die es konkret geht.

Neben der Karte von ITO steht klar und deutlich und in nicht ganz kleiner Schrift:

Heißt das, dass alle, die tracks>=2 in falscher Art und Weise verwenden, das nicht gelesen haben? :slight_smile:

Ist ja schon gut …

Mich bringt gerade das aber noch auf eine andere Spur: Der Zweck von tracks=* muss ja doch irgendwie auch mit der Anzahl der Streckengleise zu tun gehabt haben, sonst wären die Jungs von ITO wohl nicht auf die Idee gekommen, diese Karte zu machen. Denn deren Zweck scheint ja doch zu sein, die Streckengleisigkeit anzuzeigen und nicht dem Mapper zu zeigen, wo er noch ein zweites Gleis dazu zeichnen kann. So interpretiere ich das “Leider klappt es jetzt beim Mappen des gesamten Gleisnetzes nicht mehr.”

Dann hätte tracks=* ursprünglich zwei Bedeutungen gehabt (1. Anzahl der Gleise pro Weg, 2. Anzahl der Streckengleise). Beim Mappen des Streckennetzes war zufällig beides dasselbe. Als mit dem Mappen des Gleisnetzes angefangen wurde, ging die zweite der Bedeutungen verloren.

Wenn es nicht tracks sondern tracks_per_way geheißen hätte, wäre klar, dass es nur um die erste Bedeutung geht und niemand würde auf die Idee kommen, das anders zu verwenden. Dann gäbe es auch diese ITO-Karte nicht oder es würde verschämt dabei stehen: “Wir versuchen mal diese Information für einen etwas anderen Zweck auszuwerten.”

Diese Variante scheitert bei zwei parallelen, eingleisigen Strecken, die es in der Umgebung von Bahnhöfen häufiger gibt.

Aber warum sollte man ausgerechnet zu diesem Zweck auf eine explizite Angabe verzichten und einen komplizierten und fehlerträchtigen Algorithmus einsetzen?

Wenn man Speicherplatz sparen will, sollte man auf >10.000.000 “addr:country”-Tags verzichten, die sich trivial berechnen lassen.

Es ist sicher in Prinzip richtig, diese Info einer Route zuzuordnen. Ich sehe aber außer dem von seawolf genannten noch zwei Probleme:

  1. Wenn das gerendert wird entsteht ein Linie in der Mitte wo dann kein Gleis ist und zum Beispiel mittige Inselbahnsteige überdeckt werden.
  2. Da gerade die Ausnahmen und Besonderheiten interesssant sind, müsste diese Route zerstückelt werden, z. B. der eingleisige Abschnitt der Frankenbahn

Ein alternatives tag für die Zahl der Streckengleise gibt es schon, nur mit sehr verkorkstem Namen: passenger_lines (dazu gibt es sogar eine eigene ITO-Karte und eine kurze deutsche Forumsdiskussion). Vom Erfinder habe ich mittlerweile eine Antwort bekommen. Ihm ging es genau so wie mir.

Dann hat es noch jemand mit “lanes” versucht. Das wird aber offenbar gerade m.E. zu Recht wieder rückgängig gemacht.

Den Vorschlag von GeorgFausB mit line_tracks finde ich nach wie vor am besten. Das muss nur den Weg ins wiki finden und es muss eine Karte geben, sonst wird da wieder nichts richtiges draus.

Hallo jaimemd,

passenger_lines kannst du von mir aus taggen, line_tracks auch, da das kein existentes Tagging umdefiniert.

Ich werde dieses Tag vorerst nicht taggen, Signale, Höchstgeschwindigkeiten fürs Rendering und Hektometertafeln fürs Geocoding machen mehr Spaß.

Viele Grüße

Michael

Gut. Dann sollte nur niemand anderes was dagegen haben und ich würde versuchen möglichst schnell alle meine tracks=* in passenger_lines=* umzuwandeln mit einer Erläuterung, dass ich das für ein Provisorium halte.

Also bitte noch nicht weiter reverten oder löschen!

Ich bin mittlerweile in Diskussion mit noch einem Schweizer und einem Engländer, die sich mit der Ein-/Mehrgleisigkeit oder tracks=* beschäftigt haben und habe bei ITO angefragt, was man dort von der Sache hält.

Ich sehe den Sinn von OSM unter anderem darin, dass jeder das bearbeitet, was ihm Spaß macht.

Viele Grüße

Ich entnehme dem die Information, dass sich da sehr wahrscheinlich ein Orts- oder Bahnkundiger schon eingehender mit beschäftigt hat. Bei einem Gleis ohne tracks ist das weniger eindeutig. Implizierte Tags haben wir reichlich, trotzdem sind die aus verschiedenen Gründen nicht gleich unsinnig. (Autobahn+oneway=yes und dergleichen)

Wenn man kennzeichnen möchte, dass ein osm way genau ein Gleis repräsentiert, kann der mit track_detail=yes gekennzeichnet werden. Außerdem gibt es landuse=railway. Dieses Gelände und auch Eisenbahngleise sind nicht öffentlich zugänglich. Anders als bei Straßen ist deswegen OSM keine Grundlage, um Eisenbahninfrastruktur zu benutzen oder eine Nutzung zu planen (soweit ich weiß). Deswegen ist es eigentlich egal wie viele Gleise da liegen. Die in OSM hinterlegten Informationen zu Eisenbahnen legen zwar die Vermutung nahe, dass man nur ein Schienenfahrzeug beschaffen, beim Netzbetreiber Fahrplanrassen bestellen und losfahren bräuchte, aber dem ist in der Realität sicher nicht so.

tracks=* ist bei gleisgenauem Mapping von zweigleisigen Strecken schlicht nicht anwendbar: tracks=1 würde bedeuten, dass die Strecke eingleisig sei, tracks=2 würde bedeuten, dass da zwei zweigleisige Strecken seien.
Stattdessen gibt es detail=track, was imo inzwischen so wie oneway=no anwendbar ist.

Doch, so ungefähr läuft das. Ist halt nur nicht so einfach ein Eisenbahnfahrzeug zugelassen zu bekommen. (Suchbegriffe: EIBV, EVU-Sicherheitsbescheinigung)

Nachdem jetzt schon wieder ein User großflächig (in Deutschland und den Niederlanden) tracks>2 missbraucht hat, habe ich bei ITO per Mail um die Abschaltung der tracks-Karte gebeten. Gegen passenger_lines=* habe ich nichts, die Freunde dieses Tags sollen machen, was sie wollen. Aber sie sollen nicht existierende Daten beschädigen (auch nicht indirekt durch Tag-Missbrauch).

Anhand der Changesets meines Putz-Accounts Nakaner-repair kann man erkennen, welcher User schuld ist.