VBB Daten unter CC-Lizenz

[S-Man42]

@derandi

@S-Man42
Ich muß dich leider enttäuschen es ist nicht der komplette Satz der Haltestellen in BB. Ich habe die Haltestelle aus dem GTFS-Format exportiert und sie in eine
JOSM lesbare Form gewandelt (Name der Haltestelle und Koordinaten).
Teilweise weichen die Haltstelle von der Position in den Luftbildern oder OSM ab und manchmal z.B. in Cottbus gibt es nur einige wenige Halltstellen.
Berlin dagegen auf den ersten Blick komplett. Die Abweichungen kann man schon sehr schön auf der Webseite des VBB sehen

Ja, das habe ich auch schon bemerkt. Allein, dass es eben nur einen Punkt pro Haltestelle gibt, macht den Satz nicht unbedingt hilfreich. Insofern ist das mit dem automatischen Import durchaus von mir von vornherein etwas ausgeklammert.

Ich habe drei-vier Stichproben im “brandenburgischen Outback” gemacht und da gab es eben die unbedeutenderen Haltestellen. Habe dadurch angenommen, dass es alle sind. Schade, dass dem nicht so ist. Dennoch sind sicherlich einige dabei, die noch nicht in OSM verhanden sind. Von den Linien mal ganz zu schweigen, da gibts ja beträchtliche Defizite bei uns.

PS: Just in diesem Augenblick kam eine Mail vom VBB an:

Sehr geehrte Damen und Herren,

vorab vielen Dank für Ihre Entscheidung, Ihre Daten der Allgemeinheit zur weiteren Verwendung freizugeben.

Ich schreibe Ihnen hiermit stellvertretend für das OpenstreetMap-Projekt (openstreetmap.org), kurz OSM. Gern würden wir Ihre Daten für unsere Karten verwenden, insbesondere die Haltestellen und die Buslinienverbindungen. Allerdings sind vor einigen Wochen die Daten von OSM unter die Open Database License (ODbL) gestellt wurden, welche nicht hundertprozentig mit der von Ihnen gewählten CC-BY-Lizenz kompatibel ist.

Deshalb wollten wir anfragen, ob und wie wir Ihre Daten verwenden dürfen. Der Knackpunkt ist die Namensnennung Ihrer CC-BY-Lizenz. Wir sehen drei mögliche Interpretationen:

• Nennung von VBB als Quelle bei den Import-Änderungssätzen (zB: “Alle Daten dieses Änderungssatzes sind gestellt worden vom VBB”)
• Nennung des VBB an jedem relevanten Knoten/Weg/Relation (wie Haltestellen oder Buslinien) als source- oder comment-Feld am jeweiligen Datensatz (“Die Daten dieser Haltestelle kommen vom VBB”). Was passiert, wenn dieses Feld einmal versehentlich gelöscht wird (auch wenn es in der Historie verbleibt)?
• Nennung des VBB allgemein bei allen resultierenden Projekten, gerenderten Karten, Datenbank-Spiegelungen, usw. (“Ein Teil der für diese Karten benötigten Daten könnten vom VBB kommen”).

Der dritte Punkt wäre für uns leider keine Alternative, da eben genau diese Übernahme nicht gewährleistet werden kann. Die beiden ersten könnten gewährleistet werden, am sinnvollsten für uns wäre ein Vermerk bei den Änderungsdatensätzen (also Punkt 1).

Es würde uns freuen, von Ihnen zu hören,

Mit freundlichen Grüßen,
…

Guten Morgen Herr…,

das hört sich ja sehr interessant an! Gerne wollen wir mit Ihnen in einen Dialog treten und uns zu dieser Thematik mit Ihnen zusammensetzen!
Sind Sie evtl. auch am kommenden Donnerstag beim Entwicklertag “Apps& the city” dabei?
Vielleicht finden wir am Rande der Veranstaltung schon etwas Zeit…

Ansonsten melden wir uns danach um einen Termin zu vereinbaren.

Vielen Dank noch einmal für Ihr Interesse und schöne Grüße

Ich nehme nicht an dem Event teil. Sonst irgendwer? Hat jemand mit mehr Kompetenzen Lust, einen Termin mit dem VBB zu machen?

[viw]

@S-Man42

@derandi

