Wenn ich das in Belgien ansehe, wo alle Haltestellen völlig ausgewertet schon vorhanden sind als Nodes neben die Wege, gemappt als
highway=bus_stop
public_transport=platform
bus=yes
mit entsprechend role=platform
kommt diese Darstellung damit nicht zu recht. Schade weil mehr als 50% der Routen in Belgien schon erfasst sind.
Polyglot
In Belgien finde ich highway=bus_stop mit public_transport=platform und dazu die Routen-Relationen, die aber nur Wege enthält. Gezeichnet werden damit nur die Fahrwege, nicht aber die Kreise für die Haltestellen. Ich weiß nicht wie ich die Haltestellen mit den Relationen in Verbindung bringen sollte – außer eben nur über ihre Nähe zum Fahrtweg. Beispiel wäre Relation 3825790.
Dann finde ich noch Routen ohne Relationen für die nur die Haltestellen als highway=bus_stop mit public_transport=platform erfasst sind. Diese werden nicht gezeichnet. Hier fällt mir nicht ein wie der Fahrweg aus den OSM-Daten ableitbar wäre.
Was ich noch machen könnte, wäre auch Relationen wie 2904977 mit den Pfeilen zu versehen. Das wären Relationen mit Fahrtwegen und Nodes in der Rolle platform. Meist du diese Fälle?
Sehe ich das eigentlich richtig, dass ref:TECL die Haltestelle und die Fahrtrichtung identifziert?
Ja, die meisten sind wie 2904977 gemappt. Rezent bin ich damit angefangen um die Haltestellen erst zu setzen. Die kamen hinterher weil das länger Zeit der Art vom sortieren war in JOSM. Heutzutage werden die HS erst sortiert.
Der Grund für mich um das zu änderen ist aber das es im Expert Mode seit einigen Monaten die Möglichkeit gibt um ab eine bestimmte Stelle im Relation Editor bis am Ende zu sortieren. Das ist sehr praktisch um die Ways in die richtige Reihenfolge zu bekommen, auch wenn Schleifen, usw. vorkommen.
Die 3825790 ist eine die ich noch nicht umgewandelt hatte. Die sollte noch nicht der public_transport:version=2 gehat haben. Da ist etwas schiefgelaufen.
ref:TECL ist der Identifier die TEC Liège-Verviers an die HS vergeben hat. Es gibt ziemlich viele HS die zwei unterschiedliche refs haben. z.B. ref:TECL und ref:TECN (Namur) oder ref:TECX (Luxembourg), oder auch ref:De_Lijn für der Flämischen Reisegesellschaft.
Zwei HS an beide Seiten der Strasse werden immer unterschiedliche refs haben. In Flandern sind die auch angegeben. Daher stammt es das wir Nodes neben die Wege haben die die Haltestellen darstellen. Die stop_position ist hier immer als viel weniger wichtig gesehen. Weil ich die Details nur einmal eintragen will, gehen die auf die highway=bus_stop/public_transport=platform/bus=yes und nur da. Das ist in Deutschland völlig anders gemappt, aber (noch) nicht überall.
Die Routen wo keine Wegen drinn sind, sind wahrscheinlich on_demand. Da kann der Faher selber unterscheiden wie er am besten die benötigte HS bedient, also keine feste Route. Das wird meistens als ein Gebiet angegeben auf die Karte, aber die sind nicht sehr wichtig.
Was ich denke dass interessant sei, ist um route_ref zu zeigen. Dann seht man sofort welche Linien eine HS bedienen. Da wird angeblich in Deutschland aber auch einen anderen Tag benutzt, etwas mit lines drinn.
Jo
Der Name der Haltestellen und route_ref werden nun bei hohem Zoom angezeigt und die Pfeile werden auch zwischen Nodes der Rolle platform gezeichnet.
Es ist im Hinblick auf ein Tagging-Schema gut zu wissen, dass mehrere ref für dieselbe Haltestelle in Verwendung sind.
Falls bei euch freie Fahrplandaten existieren, wäre über diese Referenzen ein kombiniertes Routing mit OSM-Daten und Bussen/Bahnen theoretisch möglich. Es bräuchte nicht einmal OSM-Relationen dafür.
Die gefällt mir gut. Damit kann man Fehler finden, die mein Programm “putr” nicht findet.
Das ist OK für PTv2, da dürfen sowieso keine forward/backward auftreten. Ways mit Rolle sind in PTv2 nie Fahrwege, man könnte sie also auch ruhig weglassen. (Echte PTv1 gibt es fast nirgendwo. Fast alle forward/backward sind einfach nur Fehler oder Überreste alter Daten.)
So isses. Jeder “stop” und jede “platform” geben einen neuen Halt an. Nur wenn eine “platform” unmittelbar auf einen “stop” folgt (nicht umgekehrt) und die beiden zusammengehören (gleicher Name) bilden die beiden Angaben zusammen nur einen Halt statt zwei. (Mit “stop” und “platform” sind dabei die Rollen in der Relation gemeint und nicht Tags in den Objekten. An diese Rollen kann auch noch “_exit_only” oder “_entry_only” angehängt sein.)
Es ist aber egal, ob die “platforms” Nodes, Ways oder Flächen (auch Multipolygone) sind. Wegen der Kompatibilität zum alten Kram wird aber gewöhnlich ein “stop”-Node hinzugefügt, wenn die platform kein Node ist. Dadurch gibt es beim kompatiblen Mappen immer irgendeinen Node an einem Halt.
Zwei Sachen könnte ich mir noch zusätzlich vorstellen:
Eine Einschränkung der Darstellung auf nur eine Relation. Damit wäre es viel leichter, Fehler in der Reihenfolge zu finden.
Auch Züge, Straßenbahnen usw. dazu nehmen. Die Regeln sind ja dieselben.
Weide
Ich (als einer von denen, die zeitweise sehr viel Buslinien gemappt und das Ergebnis genutzt haben) meine inzwischen, dass wir uns auf die Infrastruktur konzentriern sollten, und den darauf stattfinden Verkehr gar nicht mappen. Um da zu einem brauchbaren Ergebnis zu kommen bräuchte man mEn ein anderes Datenformat, in dem die Daten von den VU veröffentlicht werden müssten. Dazu könnten sie theoretisch von den Aufgabenträgern bzw (bei eigenwirtschaftlichem Verkehr) vom “Willen des freien Marktes” verpflichtet werden. Wenn ihr dennoch meint, dass mit OSM da ein gutes Ergebnis erreicht werden könne, will ich euch aber nicht davon abhalten das vorzuführen 
Da habe ich andere Erfahrungen gemacht: Iirc alle von mir reparierten Beschädigungen von Buslinienrelationen liessen sich auf einen der folgenden Gründe (sortiert nach Häufigkeit) zurückführen:
Für mehrere Nummern für eine Haltestelle braucht man in Deutschland nichtmal mehrere Betreiber oder Überorganisationen (Verkehrsverbünde, bahn.de, …) betrachten, einige haben auch selbst mehrere Systeme…
Bei beidseitigen Bushaltestellen kenne ich eigentlich nur entweder eine Nummer für beide zusammen oder hierachisch aufgebaute Nummern, wobei es bei HAFAS ein paar Anomalien (bei manchen Haltestellen zwei Nummern, die dasselbe Ergebnis liefern) gibt.
Irgendwo in einem der drei Threads meinte noch jemand, dass es schwierig sei, Linienvarianten aus Fahrplandaten auf die OSM-Relationen zu matchen: Über die Liste der Halte (oder einfacher: Mit from=, to= und via=*) geht das ganz gut.
Der Query für die Overpass API kann nun bearbeitet werden. Falls der Query bearbeitet wird, bleibt die Änderung bestehen (localStorage des Browsers).
Das Ganze ist aber nur gedacht um ein Gefühl dafür zu bekommen wie Routen heute erfasst sind. Ich plane derzeit nicht die Visualisierung besonders hübsch zu machen oder mit Features auszustatten.
Hallo,
auf den ersten Blick liefert folgende Variante ein vergleichbares Ergebnis, läuft aber um einiges schneller. Das hängt damit zusammen, dass das foreach in der Overpass Query relativ teuer ist.
(relation({{bbox}})[type=route][route~"bus"]; node(r));
out geom;
Link zum Testen: http://dev.overpass-api.de/tmp/psv/
Gruß,
mmd
Genau das meinte ich. Die dabei entstehenden Schäden sind Schäden in der Reihenfolge der Wege. Bei Relationen ohne Bedeutung der Wegreihenfolge entsteht daher kein Schaden. Dazu muss man nur von den ohnehin von vielen verlangten Segmenten zusätzlich Einfachheit fordern.
Weide
Die Probleme der Public Transport Daten wurden hier schon weitgehend beschrieben.
Wenig erwähnt wurde das Auswerteproblem: die Datenstruktur ist so komplex, dass sie ein durchschnittlicher User nicht nutzen kann (etwa mit einer Overpass-Abfrage).
Ein dritter, komplexes Schema, das neben den ersten beiden besteht und mit diesen wohlmöglich vermischt wird, würde das Auswerteproblem nochmals vergrößern.
In diesem Thread und in “Welchen Sinn machen ÖPNV-Routen in OSM” haben auch sehr aktive Mapper erklärt, dass sie keine ÖPNV-Daten erfassen.
Wir brauchen m.E. eine Datenstruktur, in der jeder Mapper mit jedem Editor und mit geringem Einarbeitungsaufwand ÖPNV-Daten erfassen kann.
Eine Möglichkeit dazu habe ich einmal skizziert:
Dein Query liefert weniger Datenmenge als der bisherige von mir. Der vorige Query für die Overpass API von mir hatte zu Duplikate in den Ergebnissen geführt – die sind natürlich nicht gewünscht gewesen. Vielen Dank für den Hinweis, ich habe deinen Query gerne übernommen.
Das Auswerteproblem ist ein schönes Stichwort! Welches Auswerteprobleme gibt es denn?
Derzeit ist unklar nach welchem Schema die Linien getagt sind. Daher kann der Auswerter nur raten PTV1 PTV2 Oxomoa etc. Meistens auch Mischformen.
Nach deinen Vorschlägen würdest du die Erfassung total vereinfachen. Aber die Auswertung deutlich erschweren.
Mit erfassen der Liniennummern je Haltestelle würdest du zwar schnell eine overpassabfrage erstellen können, welche dir ausgibt an welchen Haltstellen diese Nummer eingetragen ist, wobei das auch nicht besser wird je mehr Linien an der Haltestelle fahren, aber die wichtigen Informationen an welchem Mast fährt der Bus in welche Richtung und welche Haltestellen erreiche ich ohne Umsteigen von wo aus gehen verloren. Ebenso die Linienwege für die Abfragen wieviel Verkehrsleistung wird eigentlich erbracht etc.
Das ihr damit argumentiert man könne die Fahrwege aus den Haltestellen berechnen, macht die Sache nicht besser. Wie oft habe ich schon Fahrplandaten in Netze eingelesen und danach völlig sinnlose Linienrouten erhalten. Insbesondere große Haltestellenabstände und Einbahnstraßen machen ein Automatismus schwierig.
Ja es gibt erfahrene aktive Mapper die mappen kein ÖPNV. Aber frage doch mal wer Mappt Grenzen oder Öffnungszeiten? Und du kannst noch weiter gehen, wer mappt Wickeltische oder Hundekottütenspender? Das sind wirklich triviale Dinge, welche aber nicht bei jedem auf Interesse stoßen. Und so ist es beim ÖPNV auch.
Naja, da gibt es schon einen Unterschied. Hundekottütenspender mappe ich (meistens) nicht, weil sie mich nicht besonders interessieren (duck mich und weg …). ÖPNV mappe ich nicht, weil ich das Gefühl habe, dass ich es immer noch nicht wirklich verstehe und wahrscheinlich Unsinn produziere. Das ist also fast das Gegenteil: während die einen Dinge zu trivial sind, ist ÖPNV sehr (zu?) kompliziert.
Das heißt nicht, dass ich ÖPNV-Mapping ablehnen würde: nur weil ich mich immer noch nicht recht eingearbeitet habe, heißt das nicht, dass es schlecht/falsch/überflüssig … wäre. Ich bin jedem dankbar, der ÖPNV mappt. Es könnte aber ein Indiz dafür sein, dass PTv3 nicht noch viel komplizierter werden sollte …
BTW zur aktuellen Diskussion: Segmente wären, so wie Weide sie beschrieben und erklärt hat, mMn zwar komplex (eine Ebene mehr), aber nicht kompliziert (sie sind sehr klar definiert). Wenn sie also dazu beitragen würden, das ÖPNV-Mapping zu vereinfachen und sicherer zu machen, würde ich sie durchaus begrüßen.
Ich benutze in fremden Städten die ÖPNV-Karte damit ich eine schnelle Übersicht über die Linienverläufe habe.
Momentan ist das ÖPNV-Mapping sehr komplex und das Spezialgebiet von wenigen.
Erst wenn das Erfassen einfacher wird begeistern sich auch andere (vielleicht auch ich selbst).
Vor allem das Problem, dass kaum jemand die Daten nutzt, weil die OSM-Daten unvollständig, nicht aktuell, in unterschiedlichen, verschachtelten Datenformaten und undokumentierten Mischformen vorliegen.
Die Liniennetzkarten zeigen einfach alle Relationsmitglieder an. Da kommt es auf Lücken und Fehler in den Daten kaum an. Die meisten anderen Informationen werden nicht genutzt.
Nein, damit wird die Möglichkeit geschaffen, die Basisdaten auf einfache Weise zu erfassen und ebenso einfach auszuwerten.
Für viele Anwendungen reicht das bereits aus. Viele Nutzer können selbst erkennen, zu welcher Straßenseite sie gehen müssen um den richtigen Bus zu erwischen. Diese Daten sind auf jeden Fall besser, als eine nicht erfasste Buslinie!
Die Möglichkeit, alle Streckenvarianten in allen Details zu erfassen und auszuwerten, bleibt ja trotzdem erhalten.
Wenn man mehr Mapper gewinnt, die zumindest die Basisdaten erfassen und pflegen, kann man deren Daten nutzen, um auch die komplexen Datenstrukturen auf Fehler zu überprüfen und zu verbessern.
BTW, kennst du eine Anwendung, die mit den bislang erfassten Daten anzeigt, welche Haltestellen man ohne Umsteigen von wo erreichen kann oder wie viel Verkehrsleistung erbracht wird?
Die Grenzen sind in OSM weitgehend vollständig, werden regelmäßig auf Datenfehler geprüft und ggf. repariert und liegen in einem einheitlichen Datenformat vor. Damit sind sie gut nutzbar.
Für die ÖPNV-Daten gilt das leider nicht.
PS: Der ZOB in Kiel wurde Anfang des Jahres abgerissen und soll bis Ende 2017 neu gebaut werden. Bislang hat niemand die Buslinien angepasst.
PTV Visum macht das zum Beispiel. Aber das ist natürlich ein mächtiges Tool.
Werden OSM-Daten von Verkehrsunternehmen mit PTV Visum produktiv genutzt?
Wie geht das Programm mit fehlerhaften Relationen um?
Ich weiß nicht was Verkehrsunternehmen mit diesem Programm machen. PTV pflegt ja ein eigenes Straßenmodell. Mit OSM Daten ist es aber sehr einfach ein neues Model in anderen Gegenden aufzubauen.
Fehlerhafte Relationen werden einfach soweit wie möglich in Linienrouten umgewandelt. Allerdings werden keine zwei Routen für eine getrennte Relation angelegt. Auch mit Haltestellen hat das Programm Probleme. Es ist einfach auf Stop_positionan auf dem Weg angewiesen.
Meine Idee für ein PTv3 Datenmodell:
Es gibt Fahrwegrelationen, die eine Relation zwischen zwei aufeinanderfolgenden Haltestellen und den zwischen diesen Haltestellen gelegenem Fahrweg darstellen. Im allgemeinen werden diese Fahrwegrelationen völlig linienunabhängig sein. Nur in seltenen Ausnahmefällen wird werden mehrere Linien verschiedene Fahrwege zwischen dem gleichen Haltestellenpaar haben, so dass es hier verschiedene Fahrwegrelationen geben muss.
Es gibt Linienrelationen, die eine geordnete Liste der Haltestellen enthalten. Dazwischen können die jeweiligen Fahrwegrelationen optional eingefügt sein. Diese ist aber nur zwingend, wenn es zwischen einem Haltestellenpaar mehrere Fahrwegrelationen gibt.
Um einfacher Auswertungen (z.B. mit Overpass-API) machen zu können, kann man auch festlegen, dass möglichst alle Fahrwegrelationen enthalten sein sollen. Dann sollte aber der Editor oder ein Bot diese redundante Information automatisch hinzufügen.
Ebenso könnte es einen Bot geben, der automatisch Fahrwegrelationen durch Autorouting erstellt oder korrigiert, wenn ein Haltestellenpaar als aufeinanderfolgende Haltestellen der Linienrelation vorkommt. Durch ein Tag sollten automatisch erzeugte oder korrigierte Fahrwegrelationen gekennzeichnet werden. Durch geeignete Tags in Fahrweg- und Linienrelation sollte der Bot steuerbar sein.