Diskussion über Public Transport Version 2.1

Also sollen jetzt statt dem Namen der Buslinie nur noch Zahlen in OSM stehen?

Na vielen Dank. Dadurch wird die Übersichtlichkeit und die Benutzerfreundlichkeit stark gefördert.

Ich meinte dieses Ungetüm:
name = : =>
was, wie seawolff für mich richtig meint, nichts mit dem Namen einer Linie zu tun hat.

name wäre für mich z.B. statt “Bus 564 Hanau ⇒ Langen-Bergheim” “Linie 564 Langen-Bergheim”, was wahrscheinlich auch auf dem Bus stehen könnte.
Don’t panic. :slight_smile:

Da ist PTv2 noch kürzer: die Linie heißt dort “Bus 564”. Die Linie insgesamt findet man in der route_master-Relation und nicht in den route-Relationen.

Bei den route-Relationen geht es um die Varianten und da ist der Startort genauso ein Unterscheidungsmerkmal wie der Zielort und manchmal müssen sogar Zwischenziele genannt werden. Auf dem Bus muss der Startort natürlich nicht stehen, denn den an einer bestimmten Haltestelle wartenden Passagieren ist die Vergangenheit des Busses ja völlig egal.

Statt “Bus 201: Uitikon Waldegg, Bahnhof => Uitikon, Wängi” würde man auch vermutlich auch eher “Bus 201: Waldegg=>Wängi” schreiben.

Weide

Hier werden Busrouten meist als “Linie 201” oder evtl. “Linie 201 Start-Ziel” genannt (sowohl umgangssprachlich wie auch vom Betreiber).
Züge heißen “RB 84” oder vielleicht “RB 84 Lübeck – Kiel”.
Die Konstuktionen “ : => ” sind keine Namen und gehören nicht ins name-Tag.
Als “description” oder “note” sind sie vermutlich unkritisch. Ob man sie überhaupt braucht ist eine andere Frage.

Es sind von Mappern vergebene Varianten-Namen (nicht Liniennamen) und sie werden gebraucht. Sollen wir wirklich die drei Relationen der S2 von Essen, Duisburg und Recklinghausen nach Dortmund alle “S2 Dortmund” nennen? Dann sind die Master-Relationen unlesbar.
Um es nochmal klar zu sagen: es geht nicht um den Namen der Linie. Der ist in PTv2 “Train S2” oder “S2”.

Weide

Zu Linienvarianten…

Da ich mich gerade mit Buslinien in meiner Umgebung beschäftige:

Hier mal das, was wir in der Pampa haben:

http://www.openstreetmap.org/relation/4435760 Hier der Fahrplan dazu: http://www.rvs-lds.de/tl_files/fahrplaene/509.pdf

Offiziell heißt sie: 509 Glietz < > Briesensee < > Lübben wobei lediglich die wenigsten der Linien die genannte Verbindung befahren. Das ist aber Standard hier… Die Linien sind so gestrickt, daß ein regelrechter Umlauf eines Busses und Fahrers über mehrere Linien entsteht…
Die Relation enthält alle Varianten des Fahrplans… wenn ich nichts übersehen hab…

Vom Einpflegen in OSM her ein riesen Aufwand…

Ach ja, die Angabe im name-Tag der einzelnen Routen-Variante hilft mir einigermaßen bei den vielen Varianten durchzusehen… sie sind für mich unerläßlich.

Sven

Gibt es eigentlich in Deutschland auch Geselschafte die ihre Daten offenbar machen unter Lizenz die in OSM übernommen werden kann, oder die damit einstimmen das die Daten in OSM aufgenommen werden?

Wenn man das von Fahrpläne ableiten muss, ist das tatsächlich ein ungeheuer Aufwand. Speziell weil das alles jetzt von unten aus zerbrochen wird von Mappern und von ‘oben’ aus wird das auch hier und dort manchmal angepasst.

Jo

Ich wusste noch nicht mal dass es überhaupt erlaubt ist von Fahrplänen abzukupfern… es machen aber scheinbar viele.

Wenn nicht von die Fahrplänen und nicht von die Quelldaten, wie kann man dann sicher sein alle Varianten sind eingeschlossen? Dann muss man diese Linien allen mal benutzen, mal auf Wochentag, mal am Samstag, mal am Sonntag, Freitagabends, Sonntagabends, Mittwoch zwischen 12 und 2. Mal die erste und die letzte Fahrt, weil die auch manchmal abweichen.

Und wie weiss man denn wenn etwas geändert würde and die Fahrplänen. Oder man musste es jede 3 Monate noch mal neu machen und vergleichen ob es noch stimmt.

Kein Problem mit 1000 Mappern, sondern wir sind froh wenn 1 pro Gegend sich daran interessiert.