@S-Man42
Ich muß dich leider enttäuschen es ist nicht der komplette Satz der Haltestellen in BB. Ich habe die Haltestelle aus dem GTFS-Format exportiert und sie in eine
JOSM lesbare Form gewandelt (Name der Haltestelle und Koordinaten).
Teilweise weichen die Haltstelle von der Position in den Luftbildern oder OSM ab und manchmal z.B. in Cottbus gibt es nur einige wenige Halltstellen.
Berlin dagegen auf den ersten Blick komplett. Die Abweichungen kann man schon sehr schön auf der Webseite des VBB sehen

Ja, das habe ich auch schon bemerkt. Allein, dass es eben nur einen Punkt pro Haltestelle gibt, macht den Satz nicht unbedingt hilfreich. Insofern ist das mit dem automatischen Import durchaus von mir von vornherein etwas ausgeklammert.

Ich habe drei-vier Stichproben im “brandenburgischen Outback” gemacht und da gab es eben die unbedeutenderen Haltestellen. Habe dadurch angenommen, dass es alle sind. Schade, dass dem nicht so ist. Dennoch sind sicherlich einige dabei, die noch nicht in OSM verhanden sind. Von den Linien mal ganz zu schweigen, da gibts ja beträchtliche Defizite bei uns.

Vielleicht ist in dem aktuellen Datensatz nicht mehr alles drin. Aber in jedem Falle gibt es ja einen sehr viel umfangreicheren Datensatz aus dem Jahr 2011. Dort lassen sich wahrscheinlich noch weitere Haltestellen finden. Und es sind nicht nur Haltestellen aus dem VBB Gebiet. Auch Bahnhöfe wie Meißen in Sachsen oder polnische Städte waren mir aufgefallen.

PS: Just in diesem Augenblick kam eine Mail vom VBB an:
Ich nehme nicht an dem Event teil. Sonst irgendwer? Hat jemand mit mehr Kompetenzen Lust, einen Termin mit dem VBB zu machen?

Ich hätte schon Lust mit dem VBB darüber zu sprechen. Ob das am Donnerstag schon geht weiß ich aber noch nicht.

[S-Man42]

Ich würde gern dabei sein. Aber allein traue ich mir das nicht zu, weil ich vermutlich einfach nicht so tief drin stecke. Dann sage ich der Dame, dass wir einen Termin machen können? Oder willst du das allein machen?

[aighes (Henning)]

@viw

@rayquaza

@viw

Das ist genau das gleiche Problem wie wenn wir einfach die nodeID aus OSM einem Haltestellenbereich zu ordnen. Irgendwann kommt jemand der meint den Knoten löschen zu müssen und 5 m links einen neuen zu setzen.

Das ist etwas anderes. aighes meinte (so ich es korrekt interpretiere), dass die “eindeutige ID” aus network und ref besteht, was z.B. die Overpass-API gut umbauen kann.

@viw

Wie lange ist die ID gleich? So lange der Fahrplan gilt. In diesem Fall bis zum Januar 2013.

ich weiß nicht ob er das so meinte. Aber es gibt einfach Linien die auf unterschiedlichen Wegen verkehren und dennoch die gleiche Liniennummer im gleichen “network” tragen.

Als Beispiel lass dir einfach den Fahrplan für die 838 auf vbb.de erstellen. Da findest du Fahrten über mildenberg und über Burgwall. genauso wie Fahrten nur über mildenberg oder nur über Burgwall oder über keine der beiden Haltestellen. Alle diese Varianten heißen VBB 838 und sind sogar vom gleichen Betreiber.

Doch, so meinte ich das. Diese “ID” hält solange, bis die Linie geändert wird. Sollte der Verbund es dann produktiv nutzen, dann wird er es bei uns dann selber ändern oder aber uns Bescheid geben. Zu den Linienvarianten. Bei uns laufen die unter der gleichen Liniennummer, im Fahrplan gibt es dann aber Fußnoten für jede Variante. Man bräuchte dann also neben network und ref noch ein <Varianten_ref>=* und hätte auch das Problem gelöst.

[Fabi2 (Fabian)]

@viw

Vielleicht ist in dem aktuellen Datensatz nicht mehr alles drin. Aber in jedem Falle gibt es ja einen sehr viel umfangreicheren Datensatz aus dem Jahr 2011. Dort lassen sich wahrscheinlich noch weitere Haltestellen finden. Und es sind nicht nur Haltestellen aus dem VBB Gebiet. Auch Bahnhöfe wie Meißen in Sachsen oder polnische Städte waren mir aufgefallen.

