"tracks" für Bahngleise überflüssig

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.

Die ITO-Karte zu tracks=2 wurde mittlerweile entfernt. http://www.itoworld.com/map/group/1

Die falsche Verwendung von tracks=2 ist mittlerweile auch ein Thema auf der Talk-Mailingliste. https://lists.openstreetmap.org/pipermail/talk/2015-October/074453.html

In diesem Moment gibt es einen Vorschlag, alle tracks tags in den Niederlanden zu entfernen. Der Grund dafür ist, dass alle Spuren in den Niederlanden schon da sind. JOSM zum Beispiel sagt, dass man layer=0 nicht muss taggen. Was ist Ihre Meinung als Deutscher Community?

Im Namen der Niederländische Community, bereits vielen dank für Ihre Meinung.

Wenn ihr (NL community) euch darauf geeinigt habt, spricht nichts dagegen, diese redundante Info zu entfernen.

Genau. Wir waren nur neugierig, wie Sie dies bereits gelöst haben.