Ich habe 2 Jahren mails geschickt an Gesellschaft De Lijn (Flandern) (Nicht jede Woche). Und auf einem Tag haben die dann Zustimmung gegeben um ihre Daten in OSM zu übernehmen. TEC (Wallonien) haben ihre Daten dann nochmal 2 Jahre später völlig freigegeben unter freie Lizenz.

Nur die Gesellschaft in Brüssel antwortet nicht. Vielleicht müsste ich mal auf Französisch versuchen… Man kann die Daten bekommen, aber die sagen: nicht für kommerzielle Benutzung. An Google haben die die schon langst vergeben. Und Google macht da auch eine Art kommerzielle Benutzung.

Jo

ich verweise mal auf:
http://forum.openstreetmap.org/viewtopic.php?id=19209 und auf http://daten.berlin.de/datensaetze/vbb-fahrplandaten-dezember-2014-bis-dezember-2015

Es sind mir derzeit keine Unternehmen bekannt, welche das tun. Aber es gibt Verbünde die dies tun bzw. getan haben. Einer der ersten war der VRS welcher die Mapper eingeladen hat und dort GPX Routen bereitgestellt hatte um die Linien zu übernehmen.
Später folgte der VBB, welcher regelmäßig aktualsierte GTFS Daten zur Verfügung stellt. Dabei gibt es die ausdrückliche Genehmigung der Übernahme in OSM. Es fehlt lediglich ein Konzept, wie dies geschehen kann.
Ich hatte einmal begonnen für ein automatisches Einlesen vorzuarbeiten: http://www.openstreetmap.org/relation/3410277#map=16/52.5794/13.5257
Allerdings macht es als Einzelkämpfer nur wenig Spaß. Dazu kommt das die Daten leider nur Haltestellenbereichsscharf sind und man so diverse Spezialfälle leider nicht abdecken kann.
Wenn es dazu neue Ideen gibt, würde ich mich sehr freuen.