Vielleicht ist es ja wieder nur ein Extrakt der stabilen Kernliniendaten wie 2011 (http://daten.berlin.de/ver%C3%B6ffentlichende-stelle/vbb-verkehrsverbund-berlin-brandenburg-gmbh). Scheinbar sieht man es die Aktion da im Moment auch eher als zusätzliche PR-Maßnahme als das man den tieferen Sinn von Open Data verstanden hat, ist aber schon gut, das sie es überhaupt machen.

[viw]

@Fabi2

@viw

Vielleicht ist in dem aktuellen Datensatz nicht mehr alles drin. Aber in jedem Falle gibt es ja einen sehr viel umfangreicheren Datensatz aus dem Jahr 2011. Dort lassen sich wahrscheinlich noch weitere Haltestellen finden. Und es sind nicht nur Haltestellen aus dem VBB Gebiet. Auch Bahnhöfe wie Meißen in Sachsen oder polnische Städte waren mir aufgefallen.

Vielleicht ist es ja wieder nur ein Extrakt der stabilen Kernliniendaten wie 2011 (http://daten.berlin.de/ver%C3%B6ffentlichende-stelle/vbb-verkehrsverbund-berlin-brandenburg-gmbh). Scheinbar sieht man es die Aktion da im Moment auch eher als zusätzliche PR-Maßnahme als das man den tieferen Sinn von Open Data verstanden hat, ist aber schon gut, das sie es überhaupt machen.

Ich denke nicht das man die Aktion nur als PR sieht. Der Aufwand dafür ist viel zu groß. Ich denke eher es sind die Vorbehalte der Verkehrsunternehmen. Jetzt muss der VBB erstmal schauen wo die Mehrwerte liegen um damit dann auch die Datenfreigabe zu erreichen.

[Fabi2 (Fabian)]

@aighes

@viw

ich weiß nicht ob er das so meinte. Aber es gibt einfach Linien die auf unterschiedlichen Wegen verkehren und dennoch die gleiche Liniennummer im gleichen “network” tragen.

Als Beispiel lass dir einfach den Fahrplan für die 838 auf vbb.de erstellen. Da findest du Fahrten über mildenberg und über Burgwall. genauso wie Fahrten nur über mildenberg oder nur über Burgwall oder über keine der beiden Haltestellen. Alle diese Varianten heißen VBB 838 und sind sogar vom gleichen Betreiber.

Doch, so meinte ich das. Diese “ID” hält solange, bis die Linie geändert wird. Sollte der Verbund es dann produktiv nutzen, dann wird er es bei uns dann selber ändern oder aber uns Bescheid geben. Zu den Linienvarianten. Bei uns laufen die unter der gleichen Liniennummer, im Fahrplan gibt es dann aber Fußnoten für jede Variante. Man bräuchte dann also neben network und ref noch ein <Varianten_ref>=* und hätte auch das Problem gelöst.

<Varianten_ref>=* löst das Problem für uns, soweit ich sehe, leider nicht. Das Datenschema ist ja so, das man physische Routen als eine bestimmte Abfolge von Haltestellen definiert. Auf diesen so festgelegten Varianten von Haltestellenabfolgen (weil die tatsächliche geographiasche Linenführung ist ja nicht enthalten) finden dann die Fahrten (Stichwort: Teleskoplinien) statt. Soll heißen, die Strecke ist für die Route jeweils fest vorgegeben, aber wo auf der Route dann die Fahrt beginnt und endet, ist variabel.

Somit sind “Linenvarianten” dort nur echte Änderungen der Haltestellenabfolge, aber z.B. keine Teleskoplinien, wie bei OSM.

Der Bus 838 hat also nur zwei Routen, hakt bei dem Beispiel mal “Perlschnur erzeugen” an, dann seht ihr es besser.

[viw]

@Fabi2

Doch, so meinte ich das. Diese “ID” hält solange, bis die Linie geändert wird. Sollte der Verbund es dann produktiv nutzen, dann wird er es bei uns dann selber ändern oder aber uns Bescheid geben. Zu den Linienvarianten. Bei uns laufen die unter der gleichen Liniennummer, im Fahrplan gibt es dann aber Fußnoten für jede Variante. Man bräuchte dann also neben network und ref noch ein <Varianten_ref>=* und hätte auch das Problem gelöst.

<Varianten_ref>=* löst das Problem für uns, soweit ich sehe, leider nicht. Das Datenschema ist ja so, das man physische Routen als eine bestimmte Abfolge von Haltestellen definiert. Auf diesen so festgelegten Varianten von Haltestellenabfolgen (weil die tatsächliche geographiasche Linenführung ist ja nicht enthalten) finden dann die Fahrten (Stichwort: Teleskoplinien) statt. Soll heißen, die Strecke ist für die Route jeweils fest vorgegeben, aber wo auf der Route dann die Fahrt beginnt und endet, ist variabel.

Somit sind “Linenvarianten” dort nur echte Änderungen der Haltestellenabfolge, aber z.B. keine Teleskoplinien, wie bei OSM.

Der Bus 838 hat also nur zwei Routen, hakt bei dem Beispiel mal “Perlschnur erzeugen” an, dann seht ihr es besser.

Was auch immer Teleskoplinien seien mögen, aber wenn man sich den Fahrplan der 838 anschaut stellt man bei einem Blick auf die Zeiten fest dass es mehr als zwei Varianten sind.
Die Fahrten 5:48, 5:50, 7:47, 9:45, 9:47 und 13:42 sind verschiedene Varianten.
Wenn man jetzt noch die Fahrzeiten dazu nimmt weichen auch 15:23 und 18:53 ab.
(ohne Gewähr auf Vollständigkeit)

[Fabi2 (Fabian)]

@viw

Was auch immer Teleskoplinien seien mögen, aber wenn man sich den Fahrplan der 838 anschaut stellt man bei einem Blick auf die Zeiten fest dass es mehr als zwei Varianten sind.

Das stimmt natürlich, ich hatte nur versucht das Datenformat zu verstehen ohne nach der Spec zu suchen und das hätte ich mal besser an einer Linie machen sollen, die ich kenne…

In routes.txt stehen die Liniennummer und deren Betreiber, dann haben sie über die route_id da wirklich jede einzelne Fahrt zugeordnet, die in trips.txt stehen. Über die trip_id bekommt man dann die an Reihenfolge der Haltestellen und die Ankunfts- und Abfahrtszeiten dort, die in stop_times.txt stehen. Die Haltestellen selbst werden dann noch über stop_id nach Name unterschieden, z.B. gibt es S Warschauer Str. und S+U Warschauer Str., was aber real wahrgenommen die gleiche Haltestelle ist und wenn man da nach Verkehrsmitteln unterteilen würde, sind es min. drei.

[viw]

@Fabi2

@viw

Was auch immer Teleskoplinien seien mögen, aber wenn man sich den Fahrplan der 838 anschaut stellt man bei einem Blick auf die Zeiten fest dass es mehr als zwei Varianten sind.

Das stimmt natürlich, ich hatte nur versucht das Datenformat zu verstehen ohne nach der Spec zu suchen und das hätte ich mal besser an einer Linie machen sollen, die ich kenne…

In routes.txt stehen die Liniennummer und deren Betreiber, dann haben sie über die route_id da wirklich jede einzelne Fahrt zugeordnet, die in trips.txt stehen. Über die trip_id bekommt man dann die an Reihenfolge der Haltestellen und die Ankunfts- und Abfahrtszeiten dort, die in stop_times.txt stehen. Die Haltestellen selbst werden dann noch über stop_id nach Name unterschieden, z.B. gibt es S Warschauer Str. und S+U Warschauer Str., was aber real wahrgenommen die gleiche Haltestelle ist und wenn man da nach Verkehrsmitteln unterteilen würde, sind es min. drei.

Auch das scheint nicht ganz richtig zu sein. Am Beispiel der 838 sieht man das es diese in der routes.txt zweimal gibt und zwar mit dem selben Betreiber. Wahrscheinlich werden hier auch schon die Richtungen getrennt ohne das dafür ein Key vorhanden scheint.

Die Warschauerstraße gibt es aber wirklich zweimal so wie du beschrieben hast. Warum? Weil sonst die Straßenbahn nach S+U Warschauerstraße zweimal an der selben Haltestelle halten würde. Es gibt Programme die mögen so etwas nicht. Außerdem möchte man die beiden Straßenbahnendpunkte unterscheidbar machen. Während die M13 nur bis S-Bahnhof fährt fährt die M10 noch über die Brücke zum U-Bahnhof.
Weitere Besonderheit am S-Bahnhof Warschauerstraße dürfte nur die Straßenbahn halten. Die S-Bahn hingegen hält dann am S+U Warschauerstraße.

[viw]

Wir hatten heute das Vergnügen mit dem VBB sprechen zu dürfen. Die Beteiligten waren sehr aufgeschlossen gegenüber der Datennutzung für OSM. Wir wurden daher gebeten, unsere Anforderungen an die GTFS Daten einmal zu formulieren. Der VBB würde dann die technischen Forderungen mit den Möglichkeiten abgleichen lassen.
Das von uns angesprochene Lizenzproblem sieht man beim VBB nicht so eng. Man können sich vorstellen Teile der Daten auch ohne die Auflage der Namensnennung zu veröffentlichen. Bei Fahrplandaten hingegen würde man darauf nicht verzichten wollen/können. Kein Problem sollten aber Linienrouten und Haltestelleninformationen einschließlich Mastkoordinaten sein. Allerdings ist bei letzerem noch zu berücksichtigen das sich das System gerade erst im Aufbau befindet und der Prozess noch lange nicht abgeschlossen ist.
Auch die Erzeugung der GTFS Daten steckt derzeit noch in der Erprobung, weshalb es derzeit auch noch nicht alle Haltestellen mit lat lon Koodrinaten veröffentlicht wurden. Dies sollte aber in einem neuen Lauf korrigiert werden.
Wir sollten uns also Gedanken über einen möglichen Automatischen Abgleich machen. Wenn diese Daten monatlich mit aktuellen Umleitungen versorgt werden, könnte man sich überlegen OSM darauf anzupassen. Wir müssten nur die Stoppoints mit den VBB Referenzen fürttern und dann die eindeutigen aggregierten Haltestellenfolgen abgleichen. Als Schlüssel wurden Strings aus den einzelnen Haltestellennummern vorgeschlagen. Diese müsste man aber nicht eintragen, sondern könnte sie für den Abgleich automatisch generieren.
Was haltet ihr davon? Welche Anforderungen hättet ihr an GTFS Daten? Dies ist unsere Chance, nicht zu letzt weil die Schnittstellen für eine vielzahl anderer Unternhemen dienen könnten. Nordamerika ist total durchzogen von Verkehrsunternehmen die auf GTFS setzen.

[aighes (Henning)]

Namensnennung ist ja an sich möglich. Wir hätten da eine wiki-Seite und auch in den Daten kann man ein source angeben. Für letzteren kann OSM allerdings nur in der Version garantieren, in der es eingefügt wurde. Was wir bei Namensnennung nicht garantieren können, ist, dass alle Anwender von unseren Daten, ebenfalls die Quelle nennen und das das source-Tag erhalten bleibt.

[Fabi2 (Fabian)]

@viw

@Fabi2

In routes.txt stehen die Liniennummer und deren Betreiber, dann haben sie über die route_id da wirklich jede einzelne Fahrt zugeordnet, die in trips.txt stehen. Über die trip_id bekommt man dann die an Reihenfolge der Haltestellen und die Ankunfts- und Abfahrtszeiten dort, die in stop_times.txt stehen. Die Haltestellen selbst werden dann noch über stop_id nach Name unterschieden, z.B. gibt es S Warschauer Str. und S+U Warschauer Str., was aber real wahrgenommen die gleiche Haltestelle ist und wenn man da nach Verkehrsmitteln unterteilen würde, sind es min. drei.

Auch das scheint nicht ganz richtig zu sein. Am Beispiel der 838 sieht man das es diese in der routes.txt zweimal gibt und zwar mit dem selben Betreiber. Wahrscheinlich werden hier auch schon die Richtungen getrennt ohne das dafür ein Key vorhanden scheint.

Nein, die Fahrichtungen sind es auch nicht, weil viele Linien sind dort nur als einmaliger eindeutigen Schlüssen drin, so das ich eben beim 838 erst fälschlich annahm, es seinen die Routenvarianten.

@viw

Die Warschauerstraße gibt es aber wirklich zweimal so wie du beschrieben hast. Warum? Weil sonst die Straßenbahn nach S+U Warschauerstraße zweimal an der selben Haltestelle halten würde. Es gibt Programme die mögen so etwas nicht. Außerdem möchte man die beiden Straßenbahnendpunkte unterscheidbar machen. Während die M13 nur bis S-Bahnhof fährt fährt die M10 noch über die Brücke zum U-Bahnhof.
Weitere Besonderheit am S-Bahnhof Warschauerstraße dürfte nur die Straßenbahn halten. Die S-Bahn hingegen hält dann am S+U Warschauerstraße.

Ja, die beiden Haltestellen, vor und hinter der Warschauer Brücke für die M10, sind sicher der Hauptgrund. Aber selbst wenn du schreibst, das da noch Haltestellen fehlen, auch die offizielle BVG und VBB-Fahrinfo hat nicht mehr als diese beiden Koordinatenpunkte drin, wobei aus meiner Sicht mindestens ja noch ein dritter, für den S Bahnsteig, mehr als gerechtfertigt wäre. Noch besser wären die Koordinaten aller vorhandenen Haltepunkte (im Sinne von public_transport=stop_position).

Gut zu wissen, daß das Ganze noch in Entwicklung ist, weil die Datenbak ist ja etwas abenteuerlich, wobei ich erst dachte es wäre ein Effekt der Konvertierung, aber z.B. die Sache mit den Koordinaten beim Bahnhof Warschauer Str. zeigt ja, das es scheinbar auch schon Probleme mit den Ausgangsdaten gibt.

Wegen der Namensnennung sollte man aus meiner Sicht die Spender vielleicht prominenter z.B. auf einer extra Contributor-Seite von der Hauptseite verlinken, das ist ja, wenn ich die OdbL richtig verstehe, sowieso erforderlich, wenn von unter OdbL freigegebenen Frenddaten ein Import gemacht wird. Sprich, da müßte man ja eigentlich alle Sender von anderen Datenbanken nenen, weil OSM ist ja ein abgeleitete Datenbank dieser Daten.

[viw]

@Fabi2

Ja, die beiden Haltestellen, vor und hinter der Warschauer Brücke für die M10, sind sicher der Hauptgrund. Aber selbst wenn du schreibst, das da noch Haltestellen fehlen, auch die offizielle BVG und VBB-Fahrinfo hat nicht mehr als diese beiden Koordinatenpunkte drin, wobei aus meiner Sicht mindestens ja noch ein dritter, für den S Bahnsteig, mehr als gerechtfertigt wäre. Noch besser wären die Koordinaten aller vorhandenen Haltepunkte (im Sinne von public_transport=stop_position).

Für Berlin sind diese Daten schon vorhanden. Uns wurde demonstriert, wie eine Verbindungssuche aussieht wenn man diese Koordinaten verwendet. Derzeit gibt es aber vor allem Performance- und Vollständigkeitsprobleme, weshalb die Standardauskunft noch anders rechnet. Nimmt man hingegen beim VBB die barierrefreie Routingeinstellung werden schon heute die Koordinaten berücksichtigt.
Bei der BVG ist das ganze in einem eigenen Modul ähnlich verfügbar. Allerdings sind die Verbindungen derzeit noch eine Mischung aus Routing auf OSM Daten und Luftlinien.

[S-Man42]

Ich möchte viws Ausführungen kurz ergänzen, auch wenn er das wesentliches schon gesagt hat.

Die Vertreter von VBB und BVG hatten, wie gesagt, schon das Interesse, uns mit Daten zu versorgen. Dabei geht es sowohl um die Mastkoordinaten, die sie aber erst in 1-2 Jahren fertig haben - zumindest der VBB. Bei der BVg liegen sie wohl vor, als auch um Zugänge und Fahrstuhlkoordinaten, die in den aktuellen GTFS-Datensätzen wohl schon vorhanden sein sollten. Dass es auch um Linien und Haltestellenreihenfolgen geht, hat viw ja schon gesagt.

Es ist also wichtig, deswegen hebe ich das noch einmal hervor, dass wir hier auf einen Konsenz kommen, um dem VBB klar und deutlich vermitteln zu können, welche Daten wir benötigen. Das Interesse ist da, sie haben aber ausdrücklich ein Dokument verlangt, in dem wir unsere Anforderungen spezifizieren sollen. Die sollte - nicht jetzt und gleich, aber in näherer Zukunft - passieren. Es geht eben darum - wenn ich das richtig verstand - dass sie auch von vornherein unsere Anforderungen bei ihrer derzeitigen Systemumstellung berücksichtigen können. Gerade in anbetracht an statische IDs. (Dies wird wohl aber durch eindeutige Mastkoordinaten geregelt sein).

Gruß S-Man

[EvanE]

@S-Man42

Ich möchte viws Ausführungen kurz ergänzen, auch wenn er das wesentliches schon gesagt hat.

Die Vertreter von VBB und BVG hatten, wie gesagt, schon das Interesse, uns mit Daten zu versorgen. Dabei geht es sowohl um die Mastkoordinaten, die sie aber erst in 1-2 Jahren fertig haben - zumindest der VBB. Bei der BVg liegen sie wohl vor, als auch um Zugänge und Fahrstuhlkoordinaten, die in den aktuellen GTFS-Datensätzen wohl schon vorhanden sein sollten. Dass es auch um Linien und Haltestellenreihenfolgen geht, hat viw ja schon gesagt.

Es ist also wichtig, deswegen hebe ich das noch einmal hervor, dass wir hier auf einen Konsenz kommen, um dem VBB klar und deutlich vermitteln zu können, welche Daten wir benötigen. Das Interesse ist da, sie haben aber ausdrücklich ein Dokument verlangt, in dem wir unsere Anforderungen spezifizieren sollen. Die sollte - nicht jetzt und gleich, aber in näherer Zukunft - passieren. Es geht eben darum - wenn ich das richtig verstand - dass sie auch von vornherein unsere Anforderungen bei ihrer derzeitigen Systemumstellung berücksichtigen können. Gerade in anbetracht an statische IDs. (Dies wird wohl aber durch eindeutige Mastkoordinaten geregelt sein).

Hallo S-Man

Da kann es durchaus Schwierigkeiten geben, je nachdem wie die bisherigen Haltestellen-Daten in einem Verbund erfasst sind.

• Beim AVV (Aachener Verkehrsverbund) hat jede Gesamthaltestelle eine eindeutige Nummer, die Mastpositionen haben eine erweiterte Nummer, die aus der Nummer der Gesamthaltestelle plus weitere Ziffern für die einzelne Mastposition besteht. Das kann man also leicht umsetzen.
• Beim VRS (Verkehrsverbund Rhein-Sieg) hingegen gibt es bisher nur Punkte und Nummern für die Gesamt-Haltestellen. Da ist es erst einmal nichts mit Mast-genauen Angaben. Die gibt es nach unserem Abgleich mit den VRS-Daten nur in OSM (natürlich nicht vollständig). Allerdings gibt es keine eindeutigen Referenz-Nummern für die Mastpositionen. Lediglich die Referenz-Nummer der Gesamt-Haltestelle ist mit VRS:ref=* erfasst.
• Ein-/Ausgänge, Fahrstühle, (Roll-)Treppen usw. sind dann naochmal ein spezielles Thema.

Edbert (EvanE)

[S-Man42]

Hallo EvanE

der VBB hat uns zugesichert, dass sie den Masten gerade statische IDs vergeben. Insofern ist das zumindest beim Abgleich der Daten mit denen des VBB/BVG vorstellbar. Dass andere Unternehmen ein anderes System haben, ist mir klar. Und dass wir da nicht die eierlegende Wollmilchsau finden werden, auch. Aber ich denke, wir sollten erstmal an der Stelle zufrieden sein, was wir dann bekommen könnten. Wie wir dann evtl. weiter verfahren, ist nochmal was anderes, oder?

Alternativ sind wir gerade in der Position, Vorschläge machen zu können, die offenbar gern gehört werden. Wenn also jemand eine Idee hat, wie man das allgemein lösen kann…

Gruß S-Man

[viw]

Hallo Edbert,

wir haben etwas Glück. Da der VBB diese Mastnummern gerade erst aufbaut, wird genau nach dem System des AVV verfahren. Sprich der Bereichsnummer werden 2 weitere Stellen geschenkt um dann die Masten eindeutig zu kennzeichnen.
Nichts destotrotz halte ich es aber auch im VRS für möglich Linienrouten aus dem Fahrplansystem den Linienrouten in OSM zuzuordnen.
Der Vorschlag seitens des VBB war hier eine RoutenID aus der Haltestellenfolge zu generieren. Sprich wenn die Haltestelle 1 2 3 4 5 immer in der Riehenfolge angefahren wird suche ich eine Route in der OSM Datenbank, welche genau diese Bedingung erfüllt. Dabei muss die Network ref und die Liniennummer auch stimmen und im Zweifelsfall auch der Betreiber. Damit wird der Spielraum sehr stark eingegrenzt. Das ginge wahrscheinlich sogar bei Bereichsscharfen Angaben, während OSM schon Mastscharf ist.

[derandi]

Hallo,

ich habe nochmal in den Datensatz reingeschaut und gibt es eine “stop_id” und einen “stop_code”.
Eine ID (13-Stellen) hat jeder Haltepunkt aber zusätzlich manchmal noch einen “stop_code”.
Bsp.

"stop_id","stop_code","stop_name","stop_desc","stop_lat","stop_lon","location_type","parent_station"

(1)
Alle Bahnhöfe haben die UIC Nummer als “stop-id”.

000008012666,"","Potsdam Hbf",,"52.391524000000","13.066260000000",0,900000230999

(2)
Der Busbahnhof in Luckau hat im Datensatz vom VBB 12 Punkte.

900000261577,"","Luckau, Busbahnhof",,"51.851663000000","13.720980000000",1

140000010454,"Luckau","Luckau, Busbahnhof",,"51.851663000000","13.720980000000",0,900000261577

160000000022,"LCBB2","Luckau, Busbahnhof (2)",,"51.851663000000","13.720980000000",0,900000261577
160000000023,"LCBB3","Luckau, Busbahnhof (3)",,"51.851663000000","13.720980000000",0,900000261577
160000000024,"LCBB4","Luckau, Busbahnhof (4)",,"51.851663000000","13.720980000000",0,900000261577
160000000025,"LCBB5","Luckau, Busbahnhof (5)",,"51.851663000000","13.720980000000",0,900000261577
160000000026,"LCBB6","Luckau, Busbahnhof (6)",,"51.851663000000","13.720980000000",0,900000261577
160000000027,"LCBB7","Luckau, Busbahnhof (7)",,"51.851663000000","13.720980000000",0,900000261577
160000000028,"LCBB8","Luckau, Busbahnhof (8)",,"51.851663000000","13.720980000000",0,900000261577
160000000029,"LCBB9","Luckau, Busbahnhof (9)",,"51.851663000000","13.720980000000",0,900000261577
160000000210,"LCBB10","Luckau, Busbahnhof (10)",,"51.851663000000","13.720980000000",0,900000261577
160000000020,"LCBB11","Luckau, Busbahnhof (11)",,"51.851663000000","13.720980000000",0,900000261577

Ich denke die 16 steht in der ID hier für einen Bussteig und die 9 für die Haltstelle. Wofür die 14 steht erschließt sich mir erstmal nicht.

Zusatz: Es gibt noch mehr verschiedene Nummern an ersten 2 Stellen der “stop_ID” z.B. in Berlin haben die Haltestellen eine 69 statt der 16 und die Halltestellen in Polen haben 00.

Andreas

[EvanE]

@S-Man42

der VBB hat uns zugesichert, dass sie den Masten gerade statische IDs vergeben. Insofern ist das zumindest beim Abgleich der Daten mit denen des VBB/BVG vorstellbar. Dass andere Unternehmen ein anderes System haben, ist mir klar. Und dass wir da nicht die eierlegende Wollmilchsau finden werden, auch. Aber ich denke, wir sollten erstmal an der Stelle zufrieden sein, was wir dann bekommen könnten. Wie wir dann evtl. weiter verfahren, ist nochmal was anderes, oder?

Alternativ sind wir gerade in der Position, Vorschläge machen zu können, die offenbar gern gehört werden. Wenn also jemand eine Idee hat, wie man das allgemein lösen kann…

Hallo S-Man

Ja das ist eine gute Situation.

Ich wollte da auch nichts schlecht reden. Aber gerade, wenn man wie ihr beim VBB die Möglichkeit hat, bei der Ausgestaltung noch weitere Aspekte einzubringen, macht es Sinn, möglichst viele Variante in die gemeinsamen Überlegungen einzubeziehen. Deswegen mein Hinweis auf die unterschiedlichen Handhabungen bei AVV und VRS, die wir aufgrund unserer Kontakte zu beiden relativ gut kennen.

Soweit das möglich ist wäre es gut Lösungen zu finden, die sich einerseits in einem breiten Bereich anwenden lassen und/oder sich leicht für spezielle Situation erweitern lassen.

Edbert (EvanE)