Diskussion über Public Transport Version 2.1

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

Ok… damit kann ich leben… sollte aber dokumentiert werden…

Ok… kein Problem…

[Edit] Hier eine nachträgliche Frage… in den VBB-Namen sind Straßen oft abgekürzt… Aber es sind bei Straßen auch i.d.R. die Ortsnamen vorangeschrieben…

die openptmap hat nun den ersten Teil meiner Edits übernommen… noch nicht alle…

an diversen Stellen funktioniert die Abfrage gut… http://openptmap.org/?zoom=15&lat=51.94021&lon=13.90944&layers=B0000TFFT z.B. Haltestelle Briesener Zergoweg an anderenm nicht…: z.B. Ostbahnhof… das hinterläßt bei mir den Eindruck, daß der Abgleich über die Haltestellen-Namen passiert, Nummern hab ich noch nicht eingepflegt… Da wäre nun interessant, nach welcher Schreibweise der Namen die Auswertung passiert…
Die öpnvkarte ist zwar echneller mit der Darstellung fer Bus-Routen… aber nicht mit den Haltestellenrelationen… :frowning: [/Edit]

da sollte man gegebenfalls beide Varianten berücksichtigen… beim operator- und network-Tag habe ich das ausgeschrieben:

operator=Regionale Verkehrsgesellschaft Dahme-Spreewald mbH
network=Verkehrsverbund Berlin-Brandenburg

Gerade beim Operator gäbe es laut Taginfo Überschneidung zu “RVS Regionalbusverkehr Südwest GmbH”

Die wenigen, eindeutig dem Landkreis Dahme-Spreewald zuzuordnenden operator-Tags will ich mir noch genau anschauen…

Sven

Ja, ich sehe es ein: “name” wird hier gegen die Regeln benutzt. “note” und “description” sind aber auch nicht passend. In meinem Vorschlag habe ich für den Fall eines solchen Konfliktes “p3:name” vorgesehen – ich hatte allerdings nicht angenommen, dass der Konflikt immer da wäre.

Varianten haben dann also keine Namen. Aber was haben wir dann? (Nehmen wir als Beispiel für den neuen Key einfach mal “xname”). Dann müssten die Editoren umprogrammiert werden, so dass bei Varianten-Relationen “name” zu ignorieren ist und “xname” überall dort zu verwenden ist, wo bisher im Code “name” steht. Die werden uns erzählen, dass wir ein Rad ab haben. Ich bin mir nicht sicher, wo man jetzt was verändern muss, aber die Definition von “name” ist vielleicht überarbeitungswürdig.

Weide

Ja sollte. Aber wo? Und wer findet das dann?

Die Auswertung der openptkarte geht sehr wahrscheinlich nach Namen. Das kannst du an der URL sehen. Die Schwierigkeit dabei ist aber nicht nur die Auswertung nach Namen und nicht VBB Namen, sondern auch dass die Abfrage bei der Auskunft der DB passiert. Diese verwendet teilweise andere Namen als der VBB.

Ist es wirklich wichtig weltweit eindeutig zu sein? Oder reicht auch wen wir in der Region eindeutig sind? Man kann das ja überall im Land sehen. S7 in Berlin ist eben nicht S7 in Frankfurt. Und auch die Buslinien im VBB sind nicht eindeutig. Bei REs und RBs wollen wir lieber gar nicht darüber reden. Da reicht schon der Blick nach Mecklenburg. Der RE2 von Cottbus kommend hat fährt von Ostbahnhof nach Bahnhof Zoo gemeinsam mit dem RE7 (Wünsdorf - Dessau) und zwischen Ludwigslust und Wismar RE7(Ludwigslust - Wismar).
Also um daraus Informationen zu gewinnen ist es immer erforderlich auch den Regionalen Kontext zu beachten.

Ich habe an einigen Stellen als Haltestellennamen den so, wie er in Fahrplan steht: z.B. “Lübben, Berliner Chaussee” da funktioniert der Aufruf; oder der Name als solches ist einmalig: “Briesener Zergoweg”. Ist der Name nicht eindeutig, findet er z.T. völlig falsche Sachen…

Aber auch innerhalb des VBB, bei Busgesellschaften werden unterschiedliche Namen verwendet…:

VGOSL: “Lübben, Hauptbahnhof”
RVS: “Lübben, Bahnhof”
DB: “Lübben (Spreewald)”

VGOSL: “Lübben, Cottbusser Straße”
RVS: “Lübben, Cottbuser Straße”

Man beachte die falsche Schreibweise bei VGOSL. Die Straße heißt “Cottbuser Straße”

Das wir an den ID’s nicht vorbeikommen , da sind wir uns einig… in meinem Bereich kommen sie in Kürze rein (ref:VBB:area=), ebenso die Namen (name:VBB=) jeweils an die Haltestellenrelation.

Sowohl openptmap als auch ÖPNVKarte werten aber den Stop-Node und nicht die Haltestellenrelation aus…

Sven

Du hast vergessen zu erwähnen was auf dem Haltestellenschild steht. Auch das kann noch einmal was ganz anderes sein und wäre das was meiner Meinung nach in name=* gehört. Alle anderen können in name:RVS=* und name:VGOSL=* gepackt werden. Wobei sogar innerhalb eines Unternehmens verschiedene Schreibweisen auftauchen können.

Ich hab jetzt keine Lust, zum Bahnhof zu gehen… auch wenn es nur 5 Minuten zu Fuß sind…

was mir aufgefallen ist: gibt z.B. man bei http://fahrinfo.vbb.de/bin/query.exe/dn den Haltestellen-ID ein, kommt der korrekte Bahnhof… Im RIS der DB ( http://reiseauskunft.bahn.de/bin/bhftafel.exe/dn?) kommt man mit der Nummer nicht weiter… nur mit dem Namen…

ich mache mal mit den Station-ID’s weiter…

Sven

Ähm ja das ist ja auch die VBB ID und nicht die HafasNummer. Die wäre für Lübben 8010217.
Das entspräche dann der IBNR welche man auch bei Wikipedia sehen kann: http://de.wikipedia.org/wiki/Bahnhof_L%C3%BCbben_%28Spreewald%29