Inzwischen gibt es auch weitere Verbünde, die Ihre Daten anbieten. Darunter ist Ulm und der VRN (http://www.vrn.de/vrn/einfach-ankommen/fahrplaene/opendata/index.html) Hier als VDV Format. Auch dabei kann ich gerne bei der Umwandlung behilflich sein. Leider hat es nur mit dem Zuschicken der Daten nicht geklappt.

Mapper vergeben keine Namen sondern erfassen existierende Namen (siehe Wiki:Names).
Mapper dürfen natürlich Bezeichnungen generieren, aber die gehören nicht nach “name” sondern in einen dafür vorgesehenen Key oder evtl. in “note” oder “description”.

Auch “Train S2” ist in Deutschland höchstwahrscheinlich nicht der übliche Name und gehört nicht ins “name”-Tag.

Ich weiß nicht, ob wir jetzt hier OT werden…

Mit der derzeitigen Datenlage kann die Haltestellen-ID lediglich in die Haltestellen-Relation geschrieben werden, da punktscharfe Daten wie bei einigen Stationen Berlins http://daten.berlin.de/datensaetze/%C3%B6pnv-bahnh%C3%B6festationen fehlen. Hier sollte aber auch eindeutig festgelegt werden, was an welchen Tag kommt, ob Abkürzungen verwendet werden oder nicht. letzeres wäre besser.

In dem Datensatz stop_times der aktuellen Fahrplandaten wird nur von Haltestellenbereich zu Haltestellenbereich geroutet… Dort ist nicht aufgeschlüsselt, wenn es mehrere Haltepunkte gibt. Den Haltestellen-ID also in die Stop-Position zu schreiben bringt also nichts…

… und wenn man in die Bus-Relation anstelle Platform und Stop-Position die Haltestellen-Relation schreibt? …ist aber auch Blöd…

Sven

Es ist in JOSM möglich Namen zusamenstellen zu lassen anhand tags und sogar tags von parent relations.

Das lässt dann aber iD und Potlatchbenutzer ohne Namen, wenn wir die in description oder note verschieben. Keine ahnung ob diese Editors mittlerweile zurückfallen können auf andere tags wenn name nicht vorhanden ist. Vor einige Jahren wollte der Entwickler von Potlatch das nicht unterstutzen.

Man muss dazu sowas:


    <item name="De Lijn" type="relation"
        name_template="route(!{parent() type=route_master'?{'{operator} {ref:De_Lijn} ' | '{ref} '}'}{ref} ?{'{from} - {via} - {to} ' | '{from} - {to} ' | '{from} ' | '{to} '}?{'{note} '})"
        name_template_filter="type=route route=bus">
    </item>
    
    <item name="De Lijn" type="relation"
        name_template="route_master(?{'{operator} {ref:De_Lijn} {ref} {name}'})"
        name_template_filter="type=route_master route_master=bus">
    </item>

    <item name="De Lijn" type="relation"
        name_template="route(!{parent() type=route_master'?{'{operator} {ref:De_Lijn} ' | '{ref} '}'}{ref} ?{'{from} - {via} - {to} ' | '{from} - {to} ' | '{from} ' | '{to} '}?{'{note} '})"
        name_template_filter="type=route route=tram">
    </item>
    
    <item name="De Lijn" type="relation"
        name_template="route_master(?{'{operator} {ref:De_Lijn} {ref} {name}'})"
        name_template_filter="type=route_master route_master=tram">
    </item>

an ein Presets file hinzufügen. Das muss natürlich erst mehr generell gemacht werden. Jetzt funktioniert es nur gut für route und route_master von De Lijn. Was mich daran gefällt ist das die schön zusammen geordnet werden im Relations pane.

Jo

Ich kann dir gerade nicht folgen. Es gibt eine Nummer für einen Haltestellenbereich. Zum Beispiel für den S+U Zoologischer Garten Bhf (Berlin) die 9023201.
Diese Nummer gilt egal ob für U-Bahn, Bus oder S-Bahn für alles was dort hält. Das ist insbesondere für die Busse kritisch, da hier unklar ist von welchem Mast die Busse abfahren, wenn sie eine bestimmte nächste Haltestelle anfahren. Bei allen anderen Verkehrsmitteln ist das kein Problem.
Für den Alexanderplatz hat der Verbund das bereits gelöst, in dem die Haltestelle in verschiedene Haltestellenbereiche aufgeteilt wurde. Das war dort vor allem wegen der Umsteigewege notwendig.
Welcher Relation will man also nun welche Nummer geben? Meiner Meinung nach gibt es nur eine saubere Möglichkeit. Jedem Punkt den Tag ref:VBB:area mitzugeben. Damit kann man schnell alle Punkte rausfiltern welche zu diesem Bereich gehören.
Wenn man die Nummer nur in die stop_area aufnimmt, würde man am Zoo verdammt viele Relationen mit der gleichen Nummer haben. Aber auch an der stop_area_group kann man das nicht machen, da man sonst nicht alle Haltestellenbereiche des Alexanderplatzes zusammen fassen könnte ohne das Unsinn raus kommt.
In den Linienvarianten oder Linienrelationen hat das meiner Meinung nach nichts zu suchen.

Edit: Bitte nicht die veralteten Stationsnamen aus dem Link verwenden. Gerade zu diesem Fahrplanwechsel wurden wieder diverse Stationen umbenannt. Falls nötig kann ich nochmal eine XLS erstellen. Sonst sind die Informationen aber auch in den aktuellen GTFS Datensätzen in der stops.txt Datei gespeichert. http://daten.berlin.de/datensaetze/vbb-fahrplandaten-dezember-2014-bis-dezember-2015

Ich hab mir gerade mal aus den aktuellen Fahrplandaten eine Datenbank gebaut… um durchzusehen.

Für Berlin Alexanderplatz ist es differenziert… anscheinend einer der Wenigen…

stop_name	                                                agency_name	                stop_id
S+U Alexanderplatz (Berlin) [U2]	                        Berliner Verkehrsbetriebe	9100703
S+U Alexanderplatz (Berlin) [U5]	                        Berliner Verkehrsbetriebe	9100704
S+U Alexanderplatz (Berlin) [U8]	                        Berliner Verkehrsbetriebe	9100705
S+U Alexanderplatz (Bln) [Bus K.-Liebknecht-Str]	        Berliner Verkehrsbetriebe	9100708
S+U Alexanderplatz Bhf (Berlin)	                                DB Regio AG	                9100003
S+U Alexanderplatz Bhf (Berlin)	                                ODEG Ostdeutsche Eisenbahn GmbH	9100003
S+U Alexanderplatz Bhf (Berlin)	                                S-Bahn Berlin GmbH	        9100003
S+U Alexanderplatz Bhf/Dircksenstr. (Berlin)	                Berliner Verkehrsbetriebe	9100024
S+U Alexanderplatz Bhf/Gontardstr. (Berlin)	                Berliner Verkehrsbetriebe	9100026
S+U Alexanderplatz Bhf/Grunerstr. (Berlin)	                Berliner Verkehrsbetriebe	9100006
S+U Alexanderplatz Bhf/Memhardstr. (Berlin)	                Berliner Verkehrsbetriebe	9100031
U Alexanderplatz (Berlin) [Tram]	                        Berliner Verkehrsbetriebe	9100005
U Alexanderplatz [Bus]	                                        Berliner Verkehrsbetriebe	9100707

Meinst du damit der stop_position?

Ja… der Alex ist da sicher ein gutes Beispiel, daß meine Idee Quark war…

Wenn man sich http://datenfragen.de/openvbb/Bahnhoefe_mit_Zugangskoordinaten_GK4_lon-lat_Auswahl.xlsx anschaut, hat alles eine ID… Das wäre diese, die an das Objekt gehört. Das hieße, daß dann auch, daß für jede o.g. stop_id eine Haltestellen-Relation angelegt werden müsste… ??!

fragt sich Sven

Das ist sehr gut!

Ja es ist besser, aber noch nicht perfekt! du kannst dir gerne mal die ref:BVG anschauen. Da siehst du dann was dem VBB noch fehlt. Über diese Nummer kann man dann die website dieses Mastes aufrufen. (Sie ist als QR Code dort aufgedruckt, der NFC Tag besitzt noch eine eingeschobene 100)

Damit meinte ich stop_position genauso wie platform oder Mastschild, welches ich viel lieber verwende.

Ich denke nicht das die Idee Quark war. Es zeigt nur wie unterschiedlich die Daten sind. Meiner Meinung nach müssten am Alex alle Bereiche eine stop_area Relation erhalten und dann die entsprechende Nummer. Zusammenfassen kann man das dann in einer stop_area_group, damit die Umsteigebeziehungen klarer werden.
Das ist allerdings am Bahnhof Zoo nicht mehr so einfach. Dort ist nach VBB Definition noch alles ein Haltestellenbereich. Aber man sollte es wenigstens in Bus U-Bahn und den Rest teilen. Diese Relationen hätten dann aber wieder die selbe Nummer.
Ich denke es ist auch nicht verkehrt die VBB Namen zu erfassen, da dies Verwechslungen vorbeugt. Am Fahrplan/Schild ist meist nur eine verkürzte Form zu finden.

So mache ich das hier jedenfalls. Für jede HS eine stop_area. Die dann wieder grupieren in eine stop_area_group. Es ist dann kein v2 mehr…

Für mich macht es mehr sinn die ref/id auf Platform zu setzen. Wir haben noch nicht überall stop_position gemappt. Was angeblich abweicht von v2 ist das wir nur nodes benutzt haben für highway=bus_stop, public_transport=platform, bus/tram=yes. Das sind hier die wichtige Nodes die name/ref/route_ref/operator/network details haben.

Wir haben wohl das Glück gehabt, dass wir vom Anfang an refs für die HS zur Verfügung hatten (Die sind angegeben auf den Schildern in der Strasse, wenigstens für De Lijn) und das hat natürlich die Entscheidung beeinflusst um HS neben den Strassen zu taggen, und diese Nodes als wichtigste zu sehen.

Ich habe jetzt auch gefunden warum ich nie überwogen habe um diese Details auf platform ways/MP zu setzen. Das hat zu tun mit MapCSS die all diese Daten schön rum die Nodes anschaut:

Ich hatte einen screenshot, sehe aber nicht wie den ein zu schliessen.

wenn wir die Daten so genau hätten… klar…

Dan denken wir in die selbe Richtung… Gut…

Nun, ich glaube es ist eine Frage der Zeit, daß der VBB auch den Bahnhof Zoo zerteilt… :smiley: (Ich “liebe” den Bahnhof Zoo… vor allem wenn ich da umsteigen muß). Ein Aufteilen würde sicher schon helfen… zumal eine indirekte Zuordnung dann möglich wäre: aus den OSM-Haltestellenbereichen die mit Bus und aus den GTFS-Daten die Bus-Fahrplandaten.

Bliebe noch die Frage nach dem Tagging: ref:VBB=* an die Haltestellen-Relation und der VBB-Name als Name der Haltestellen-Relation, network=Verkehrsverbund Berlin-Brandenburg und operator=* (bei mir: Regionale Verkehrsgesellschaft Dahme-Spreewald mbH) Sifern Stop-Position und Platform (Bussteig, Bahnsteig ect. ) eine eigene ID haben, bekommen sie ihe eigene ID als ref:VBB

schlägt Sven vor

Also ich würde nicht ref:VBB verwenden, da es eindeutig die Referenz für den Bereich ist. Daher hatte ich ref:VBB:area benutzt. Wenn man was besseres findet kein Problem.
Und für den Name würde ich name:VBB vorschlagen, da verschiedene Anbieter für gleiche Haltestellen verschiedene Namen verwenden. So kann man die auseinander halten.
Was das ausschreiben von VBB angeht, so ist die Abstimmung mit den Füßen derzeit eindeutig.
2468 Relationen mit VBB zu 406 mit der ausgeschriebenen Variante.
und 998 Punkte kurz zu 128 mit langer Schreibweise.

Beim Operator scheint es ähnlich zu sein:
1238 Punkte mit BVG zu 18 mit Berliner Verkehrsbetriebe
936 Relationen zu 1