Aktuelle Situation: HAFAS vs. DELFI

[SpielenmitLili]

In Anbetracht der aktuellen Situation, die die Abschaltung von DB HAFAS betrifft.

Besteht momentan eine Möglichkeit, die in der line-colors.csv befindlichen Einträge entsprechend so zu updaten, sodass die Linienfarben wieder verfügbar sind?

Oder ist das durch die momentane "Uneindeutigkeit" (es werden keine Operator in der Träwelling-Datenbank gespeichert) nicht ohne weiteres möglich?

[marhei]

Wenn dann wäre wohl eher eine weniger strikte Implémentation auf Seiten der Clients sinnvoll, die auch ohne Betreiber-Information versuchen eine Linie zuzuordnen

[jheubuch]

Es fehlen aktuell jegliche IDs aus der bahn.de-Schnittstelle, des weiteren ist über die aktuell genutzte Schnittstelle keine Betreiber-Zuordnung möglich.

Ich habe mir bereits Gedanken gemacht, wie es bzgl. Linien-Icons weitergehen könnte und werde diesbezüglich Rücksprache mit dem Team von @Traewelling/trwl-admin halten. Vielleicht ist mit diesem Ansatz dann auch eine Migration zu Wikidata und dort hinterlegten Farben/Icons möglich.

[traines-source]

Bin hier nur zufällig drauf gestoßen, hab jetzt nicht weiter geschaut, was ihr/Traewelling so getan habt, außer dass ihr die neue bahn.de API verwendet. Betreiber Infos sind in der bahn.de API eigentlich schon (teilweise) enthalten, aber in den zugattribute o.ä., einer Liste von allgemeinen messages. Falls ihr adminCodes braucht, und auch sonst, ist vermutlich die DB Navigator API (eine wieder komplett andere API, yay), besser geeignet. Evtl. kann da für euch https://github.com/public-transport/db-vendo-client hilfreich sein, da hab ich versucht, ein paar Sachen zu dokumentieren und da gibts auch ein paar dumps von der DB Navigator API.

[vainamov]

Bei Aboard hab ich zum Testen gerade mal probiert, die Linien auf andere Art und Weise zu mappen.

Diese Trip ID der S4 von Hildesheim Hbf (23:06) nach Bennemühlen (00:07 + 1) zum Beispiel

2#VN#1#ST#1740599313#PI#0#ZI#1089426#TA#0#DA#10325#1S#8000169#1T#2306#LS#8000871#LT#10007#PU#80#RT#1#CA#DPS#ZE#4#ZB#S 4#PC#4#FR#8000169#FT#2306#TO#8000871#TT#10007#

