"tracks" für Bahngleise überflüssig

Erstmal ja…jaimemd hat ausgeführt, dass er sich erstmal in der Schweiz bei den dortigen Usern schlau machen will, DAS sollte man ja wohl erstmal abwarten. Du bist immer ziemlich schnell…nimm mal einen Gang raus!

Moin,

ich würde den Changeset nicht reverten, sondern als Basis nutzen und die entsprechenden Tags in neutrale (z.B. line_tracks=* umwandeln, um die/seine vorhandene Information zu erhalten.

Die Definition eines langjährigen Tags umzubiegen ist nun mal ein No-Go - zumindest, so lange er nicht alle 37.870 Verwendungen (!= 1) weltweit betrachtet hat.
Wie soll man je wieder feststellen, wie der Tag nun tatsächlich gemeint ist/war?

Hallo in die Runde,

hier die erste Rückmeldung. Meine bisherige Recherche zeigt, dass wirklich verantwortlich für diesen tag nur wenige Mapper sind, die sich in Großen und Ganzen jeweils nur ein Land vorgenommen haben (außer mir). Davon haben vier im Sinne der Definition getaggt und drei dagegen (mich eingeschlossen). Ich habe mir da nur Gegenden angeschaut, wo der tag in einem ganzen Netz vorkommt. Ich müsste allerdings nochmal genauer in Tschechien, China und Indien nachschauen.

Meine Vorstellung haben ich dem unten zitierten offenbar noch nicht verständlich vermitteln können, was aber auch nicht vorrangig Zweck dieses Kontaktes war. Hier geht zumindest eindeutig draus hervor, dass für diesen Mapper der tracks tag keine wirkliche Bedeutung hat und dass er auch keine Funktion kennt, wo dieser tag verwendet bzw. ausgewertet wird.

Das klingt alles sehr gut und ich will nicht bestreiten, dass so gearbeitet wurde. Ich selbst habe jedoch oftmals railway=rail und nichts weiter dazu vorgefunden und im Verlaufsprotokoll habe ich jetzt auch oft gesehen, dass auch in Mitteleuropa der tracks tag oft nicht im Zusammenhang mit den oben beschriebenen Änderungen bearbeitet wurde. Stattdessen hat sich jemand diesen tag separat für ein ganzes Netz vorgenommen.

Wenn ich mich für irgendeine Gegend interessiere, schaue ich zuerst in Mapnik nach und wenn mir da etwas nicht gefällt, versuche ich es besser zu machen. Mit der tracks-Information im Sinne der Definition habe ich nie etwas anfangen können, sondern nur dem was bisher eingezeichnet is, den Sateillitenbildern und den Informationen der Eisenbahnunternehmen (v.a. Fahrplan).

Es gibt dann noch die (in meinen Augen) Unsitte, Gleise von zweigleisigen Strecken mit oneway=yes zu kennzeichnen. Wozu das gut sein soll ist mir völlig schleierhaft, da sie sehr wohl in der Gegenrichtung befahren werden dürfen und dies für Privatpersonen sowieso uninteressant ist. Die dürfen Eisenbahninfrastruktur weder in der einen noch der anderen Richtung selbständig benutzen.

Den Punkt 5 finde ich nicht ganz korrekt. Die Viergleisigkeit existiert nämlich (nach meiner bisherigen Erkenntnis) nur in der Theorie, da sie keine praktische Verwendung findet. Nur ein Ärgernis für dich und deine Kollegen scheint es zu sein, das möchte ich natürlich nicht. Aber über das oneway versuche ich mich auch nicht oder möglichst wenige zu ärgern. Vielleicht hat es ja doch einen Sinn

Lt. wiki bedeutet Tracks:
Anzahl der Gleise, nur wenn ein Way Way mehrere parallele Gleise in der Realität repräsentiert, z.B. als vereinfachende Angabe bei mehrgleisigen Strecken. Ohne diese Angabe wird eins angenommen. Nicht bei Bahnanlagen verwenden, in denen jedes Gleis einzeln gemappt ist!

Dies bedeutet doch, wenn bei einer zweigleisigen Strecke zwei Gleise (railway=rail) gemappt sind, dann ist tracks überflüssig ODER muss mit tracks=1 getaggt werden.
Wenn bei einer zweigleisigen Strcke nur “eine Linie mit railway=rail” gemappt ist, dann wird der Tag tracks=2 hinzugefügt.
Praktische Verwendung oder nicht ist nach der Sachlage unerheblich, wichtig ist, wie es im wiki dokumentiert und abgestimmt wurde, denn dass ist eine Richtschnur zur Einheitlichkeit.

“oneway” an einer Railwaystrecke kann man m.E. in den meisten Fällen ohne Rücksprache getrost löschen, da dieses Tag offensichtlich zumindest in Deutschland fehlerhaft benutzt wird.

Kann man sich darauf einigen?

Hallo Thoschi,

Disclaimer: Ich habe gestern wegen dieser Diskussion DE:Key:tracks und Key:tracks im Wiki editiert. Dabei habe ich die Formulierung verbessert und versucht Missverständnisse zu vermeiden. Die beiden Seiten sind recht jung. Viel länger schon ist der Key in den MapFeatures dokumentiert. In der englischen Version wurde er von PealRinger am 24. Januar 2012 eingefügt. Nicht, dass jetzt jemand meint, ich würde das Wiki umschreiben, um danach mit ihm zu argumentieren.

Dem stimme ich zu. Anmerkung: In Südwestdeutschland wird oft detail=track verwendet, wenn jedes Gleis einzeln gemappt ist. Die OpenRailwayMap-Validationsregeln für JOSM (werden in den JOSM-Einstellungen angeboten) bieten an, tracks=1 zu entfernen, wenn detail=track getaggt ist.

Bei Eisenbahnen (EBO) stimmt das. Selbst wenn es keine Signale für “Fahrten auf dem Gegengleis” (Eisenbahnersprech für Fahrten auf dem linken/falschen Gleis) gibt, kann ein Zug auf dem Gegengleis fahren. Er braucht dazu halt eine schriftlichen Befehl (wird oft per Funk diktiert). Deshalb ist oneway=yes bei railway=rail falsch. Bei Straßenbahnen (BOStrab) kenne ich mich nicht so gut aus, um das bestätigen zu können.

Viele Grüße

Michael

Die Diskussion finde ich so weit sehr interessant. Ich habe nicht vor, mich zu streiten. Ins wiki brauche ich nicht nochmal zu schauen, dessen Text wird ja schon hier immer wieder rezitiert. Ich habe auch wirklich begriffen was da drin steht.

Du ergänzt wieder tracks=2 an den Gleisen. Dadurch wird die Strecke nach Definition von tracks=2 viergleisig.

Ich möchte das aber wirklich gerne wissen: Wer (Mensch oder Maschine) und zu welchem Zweck (Eisenbahnatlas erstellen, das Ausmaß von Landschaftszerstörung ermitteln, einen Selbstmord planen) nimmt die 4 Gleise an? Die ITO-Karte zeigt zwei!

Es geht mir gerade nicht darum, im Wiki zu lesen sondern etwas sinnvolles mit Geodaten zu machen.

Damit man mit den Geodaten etwas sinnvolles machen kann, braucht es klare Definitionen und Mapper, die sich an diese Definitionen halten, sonst sind die Daten wertlos. Auf den ITO-Maps mag es zwar schön aussehen, andere Renderer und Programme könnten mit den falschen Attributen aber Probleme haben.

http://wiki.openstreetmap.org/wiki/DE:Taggen_f%C3%BCr_den_Renderer

Das ist nur eine Karte von hunderten.

Ein Beispiel würde mir reichen.

, aber eine die etwas mit diesem tag macht!

Das Tag “tracks” ist seit langem definiert. Wir ändern nicht einfach Beschreibungen, nur weil es “gut” aussieht. Lies mal die ganzen Beiträge bzgl. bus_stop, das ist etwas ähnliches.
Kannst Du ausschließen, dass andere Karten tracks genauso nutzen wie ITO? Und wer sagt, dass ITO das Tag korrekt auswertet? Nur weil es bei Deinen Beispielen scheinbar gut aussieht.

Hallo Thoschi,

ITO wertet tracks ganz einfach so aus wie es in den Daten steht: tracks=1 ist blau, tracks=2 orange, tracks=4 rot. Somit ist eine zweigleisige Strecke mit einem Gleis und tracks=2 orange (korrekt und sieht gut aus), eine eingleisige mit tracks=1 blau (sieht auch gut aus), eine zweigleisige Strecke mit zwei gezeichneten Gleisen und tracks=1 blaus (ist korrekt, gefällt mir aber nicht) und eine Strecke ohne den tag zeigt fehlende Daten (sieht für mich zumindest auch nicht so gut aus), zweigleisige Strecke mit tracks=2 ist orange (sieht gut aus ist aber wie hier ausfürlich diskutiert falsch.

Ich weiß nicht ob da jemand mal nachgeschaut hat, um zweigleisige Strecken zu finden, wo noch das zweite Gleis zu zeichnen ist. Dann würde ich das Problem verstehen Ich würde das wie oben schon beschrieben nicht so machen.

Vielmehr hätte ich gerne eine Karte, wo man z.B. sehen kann,

  • wie viele Gleise die Strecke von Amsterdam nach Utrecht hat
  • wie sich die Ausgangssituation der Diskussionen um einen zweigleisigen Ausbau der Gäubahn darstellt, also in welchen Abschnitten die ein- und zweigleisig ist (in Stuttgart ist sie zweigleisig, aber wenn man über den Ausbau diskutiert muss sie auch irgendwo eingleisig sein)

Momentan frage ich aber danach, wo eine fehlerhafte Verwendung von tracks=2 zu Prblemen führt außer dass es gemäß der Definition falsch ist. Wie gesagt, es reicht ein Bespiel.

Ein anderes Beispiel könnte so aussehen: Gemäß Satzung müssen Bäume neben öffentlichen Wegen so verschnitten werden, dass eine festgelegte Mindesthöe (sagen wir mal 3 Meter) gewährleistet ist, aber das wird von einem Anwohner missachtet und sein Strauch wächst in Höhe von 2 Metern über den Bürgersteig. Der müsste nun eigentlich die Äste absägen, weil ja jemand der besonders groß ist dagegen laufen und zu Schaden kommen könnte. Veilleicht kommt da aber niemand vorbei oder ist nicht so groß oder hat den Ast vorher gesehen und umläuft ihn und so wird der Anwohner sagen, dass das nur in der Theorie ein Problem ist und den Ast erst einmal nicht absägen. Nun bin ich aber tatsächlich in der Dunkelheit mit meinem Kind auf den Schultern dagegen gelaufen und das Kind hat geweint. Entsprechend dieser Begebenheit möchte ich jetzt nicht wissen, ob es diese Vorschrift gibt (das weiß ich schon), sondern ob tatsächlich ein Problem aufgetreten ist. Geht das?

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.