enthält praktischerweise die IBNRs von Hildesheim Hbf und Bennemühlen. Also zweimal 8000169 (einmal in #1S#8000169, wobei 1S vermutlich First Stop heißt, und in #FR#8000169, hier wird FR wahrscheinlich für From stehen) und passend auch zweimal 8000871 (in #LS#8000871, LS könnte hier Last Stop sein und in #TO#8000871).

Aboard parsed jetzt aktuell FR und TO und löst mit dem Liniennamen und den IBNRs in einer zum Testen kurz händisch geklöppelten Map die hafasLineId und den hafasOperatorCode für die CSV auf. Und das klappt erstaunlich gut.

---

tl;dr: Es wäre natürlich ein Haufen Arbeit, aber wir könnten unsere CSV um die IBNRs der Start- und Endhaltestelle der Linien erweitern. So könnten wir im Endeffekt nicht nur erstmal überhaupt wieder Linien matchen, sondern sollten in der Theorie auch die Konflikte die wir teils haben (#26) lösen können.

[SpielenmitLili]

Du meinst also die .csv entsprechend um den Parameter FirstStop und ggfs. LastStop zu erweitern?
Müsste man aber auch im Hinterkopf behalten, das Züge nicht immer an selben Stationen beginnen/enden.

RB 23 hat alleine wenn sie offen sind als mögliche Starts und Stopps Mayen Ost, Andernach, Koblenz und Limburg. Das würde bei manchen Linien dann dementsprechend die Datei ein bisschen aufblähen I guess

[vainamov]

@SpielenmitLili Muss gar nicht so spezifisch sein, die Bedeutung der Station ist ja unerheblich. Die Linie 1 in Hannover fährt von Langenhagen mal nach Sarstedt und mal nur bis Laatzen. (Die Stationen haben bei Fahrten in die andere Richtung in diesem Fall nochmal andere IBNRs). Ergibt also 6 relevante Station-IDs, aber was davon jetzt Start oder Ende ist spielt ja keine Rolle. Beim Matchen muss man eben nur prüfen, dass sowohl Start und Ende des Trips in der Liste enthalten sind.

{
  id: '8-webuet-1',
  name: 'STB 1',
  operator: 'ustra-hannoversche-verkehrsbetriebe-ag',   
  stations: [614078, 616282, 638683, 638700, 638766, 638767],
},

In der CSV könnten die entsprechend auch einfach separiert in einer Zelle stehen.

[MrKrisKrisu]

Ich hebe gerne nochmal den Vorschlag aus #91 (comment) hervor, dass ich weiterhin eine zentrale Datenhaltung bei Wikidata bevorzuge. Einige Daten sind dort schon vorhanden (siehe https://www.wikidata.org/wiki/User:Mkkagain/Verkehrslinien_in_Deutschland), es müsste aber noch einiges gepflegt werden.

Die Herausforderung an dieser Stelle wäre dann eher zu schauen, wie man die Daten auf vorhandene Fahrten mappt. Ich würde mich wieder ungerne an semi-permanente IDs binden, sehe aber aktuell keine andere „gute” Lösung.

Andere Ideen wären ggfs. ein Mapping von Bounding Boxes, Linienbezeichnungen, ggfs. Haltestellen (sofern in Wikidata erfasst - häufig nicht der Fall).

Beispiel - Linie S5 der AVG: https://www.wikidata.org/wiki/Q126901689

In dem Beispiel sieht man, dass die Farbe und die Endpunkte (Wikidata Objekte) zugewiesen sind.
Zusätzlich ist hier sogar noch das Linienicon als SVG gespeichert (das wäre der Idealzustand, davon kann man aber wahrscheinlich nicht immer ausgehen, da das Anlegen von SVGs für die Allgemeinheit wahrscheinlich auch nicht so trivial ist.).

[SpielenmitLili]

@SpielenmitLili Muss gar nicht so spezifisch sein, die Bedeutung der Station ist ja unerheblich. Die Linie 1 in Hannover fährt von Langenhagen mal nach Sarstedt und mal nur bis Laatzen. (Die Stationen haben bei Fahrten in die andere Richtung in diesem Fall nochmal andere IBNRs). Ergibt also 6 relevante Station-IDs, aber was davon jetzt Start oder Ende ist spielt ja keine Rolle. Beim Matchen muss man eben nur prüfen, dass sowohl Start und Ende des Trips in der Liste enthalten sind.

{
id: '8-webuet-1',
name: 'STB 1',
operator: 'ustra-hannoversche-verkehrsbetriebe-ag',
stations: [614078, 616282, 638683, 638700, 638766, 638767],
},
In der CSV könnten die entsprechend auch einfach separiert in einer Zelle stehen.

Joa, habe schon so gedacht, das es am Ende ja keinen großen Unterschied macht, was jetzt Start und Ende ist. Meinte nur generell, das es je nach Linien auch paar mehr sein können wodurch die Zeilen teils bisschen lang sein könnten.

Da die aber hauptsächlich ja eh nur vom Programm gelesen werden sollen, macht das nicht so viel Unterschied letztendlich.

Fände diese Umsetzungsidee von meiner Perspektive eigentlich sowohl leichter zu Pflegen als auch einzubinden und damit eigentlich echt gut

[luna-cant-code]

Mal kurz meine zwei (deutschsprachigen) Cent dazu:

Ich hab mich im PR #284 schon dazu geäußert...Da sich Transitous die Daten ja scheinbar u.a. aus den DELFI-Datensätzen zieht und die im GTFS-Format vorliegen, könnten wir nicht einfach dahinwechseln?

In meinem Kommentar zum PR hab ich das auch mal bisschen ausufernd vorgeschlagen.

Die in der routes.txt vorhandenen Route IDs und Agency IDs sind ja alle einzigartig, sodass ein Mapping problemlos möglich sein sollte.

So hätten wir dafür einen Single Point of Truth und müssten uns z.B. im VRR eigentlich nur beim Betreiberwechsel drum kümmern, die Route IDs zu ändern.

Mit den GTFS-Daten wären wir halt nicht mehr auf die HAFAS-Daten angewiesen.

Wie seht ihr das?

[MrKrisKrisu]

Da sich Transitous die Daten ja scheinbar u.a. aus den DELFI-Datensätzen zieht

Transitous nutzt dieses Repo für die DELFI-Daten als Quelle. Dazu wird der lineName und der delfiAgencyName für das matching genutzt. Siehe dieses Skript.

Die Spalten hafasOperatorCode und hafasLineId werden dafür nicht gebraucht.

Ich wüsste ad-hoc kein Projekt, welches damit noch matched. Falls das so sein sollte würde ich mich auch dafür aussprechen, diese zwei Spalten zu löschen.

[MrKrisKrisu]

So hätten wir dafür einen Single Point of Truth

Mir wäre es ja eher am liebsten, wenn die Daten alle bei Wikidata liegen würden (siehe #91) und in diesem Repo nur das Matching zwischen Wikidata ID und anderen notwendigen IDs gespeichert wird (Das speichern des agencyNames bei Wikidata sehe ich nicht als sinnvoll an).

[luna-cant-code]

Da sich Transitous die Daten ja scheinbar u.a. aus den DELFI-Datensätzen zieht

Transitous nutzt dieses Repo für die DELFI-Daten als Quelle. Dazu wird der lineName und der delfiAgencyName für das matching genutzt. Siehe dieses Skript.

Wenn ich's also richtig verstehe, bräuchten wir also eigentlich nur die Linie in dieser line-color-repo so zu schreiben, wie es in den GTFS-Daten quasi steht und dann den AgencyName dahinter?

Nur als Beispiel für meine etwas müde Birne:
Dann müssten wir bei der Wuppertaler Schwebebahn aus dem bisherigen Schwebebahn unter lineName die 60 machen, hinten bleibt's dann bei der 8015 als "delfiAgencyID" bzw. "Schwebebahn" bei delfiAgencyName

Die Spalten hafasOperatorCode und hafasLineId werden dafür nicht gebraucht.

Ich wüsste ad-hoc kein Projekt, welches damit noch matched. Falls das so sein sollte würde ich mich auch dafür aussprechen, diese zwei Spalten zu löschen.

+1 von mir, mir fällt auch kein Projekt mehr ein.

So hätten wir dafür einen Single Point of Truth

Mir wäre es ja eher am liebsten, wenn die Daten alle bei Wikidata liegen würden (siehe #91) und in diesem Repo nur das Matching zwischen Wikidata ID und anderen notwendigen IDs gespeichert wird (Das speichern des agencyNames bei Wikidata sehe ich nicht als sinnvoll an).

Mittelfristig wäre es wahrscheinlich wirklich nicht schlecht, wenn wir dann Wikidata als Art Datenbank nutzen.
Zu den agencyNames: Nutzt Träwelling das nicht für die Statistiken oder woher zieht sich das die Namen?

Da würde ich persönlich dann tatsächlich auch die agencyNames bei Wikidata eintragen.

Wenn schon Single Point of Truth, dann auch vernünftig und komplett 😁
Doppelte Datenhaltung ist halt immer kompliziert und meh...

[MrKrisKrisu]

Wenn ich's also richtig verstehe, bräuchten wir also eigentlich nur die Linie in dieser line-color-repo so zu schreiben, wie es in den GTFS-Daten quasi steht und dann den AgencyName dahinter?

Prinzipiell korrekt.

Zu den agencyNames: Nutzt Träwelling das nicht für die Statistiken oder woher zieht sich das die Namen?

https://github.com/Traewelling/transitous-wikidata-operator-matching