 Ja, moin. Schön, dass ihr hier so zahlt euch zu dieser viel zu frühen Vorlesung über Bahnen gekommen seid. Ihr hättet euch das auch in der Aufzeichnung angucken können, also danke fürs Frühaufstehen. Ich fange diesmal, also ich habe, diesmal geht es um Bahnappis und ein bisschen internationalen Ausblick. Als ich den Talk reingestellt hatte, hatte der irgendwie noch ein bisschen anderen Inhalt. Das ist ein bisschen weniger international geworden, aber naja. Und diesesmal erkläre ich sogar, warum ich das eigentlich alles kann. Also ich habe einen ähnlichen Talk schon mal auf der GPN gehalten und da habe ich einfach angenommen, dass alle wissen, warum ich so viel darüber weiß. Das war vielleicht nicht so schlau. Also fangen wir damit an. Also erstes mal ganz klar, ich fahre sehr viel Bahnen und dann kriegt man so ein bisschen mit, wie die Bahnen und ihre Informationen so funktionieren. Das ist aber nur, weil ich so viel Bahnen fahre, habe ich irgendwie die Motivation mich noch mehr damit zu beschäftigen, weil das ist echt schlecht, was die Bahnen da abliefert. Das kennen wir alle. Und ich habe mal nachgeguckt, also mindestens seit dem 13. August 2015 mache ich den Kram, weil da war der erste Commit in einem Repo von mir. Allerdings hieß das schon V2, ich habe keinen V1 mehr gefunden. Aber ich habe auch ein anderes Repo wieder mit, dass V3 heißt, mit V1 angefangen. Ich war damals nicht so schlau, was wäre so die Rougant geht. Nun ja, also mindestens dann. Und inzwischen Maro.de werden die meisten kennen. Die Seite hat inzwischen so 3.900 Nutzer im Monat. Also User, nicht Sessions, finde ich ganz erstaunlich, dafür, dass ich da nur Werbung mache und das eigentlich nur durch Leute, so erzählt anderen Leuten, dass sie da die Informationen herkriegen. Das ging übrigens schon soweit. Also ich weiß, dass die DB-Launch in Berlin nutzt das regelmäßig. Die Go-Ahead-BW, das ist eine Privatbahn in Baden-Württemberg, die hat das auf ihren Diensthandys installiert, auf dem Homescreen. Also die können sich auch gerne mal melden. Also vielleicht kann ich den Features einbauen, die denen helfen. Das könnte man mal überlegen. Ich brande das auch für die, dann kostet das halt. Also ich wurde jetzt auch mehrfach von der Bahn schon eingeladen zu so einem Thema. Ich soll denen mal ein bisschen was erklären quasi. Das ist je nach dem, wer von der Bahn einlädt, sehr schleppend. Die Sistelt zum Beispiel, da dauert alles. Aber ein paar sind schon zustande gekommen. Auf diese Maro.de habe ich inzwischen so 20 verschiedene Abys angebunden, die rein von der DB sind. Da kommen dann nochmal so theoretische Möglichkeiten für ÖBB, HVV, BVG, AVV, alle möglichen Verkehrsverbundete zu. Aber das ist so das, was ich rein von der DB hat für den Kerngedöns. Allerdings wollen wir uns jetzt ja Bahnabys angucken. Eigentlich auch nicht, weil ich mache ja so ein bisschen internationalen Ausblick und das ist gar nicht direkt Bahn. Deswegen dann alle Bahnmitarbeiter. Euch tritt es nicht ganz so hart diesmal. Denn wir gucken uns eine Firma namens HCON an. Die machen ein Produkt namens HAFAS. Und das ist der Kernding, was zum Beispiel den DB Navigator und Bahn.de powered. Und halt auch die ÖBB, den HVV, die BVG in Berlin, alles mögliche. Die schreiben von sich selbst, sie sind der führende Software Spezialist für Verkehrsplanung in Europa. Das mag stimmen, weil sehr viele nutzen den. Also die, das ist aber auch sehr traurig. Weil ich kenne ja, was sie machen. Also ich bin mir sicher, dass wenn wir uns hier jetzt hinsetzen, wir können das besser. Wir kriegen die aber einfach nicht vertrieben, weil die so tief in den ganzen Verkehrsverbünden und Bahnunternehmen stecken. Die können halt nicht mehr ausgetauscht werden. Ist auch ein Konzept. Und was sie auch von sich schreiben. Und ich glaube, die meisten sehen das gar nicht so als Qualitätsmerkmal. Es ist eine Siemensfirma. Ja. Naja, schauen wir uns mal dieses Haarfass an. Wofür steht denn eigentlich Haarfass? Die sind nicht so kreativ gewesen. Das ist nämlich einfach das HAKON Fahrplan-Auskunftssystem. Okay, wir mussten wohl. Und ich habe mal so auszugsweise ein paar Kunden, der Aachener Verkehrsverbund, Berliner Deutsche Bahn und da ganz viele verschiedene von den Deutschen Bahnen haben die extra gekauft. Das ist nicht so, dass die Bahn das als Gesamtes kauft, sondern DB Netze hat da auch noch mal was. Weil, ist ja eine eigene Firma, da muss man schon mal mehr Geld ausgeben für. Ja, Hamburg benutzt es, Schleswig-Holstein benutzt und die ÖBB benutzt es. Da sind auch mehr so genau, so die SNCB zum Beispiel benutzen die auch. Die sind jetzt für so einen Vergleich aber überhaupt nicht spannend, weil die haben einfach überhaupt keine Ahnung, was hier in Deutschland los ist, während die ÖBB halt auch Informationen über deutsche Züge hat. Was sie halt jetzt sehr spannend macht, um mal zu vergleichen, was weiß die ÖBB und was weiß die DB-Überträge. Gucken wir uns mal mal an, was kann man mit dem Ding denn machen, weil die sind ja der führende Software-Spezialist dafür. Also müssen die doch jetzt echt Features, Features, Features haben. Stimmt, haben sie auch, das ist vielleicht auch eines der Probleme. Aber da gucken wir mal, also was können die denn, die können routen, das ist schon mal ganz gut. Sie haben eine Abfahrtstafel und eine Ankunftstafel, übrigens nicht beides, also du kannst nur ein Opfer davon abfragen, und wenn du beides haben, jetzt musst du auch beides abfragen, weil wer will denn bitte beides gleichzeitig, offensichtlich niemand. Naja, Station suchen, Station suchen über Geo-Koordinaten, Details zu einer Fahrt und nochmal, aber anders, und ich meine jetzt nicht irgendwie api-technisch anders, sondern es ist einfach ein separator Endpunkt, der einem auch andere Informationen gibt. Also manchmal, das ist das Problem. Deswegen benutze ich zum Beispiel für die Details Seite drei verschiedene Arpies von denen, weil nur wenn du alle drei verbindest und so, naja, wenn die nichts hat, dann hat die andere wahrscheinlich was. Warum das nicht einheitlich geht, weiß ich nicht, aber das würde ja dem Kunden helfen, wenn es einheitlich wäre, und das ist irgendwie nicht so die Stärke von denen, habe ich das Gefühl. Kundenfreundlich ist es nicht, weil die wollen Geld machen. Naja, und sie können Fahrten suchen, also zeig mir mal Infos zu ICE 42. So, naja, wie spricht man sie an? Das wird es ein bisschen technischer, aber das muss man mal gesehen haben, weil das doch speziell ist. Also die machen sehr viel XML, und auch XML, was aber erst XML ist, wenn man ein bisschen Stringreplace macht, weil sonst ist das einfach invalid. Das kann man halt nicht pausen, bis man Strings replaced. HTML, das ist zum Beispiel das, was Bahn.de macht. Die machen API Reckards, wo direkt HTML zurückkommt, weil so API Driven, das ist ja viel zu modern. JSON können sie, und JSON aber anders, weil das wäre langweilig, wenn die das gleiche haben. Man muss ja sagen, Harfers, also Beispiele für so Harfers Endpunkte sind, Crurry-Excel, Train-Search-Excel, Ajax-Get-Stop-Excel. Die fangen, die enden immer mit Excel, das ist so ein bisschen, und dann kann man die halt noch so einstellen, was man denn haben möchte. Möchte man mit dieser Ajax-Get-Stop-Excel XML reden, möchte man HTML zurückbekommen, möchte man JSON zurückbekommen, und dieses JSON aber anders ist quasi ein anderer Endpunkt, nämlich mGate.exe, der nochmal das genau gleiche Featureset hat. Du musst es aber komplett anders ansprechen, du kriegst komplett andere Ergebnisse. Also das API sieht einfach komplett anders aus. Die Infos sind aber eigentlich dieselben. Also meine Theorie ist, das mGate ist halt MobileGate, die haben festgestellt, dass, was sie jetzt haben, ist für Apps überhaupt nicht sinnvoll zu benutzen, weil das muss man halt API-Draven machen, und das war wohl nicht Konzept vorher, weil sie eben explizit dieses HTML überall sprechen. Aber das ist nur so eine Theorie, sie haben es jedenfalls, freut mich, weil dieses JSON aber anders ist halt einheitlich strukturiert. Also da sehen die Responses sehr ähnlich aus, auch über die Funktionen hinweg. Einfach, das heißt man muss weniger Pausingarbeit für die einzelnen Schnittstellen machen, das ist prinzipiell erstmal gut. Deswegen nutze ich das auch. Und da reden wir jetzt auch mal kurz drüber, wie kann man da denn so Config machen? Also wie kann man so ein mGate sagen, was man eigentlich ist, ich hab da mal so ein Snippet, das ist jetzt von der DB, wie man da sieht. Da sind so Sachen wie der Typ, das ist halt Android, was das ist, der DB Navigator, eine Version und eine Extension, und darunter noch eine Version, weil eine reicht scheinbar nicht. Ich hab keine Ahnung, was das V mitmacht, wenn man es aber nicht so mit schickt, geht's nicht. Die Extension ist, also man kann im Hafas noch so extra Features beibringen. Wahrscheinlich geht man zu Hakon und sagt, wir brauchen dieses Feature, dann sagen die ja, können wir machen, kostet x Geld, und dann hat man so x Dinge, damit man halt nochmal vom Standard abweicht, weil eigentlich ist das Ding ja standardisiert, eigentlich. Da spricht jetzt auch dieses zweite Version rein. Also hier steht jetzt 118, der DB Navigator benutzt 115, und es geht, glaube ich, alles zwischen 110 und 125 beim DB Navigator. Manchmal unterscheiden die sich ein bisschen, also 115 ist anders als 120, ist aber gleich wie 118 benutze ich auch nur, weil ich glaube die BVG war das zuletzt, die kann kein 120, die können aber 118, das sieht genauso raus. Also ich hab noch nicht rausgefunden, wo der Unterschied ist. Wahrscheinlich in irgendeinem Detail Ding unterscheidet sich das, und wenn man Dokudat so hätte, wäre das ersichtlich. Die rücken dir aber nur raus, wenn du das auch kaufst. Von daher hab ich keine Dokur, also deswegen auch vielleicht gibt es bei so ein paar Dingen, die ich aufzeige, eine super easy Lösung, du musst nur dieses Fleck hier können, verstehen und mitschicken, und dann geht das alles. Es benutzt aber bisher keiner, den ich gefunden habe, deswegen kenne ich es nicht. Ich suche mir halt nur aus den verschiedenen Benutzern davon zusammen, oh, das schicken die mit, und dann probiere ich so ein bisschen rum, ah, das könnte ich ja mitschicken, dann macht die AP das, halt reverse engineering. Und hier haben wir so Authentication. So, jetzt wird es ein bisschen spannender noch. Offensichtlich machen sie Authentication. In dem Fall ist das aber einfach, diese AID ist einfach immer gleich, die musst du mitschicken, wenn du die nicht hast, ist also quasi ein Scherz Secret. Da das in der App steht, hätten sie sich das auch sein lassen können eigentlich. Aber nun gut. Gucken wir uns mal was anderes an. Das hier ist von einem anderen Harfers Benutzer. Der war nicht so verbose. Das ist einfach Typ, geht noch, Web. Das ist offensichtlich ein Testclient. Habe ich aber nicht aus dem Testclient, das war der Produktivclient. V100, wahrscheinlich muss das Feld belegt sein. Ich weiß nicht, warum sie lang DOI machen. Das sind die einzigen, alle anderen nehmen DE. Ich vermute, Harfers hat das auch spezifiziert, dass man bitte Two Letter Country Code nimmt für solche Dinge, also Sprachcode. Die hatten keinen Bock. Das war übrigens der AVV, also der Aachner Verkehrsverbund. Die benutzen das seit einer Weile für ihre Website, deswegen Typ Web. Und die waren wohl zu faul vom Testbetrieb umzustellen, weil das ist ja auch Arbeit. Und so funktioniert es auch. So, und jetzt hatten wir ja schon Authentication. Und das Ding hat eine Krypto. Also es ist eine Checksum, die man mitschicken muss. Und da ist tatsächlich Krypto involviert. So richtig ist es aber nicht. Also die Checksum ist das da. Man schickt das MD5 von dem Request, den man hinschickt und dann von dem MD5, nochmal MD5 und appendet das Secret. So, wo kommt das Secret her? Ja, also das Secret steht, tatsächlich, man hat nur ein paar Teile und es ist effektiv Krypto, weil es ist AES197CBC verschlüsselt. Der Text, den man entschlüsseln muss, steht in der Config von deinem Client und der Key ist einfach hardcoded da drin. Der ist auch für alle Harfers Dinge gleich. Also ich habe noch den Harfer vorgefunden, der auch so ein Secret benutzt. Der hat den gleichen Key wie die DB. Wahrscheinlich ist es einfach der Harfers Key. Und falls ihr das rausfinden sollt, also A, ich habe das eventuell auf dieser Folie stehen irgendwo, dürft ihr suchen. Ansonsten verbindet doch mal diesen String mit diesem String und macht vielleicht das, was ich da drüber stehen habe. Es könnte das Ergebnis rauskommen für die DB. Aber falls ihr euch an den letzten Talk, falls ihr den gesehen habt, die DB und Sicherheit, also das ist ungefähr das Level, wie halt ein User DB nehmen, ein Passwort exklusiv und das über die gesamte Firmarschereien. Und das absichern durch, wenn du dich damit einloggst, musst du so einen Haken anmachen, dass du das niemandem sagst. Das ist ungefähr das Level an Krypto, weil es steht halt alles drin. Ist ja auch klar, das muss so eine App ja auch wissen. Die kann ja nicht Dinge tun mit Fans wie Krypto, wenn das einfach jeder benutzen kann ohne irgendwas. Wahrscheinlich stand auch hier ein Manager da, sagte, das geht nicht, das sind unsere Daten, wir brauchen Krypto. Und dann stand der Entwickler da, das geht nicht, das muss aber und das ist das Ergebnis. Es ist jetzt Krypto und Anforderung erfüllt, war halt sinnlos. Nun gut, das ist aber eigentlich noch mal eine, geben wir mal viel Datenlage ein. Also ich mache jetzt mal einen Vergleich von verschiedenen, die ich da so gefunden habe. Wir suchen mal München-Hobbahnhof und gucken, finden wir München-Hobbahnhof. Weil das ist ja nicht selbstverständlich, dass die ÖBB zum Beispiel in München kennt. Das ist ja nicht so ähnlich, weil da fahren ÖBB-Züge hin. Aber wer weiß. Und auch halt auch bei den anderen Verkehrsverbunden. Also die DB natürlich hat den, hat halt München-Hobbahnhof. Die ÖBB auch. Der AVV auch, aber fünfmal. Denn nah ist H auch, aber siebenmal. Der AVV hat zweimal und die BVG einmal. Und das sind übrigens alle zusammen gesammelten Vorschläge. Also ein paar davon, so wie Gleis fünf bis zehn, sind einfach betrieblich zu erklären, gibt es diesen separaten Bahnhof. Das hat aber den Kunden eigentlich echt nicht zu interessieren und macht doch bitte einfach einen München-Hobbahnhof für alles für den, weil das ist das relevante für den Kunden. Außerdem sitzt sie sich manchmal mit der Schreibweise nicht einig. Deswegen gibt es manche, die gedoppelt. Und sehr spannend, dieses München-Hobbahnhof. Das gibt es nur bei der BVG. Die hat auch nochmal eigene Daten, weil da stehen so Koordinaten dran. Und die sind bei den anderen identisch. Und die BVG hat da einfach nochmal eigene. Scheinbar hatte die BVG Lust auf eigene Daten, statt sich einfach bei der DB die Daten zu holen, weil die wissen das wahrscheinlich am besten, weil DB Station Service macht diesen Bahnhof. Okay, offensichtlich wollten sie extra Aufwand betreiben. Gucken wir uns mal an, was da noch so mitkommt, weil wenn man nach Stationen sucht, bekommt man mit, welche Produkte fahren hier. Also fährt hier, dann kriegst du eine Liste mit ICE, RERB und so weiter. Was es halt so an Produkten gibt. Und wie viele finden die einzelnen Havers-Schnittstellen davon? Die DB 53 Stück. Das ist halt einfach zu erklären, so U-Bahn, S-Bahn, alles. Und ab regional kennt es auch Linien. Also dann gibt es die U1, die U2, die U3 und die U4 separat. Und bei Zügen haben sie nur die Kategorie, also ICE, ICE und so weiter. Die ÖBB hat da Null, die haben immer Null. Also auch wenn man Wien sucht, kennen die das nicht. Entweder hat niemand denen gesagt, dass es dieses Feature gibt und die das nicht anfordern können. Oder die wollten es nicht extra kaufen, weil ich vermute es kostet extra, weil alles da kostet extra, so wie ich rausgefunden habe. Oder sie brauchen es einfach nicht. Also wer auch hier ÖBB, wer echt nett für so einen Kunden, dass er sieht, was es da gibt, kann man im DB Navigator zum Beispiel. Aber die ÖBB braucht sowas nicht. AVV hat fünf, was einfach nur eine Teilmenge ist. Die kennen halt ein Padige, aber nicht alle. Und da gibt es auch kein Muster. Der Nahsh kennt zehn. Der HVV einen, aber auch nicht, weil das ist ein leerer String, der da mitkommt. Also Filtering wäre ganz gut gewesen. Die BVG genauso, die hat den gleichen leeren String. Und bei dem Nahsh finde ich sehr spannend. Ich habe mal aufgelistet, was es da gibt. Also unternahm das hier. Es sind jetzt halt sechs verschiedene, da fehlen also noch vier. Diese vier waren halt konkrete Züge. Und ich habe keine Ahnung, warum diese vier. Dieser EC89, der fährt übrigens von München über Österreich nach Italien. Das ist die falsche Richtung für den Nahsh. Das schießt sich Holstein. Ich hätte erwartet, also wenn spezifisch dann vielleicht so ein dänischen IC von Hamburg durchschließt sich Holstein weiter nach Ahus oder so. Das wäre verständlich gewesen, warum der den kennt. Aber warum kennt er den von München über Österreich nach Italien? Kann ich nicht, ist halt so. Das ist gemein. Also bei vielen dieser Dinge, ich nehme das einfach hin. Und entweder sind die Daten so, dass ich glaube, okay, damit könnte man sinnvolle Informationen bereitstellen oder halt nicht. Oder man sucht sie sich zusammen, indem man halt alles abfragt, was er hat. Und im Idealfall ist die Kombi daraus sinnvoll. Das mache ich ja ganz gerne. Die Kombi nutzen, weil dann geht es. Das ist einfach so. Das ist einfach so. Das ist einfach so. Das wäre auch ein Verkaufsfeature für dieses Hafer, wenn es einfach sinnvoll funktionieren würde. Wobei hier einfach mein Wissen fehlt, wie ist der Zusammenhang? Also muss die DB quasi alle Daten liefern. Und Hafer ist nur die Api und die Software dafür. Und wie ist dann der Zusammenhang mit den anderen Verkehrsverbünden? Weil die kennen ja teilweise, die tauschen ja auch Informationen aus, weil die DB zum Beispiel hat ja auch die Busse teilweise sogar mit Verspätungen. D.h. die müssen sich ja austauschen. Das wäre ja sinnvoll, dass man da irgendwie einen Standard macht. Wird es auch geben, aber halt wahrscheinlich steht dann da immer irgendeiner sagt, nee, mit euch spiele ich aber so nicht. Anders kann ich mir nicht erklären, warum das so unterschiedlich ist. Also wahrscheinlich müsste man einfach mal besser reden. Aber es ist halt auch irgendwie Informationsaustauschen. Das kriegt die Bahn ja schon zum Kunden nicht hin. Wieso sollte die das zu anderen? Und im Idealfall meistens steht dann auch irgendjemand und sagt, das kostet aber Geld. Weil das belastet ja meine Server und das habe ich tatsächlich auch schon so von DB-Ding gehört. Nee, wir können keine Open Data machen, weil dann haben wir eine Api, der zahlt keiner für. Das können wir nicht abrechnen. Wer zahlt dafür? Und das ist halt auch bei diesem Informationsaustausch. Da gewinnen ja eigentlich beide Seiten. Also man kann ja sagen, der HVV kennt jetzt Fernverkehrsdinge in Hamburg. Da gibt es auch die lokalen Dinge der Bahn. Und dann gewinnen beide mehr Informationen. Das wäre ja sinnvoll. Und dann haben wir halt auch beide auf ihren Server in Belastung. Also das kann man ja quasi verrechnen. Naja, dafür, dass ihr uns eure Informationen geben wir auch unsere her, wenn man irgendwie so argumentiert. Scheinbar aber nicht. Wahrscheinlich rechnet da nämlich dann tatsächlich jemand aus, das kostet uns genau so viel Euro und euch weniger. Das geht so nicht. Weiß ich nicht. Das ist wieder so, möchte ich glaube ich auch gar nicht genauer wissen, wie die Bahn, warum das so ist. Das ist doch bitte nicht das sehr für alle besser. Naja, gucken wir uns mal die Daten an. Und zwar so eine Abfahrtstafel. Also ich weiß nicht mehr, welcher Tag. Es wird irgendwie kurz vor 15 Uhr gewesen, 15, 13 gewesen sein, weil das war der nächste Zug, der in Essen abfährt. Find ich das den bei der Abfahrtstafel bei den einzelnen Schnittstellen. Also die DB, klar, wie hat den? Die ÖBB hat den auch. Und da ist ganz gut, der bei Fernverkehrszügen hat die ÖBB im Gesamten bei dieser Abfahrtstafel ganz gute Daten. Wenn es dann regional wird, also U-Bahn und Trams und so ein Kram fehlt in der Regel komplett, ist hier auch irgendwie verständlich. Und EES, die haben einfach oft keine Verspätung. Da wissen die, da fährt einer Ehe, aber sie wissen nicht, ob er Verspätung hatte oder nicht. Die Bahn hingegen schon. Ist auch wieder warm. Wenn ihr schon die Informationen teilt, dass dieser Ehe fährt, teilt doch auch die Echtzeitinformationen. Das würde bestimmt Leute aus Österreich, die in Deutschland unterwegs sind, freuen, die ihr ÖBB-Scotty benutzen könnten und nicht noch den DB-Navigator bräuchten. Aber das wäre ja nett zum Kunden. Der HVV kennt das auch. Der NASH kennt diesen Zug nicht. Der kennt auch fast nichts, was da fährt. HVVV genau so. Der hat ein paar Verspätungen. Das sind, wenn ich so kurz überflogen habe, in der Regel die Züge, die halt aus Hamburg kommen und über Hamburg fahren. Dann gibt es auch Verspätungen in Essen dafür. Das tut dieser Zug hier nicht, deswegen gibt es den nicht. Aber die BVG kennt Essen nicht. Okay. Gucken wir uns mal einen anderen Bahnhof an, weil das war jetzt ein bisschen unfair, weil Essen liegt in NRW. Das ist relativ Aachen auch. Also ist es wahrscheinlich, dass Aachen diesen Zug kennt, einfach weil der in der Nähe fährt. Guck uns mal Hamburg an. Auch hier, diesen Zug wollten wir, kurz bevor dieser abgefahren ist, DB-HTN. ÖBB ebenso, auch hier wieder, das kennt AFFW nicht. Es kennt aber Züge in Hamburg, und zwar auch wieder die, die durch NRW fahren. Also es wird quasi nur gesünkt, was auch bei mir fährt. Alles andere weiß ich nicht. Nahesfahrer kennt alles, also kennt tatsächlich auch alles in Hamburg, der AFFW auch, und die BVG kennt wieder nur nichts da. Also kennt immerhin Hamburg, also es existiert in Hamburg in Berlin, aber da fährt halt nicht wirklich was. Und das zeigt so ein bisschen das Muster. Offensichtlich kennen die Verkehrsverbünde, am ehesten das, was halt auch bei ihnen fährt. Und dann tracken sie aber auch in die Zukunft weiter. Also wenn er halt schon nicht mehr bei sich fährt, dann hätte man ja auch sagen können, okay, wenn der bei mir in der Nähe am Bahnhof ist, dann kenne ich die Daten, weil ich diesen Bahnhof sinke. Und wenn er dann halt weg ist irgendwo in Niedersachsen, dann kenne ich den nicht mehr, sondern in meinem Bereich, wo ich Informationen breitstellen möchte. Dann wäre das ja auch irgendwie für den Kunden ersichtlich, weil der sieht dann, naja, so ein Hamburg, finde ich einfach nicht in der Suche, wenn ich in der AFFW Seite nachgucken möchte. Gibt es aber, das ist ja verwirrend. Also es wäre eigentlich dann schöner zu sagen, naja, dann findet man auch nur Stationen bei sich, weil nur da habe ich ja auch Informationen. Aber nee, das wird halt, Stationen werden einfach alle gesünkt und die Informationen zu den Zügen dann nicht. Also das ist, glaube ich, verbesserungswürdig. Und das können wir, glaube ich, auf vieles hier setzen. Das ist, die Idee ist gut, aber ein bisschen mehr Aufwand betreiben, bitte, dann. Danke. Ja, gucken wir uns noch ein paar mehr Dinge an. Und zwar tatsächlich jetzt mal so ein sehr direkten Vergleich über Details eines Zuges zwischen DB und ÖBB. So, wir gucken uns auch explizit nur den Fernverkehr an, weil das kennt die ÖBB-Prinzipiell auch, weil bei der ÖBB darf man ja auch einfach in der Deutsche DB-Ticket einfach buchen. Das heißt, die haben da ja schon so ein bisschen Kooperation. In diesem Fall wollen wir uns den IC 124, der fährt von Frankfurt nach Amsterdam. Und ich habe um ungefähr 15, 20 abgefragt, die Arpies. Nur zu gucken. Das ist das deutsche Ding. Und ich hoffe, das kann man so einigermaßen lesen. Okay, das Rot ist da echt schlecht zu sehen, aber muss ich ein bisschen erzählen. Die DB im Allgemeinen, die ist sehr gut da drin, Verspätung von früher zu vergessen, weil das würde ja zeigen, also dann könnte jemand Statistik machen und dann würde man ja zeigen, dass man nicht gut ist. Das ist so tatsächlich wohl die Argumentation, dass sie Angst haben, dass jemand eine Statistik darüber macht. Hint, falls die Personen hier den Talk sehen, das passiert trotzdem. Also ihr könnt auch einfach die Informationen geben, ihr verhindert damit nichts. Und wahrscheinlich wäre das auch weniger Aufwand, die Daten nicht noch zu löschen, weil ihr müsst sie dann in einer Schnittstelle löschen. Bei euch ja nicht, weil ihr wollt ja trotzdem noch die Statistik haben und die habt ihr ja auch. Kann man übrigens Geld sparen, wenn man Dinge, die Aufwand betreiben, nicht macht. Ich glaube, das braucht die DB gerade echt besonders seit. Ich glaube, vorgestern die Pressemitteilung. Naja, ansonsten sieht das ja ganz solider aus, so an Infos. Emmerich hat das GR steht übrigens für Grenze. Deswegen gibt es bei Emmerich keinen Halt, weil da wird einfach durchgefahren. Aber aus betrieblichen Gründen steht immer bei Auslandsfahrten der Grenzpunkt mit dran. Das ist die ÖBB. Hier sieht man, natürlich vergessen nicht, die wissen trotzdem noch, wie viel Verspätung der Zug in Frankfurt-Flughafen hatte. Allerdings ist dieses Halt entfällt etwas komisch, weil das ist eine Service-Meldung, die an diesem Bahnhof steht. Also es steht, bei der ÖBB findet man, dass Frankfurt-Flughafen-Fernbahnhof angeblich ausfällt, aber dann doch nicht, weil die Abfahrt wurde ja nicht markiert, weil sie sehr wahrscheinlich auch der Fall war, dass er halt einfach am Flughafen gestartet ist. Warum schreibt ihr das dann da dran, wenn das nicht stimmt? Und ansonsten ist hier sehr spannend. Ansonsten ist es ja in Duisburg gleich, in Oberhausen auch. Offensichtlich haben die beiden aber eine andere Prognose und Software und Analyse, wie sie prognosizieren, wie verspätet ein Zug ist. Offensichtlich funktioniert das in Österreich besser, weil die glauben, wenn er mit plus 8 in Oberhausen losfährt, dann ist er mit plus 2 in Amsterdam. Die Bahn traut sich nur zu 2 Minuten aufzuholen. Weiß noch nicht, ob sich vielleicht andere Modelle haben im Ausland, dass sie sagen, der ist jetzt in der Schweiz zum Beispiel, der wird jetzt pünktlich sein, wäre ja eigentlich ganz gut. Oder, was ja auch denkbar ist, fragt halt den, in welchem Land du gerade, in welchem Netz du gerade rumfährst. Also frag doch die Niederlande, wie verspätet der sein soll. Ja, also da besteht ja auch so eine Kooperation mit so einem EZ, der wird ja auch teilweise medizinischem Personal gemacht. Also mehr Kooperation würde hier dem Kunden helfen. Weil im Idealfall ist es genauer, wenn du den fragst, der das täglich macht. Statt in Deutschland bedeutet das in der Regel, dass wir nur 2 Minuten schaffen, das heißt ja nicht, dass es in anderen Ländern so ist. Nun gut. Gucken wir uns mal was anderes an, weil der ist jetzt ja nicht durch Österreich gefahren, das wäre ein bisschen unfair. Nehmen wir doch mal einen Zug, man könnte jetzt ja annehmen, dann in Deutschland ist die DB besser mit den Informationen und in Österreich die ÖBB. Weil ist dann ja bei sich im Netz, das könnte man jetzt mal annehmen. Das war ungefähr um 14.10 Uhr abgefragt. Das ist wieder die DB, also nur ein Auszug, weil das war viel zu lang für alles. Auch hier wurde wieder hervorragend die Verspätung von vorher rausgelöscht. Die hat ja keinen zu interessieren. Damit könnte man ja noch Fahrgastrechte machen. Das geht ja gar nicht. Ja. Und okay, es gibt immerhin Informationen in Österreich und die Prognose geht auch eher ein Stück hoch. Das klingt jetzt erstmal alles realistisch, würde ich sagen. Und scheinbar ist irgendwas in Passau passiert, also wegen der 10 Minuten Stand. Aber würde ich hier nehmen. Also zumindest für die Zukunft sehen die Daten solide aus. Das hat die ÖBB. Warum habt ihr plus 0? Ich glaube nicht, dass man zwischen Passau und Linz 10 Minuten aufholen kann mal eben. Also das klingt zumindest sportlich. Also bin die Strecke schon gefahren. Da kann man schon was aufholen, wenn es gut läuft, aber 10 Minuten ist sportlich. Nun gut, ich weiß tatsächlich nicht, wie das ausgegangen ist. Ich würde hier eher der DB vertrauen, glaube ich. Außer bei den Plattformen, da habe ich es auch recht spannend. Da sieht man sehr gut, dass das einfach Freitext ist, der korrigiert wird. Weil in Deutschland hat man dieses Minus für A bis F vergessen. Wahrscheinlich war das zu aufwendig, an seinem Smartphone zu tippen, weil sie tippen das halt meistens an ihrem db communicator heißt da, glaube ich, das interne Ding ein. Und 8af war halt einfacher als 8ab bis F. Bei der ÖBB ging das hingegen. Und die Enthaltestelle wurde auch korrigiert, während das bei der db nicht. Es ist in dem Fall gar nicht so relevant, weil das einfach nur zur Wahl der Zuge länger, als wir gedacht haben, scheinbar. Deswegen hält er von A bis C statt von A bis B. Aber wenn ihr Verspätungen da habt und wenn ihr prinzipiell Plattformänderungen in Österreich habt, warum habt ihr das nicht? Also, wo hakt es wieder? Ist es tatsächlich so, dass alles manuell eingetragen wird und einfach kein Lust hatte oder es nicht für wichtig befand? Offen Fragen kann ich auch nicht beantworten. Sieht aber schon so aus, als wenn das alles manuell gemacht wird. Und warum wird das manuell gemacht? Da muss es doch was Besseres geben. Auch das eher offene Fragen hier. Gucken wir uns noch mal das da an. Die Gegenrichtung, die finde ich jetzt auch wieder sehr spannend, einfach weil jetzt hat die ÖBB-Verspätungen in Österreich und ansonsten auch das gleiche Verspätungsmodell in Deutschland. Die db hat diesmal auch verdaten in der Vergangenheit, aber nicht bis ganz zurück. Meine Verwaltung war okay, vielleicht löschen Sie das spätestens nach vier Stunden. Das habe ich tatsächlich geprüft. Auch im 1750 waren St. Pölten noch die Verspätung von 0 Minuten dran. Das, was ich bisher gesehen habe, hängt auch nicht damit zusammen, dass das plus null war und dass man das ja ruhig stehen lassen kann. Ansonsten löschen Sie nämlich auch, wenn es plus null war, sehr explizit. Daher haben wir einfach keine Ahnung, wie sowas zustande kommt. Und wie ein Meideling explizit gelöscht aus der Statistik, aus der Api, aber der Rest nicht. Also wenn jemand Ideen hat, können wir dann nachher mal darüber reden oder ich weiß auch nicht. Ich habe noch keinen Szenario gefunden, dass irgendwie sinnvoll wäre. Also was auch ein Workflow wäre, den man verstehen könnte und sagen, das ist effizient, das kann man mal machen in seinem täglichen Bahnbetrieb. Wobei effizient, da meistens keine Rolle spielt. Ja, und diese Plattformänderungen schon wieder. Die wurden nicht, also gerade wie ein Meideling, wäre echt interessant. Da guckt man mit seinem DB-Navigator, was ich zum Beispiel, wenn ich in Österreich fahre, eigentlich auch Tour, halt mit meinem Tool, aber das ist halt effektiv auch der DB-Navigator. Dann stehe ich jetzt an fünf und nicht an sechs, bis es halt am Bahnhof steht. Und ich glaube, die Österreicher können das weitaus besser. In Deutschland ist das ja immer so ein Problem, wenn du da stehst und das hoffst, dass es im Bahnhof schon richtig stehen wird. Das machen die ja gerne mal sehr spontan. So, Zug fährt ein, aber halt nicht an deinem Gleis, sondern an dem nochmal Treppe rauf, Treppe runter. Aber das wussten wir leider erst bei der Einfahrt. Das kennen wir hier alle, wenn man mal fährt. Also das finde ich auch tatsächlich echt einfach nur spannend. Und jetzt kommt noch was, so eine Besonderheit der API. Das ist, ja, ich habe absolut keine Ahnung, wie sowas zustande kommt, wie es sinnvoll ist. Und, naja, also wir gucken uns mal, Auszug aus der API von Trainsearch-Achse. Trainsearch-Achse ist halt genau das, ich sage ICE 91 und da gibt mir den ICE 91 an dem Datum, das ich ihm sage. In dem Fall gucken wir uns tatsächlich den, an dem wir gerade gesehen haben. Und da stand jetzt das hier. Jetzt gucken wir mal Dinge ab. Also zum Beispiel das hier. Also laut Bahn fährt der in Passau ab. Das stimmt nicht. Der fährt schon in Hamburg los. Und Passau, für die es nicht wissen, wie der letzte Deutsche Bahnhof bevor Österreich kommt. Mit anderen Worten, Sie haben angeblich fährt er halt nur Österreich ab. Das mag jetzt auch tatsächlich eine Einstellungs-Sache sein, weil es gibt einen Filter dafür. Man kann ihm sagen, gebe mir nur Züge, die auch in Deutschland fahren. Ansonsten kriegt man halt sehr oft Fahrten, die irgendwo nur am Osten fahren oder irgendwo in Frankreich rumfahren. Diese Trainsearch-Achse ist sehr europäisch. Im Vergleich zu allem anderen, das ist nicht so europäisch gedacht. Aber warum kriegt man so einen Teilzug? Und das Spannende ist jetzt, wenn man diesen Filter zum Beispiel rausnimmt und sagt, gib mir einfach alle Züge, dann bekommt man auch nicht alles. Also dann startet der zwei in Hamburg, dann endet der aber in Passau. Und es sind auch nicht zwei Züge, weil diese beiden Züge haben die gleiche ID. Also darunter steht so eine Journey ID. Die ist halt identisch dann. Also scheinbar gibt es diesen Zug und diese API halt nur entweder in Deutschland oder nur in Österreich. Und das ist der erste Grund, warum man mehrere APIs braucht, um eine Detailsite zu bauen. Weil jetzt wüsste ich ja nur, dass der in Passau startet. Und das Problem ist, ich habe ja schon erwähnt, es gibt zwei APIs, um Details zu einem Zug zu bekommen. Die eine nimmt diese Journey ID, die kann ich da einfach reinkippen. Das ist aber auch die, die die Vergangenheitsdaten nie hat. Das ist also die, die ich nicht nehmen möchte. Die andere braucht einen Context String und da muss Start und Ziel drin stehen. Aber den Start habe ich ja nicht bei der Bahn richtig, weil ich weiß ja schon, es kann sein, dass der Start falsch ist. In dieser API, die ich mit dieser Journey ID befeuere, steht dann aber richtig drin, dass der in Hamburg Altona startet. Also die wissen das ja. Wieso steht das da nicht drin? Und wieso ist das gesplittet? Also habe ich zumindest noch nicht gefunden. Wieso kriege ich keinen Filter mit? Ich habe den gesamten Zug und nicht nur den Teil. Das wäre echt hilfreich, Bahn. Oder Haferz. Wobei das ja scheinbar ein Bahn-Setup ist, weil die ÖBB kriegt das ja einwandfrei hin. Außer das mit diesem Namen, das kriegen die alle nicht gut hin. Also die ÖBB hat am Ende noch ein paar Leerstrings und die DB macht prinzipiell mehrere Leerzeichen, wenn sie Dinge trennen. Das ist halt so. Das ist halt, ja, das ist so ein Ding, das muss man halt wissen und das ist halt einfach so bei dieser API. Was ja aber auch scheinbar, also entweder ist das ein Datending, aber warum stehen die Daten so drin? Oder ist es ein Haferz-Problem? Und dann ist es eine Einstellungs-Sache. Also in jedem Fall ist das ein Problem, was die Bahn eingebaut hat. Oder die ÖBB halt auch. Also sie kriegen es ja alle nicht hin. Das ist sehr irritierend. Und wenn wir schon mal diesen Trains, da kann ich noch mal erzählen, ich habe gerade diese dritte API, die ich benutze, um Vergangenheitsdaten zu bekommen, die hat ein anderes Problem, weil die hat nicht immer Vergangenheitsdaten. Wenn sie keine Vergangenheitsdaten hat, hat sie einfach gar keine Verspätungen. Selbst wenn ich nur die ansprechen könnte, würde mir das nicht helfen, weil dann wüsste ich nicht, ob der Zug keine Verspätungsdaten hat, ob die in dieser API fehlen. Dann brauche ich trotzdem die andere, wo sie dann zumindest die in der Zukunft drin stehen. Das klingt alles echt nicht gut durchdacht und erklärt auch so ein bisschen, wenn man diesen DB-Navigator für sowas benutzt, warum da so oft Informationen drin stehen, die einem nicht wirklich helfen. Einfach, weil die kommen, die sind halt auch in den APIs so. Scheinbar geht das besser, weil bei der ÖBB habe ich diesen Problem nicht gesehen. Da steht in jeder API auch die Vergangenheit drin. Die löschen die halt scheinbar einfach nicht. Also warum betreibt die Bahn diesen Mehraufwand, diese Verspätungen zu verschleiern, wenn das eh nicht hilft, weil es gibt Seiten, die Verspätungsstatistik haben, die sind auch sehr gut. Ja, das ist eines meiner ungelösten Probleme, die finde ich echt gut, weil so drei APIs-Abfragen ist langsam und eigentlich will ich eine schnelle Seite haben. Nun gut. Das sind so Bahnhafas-Probleme. Wenn mich mir irgendwer von der Bahn mal erklären, wie dieses Zusammenspiel ist, finde ich das auch echt gut, weil das kann nicht, funktioniert scheinbar nicht richtig. Und historisch übrigens kein Fun-Fact. Inzwischen ist dieses Hafas und Hakon nicht mehr aus der DB wegzudenken. Also die Migration würde wahrscheinlich einfach viel zu teuer sein in irgendein anderes System. Und die werden ziemlich viel blechen für dieses Ding. Man hatte mal die Chance, diese Firma zu kaufen, dann hätte man das einfach selber gehabt. Man dachte sich aber, nee, das lohnt nicht. Das glaube ich jetzt, wenn man jetzt darauf guckt, eine echt doofe Entscheidung gewesen ist, die Firma nicht zu kaufen, das heißt nicht zwingt, dass das Ding besser wäre, wahrscheinlich nicht, wenn wir uns den Rest der APIs angucken, aber es wäre günstiger. Nun gut, das müssen wahrscheinlich irgendwelche Manager jetzt, die wahrscheinlich gar nicht mehr existieren, verantworten. Gut. Das war so, das was ich so habe. Habt ihr denn noch Fragen zu ein paar Dingen? Wie sieht denn die Qualität von Wagenreihungen und den ganzen Zugdetails dort aus? Also die Zugdetails, die auch aus dem Hafas kommen, die ich gesagt habe, mal so, mal so. Die Wagenreihung ist in der AP sehr gut. Das ist tatsächlich eine reine DB-Ding, weil die ist in dem Hafas, also in dem Navigator, ist sie tatsächlich so eingebaut, diese AP, die Routing macht, die kriegt da diese Extension mit und ab einer bestimmten Extension-Version schickt es einen String, also ein Array mit, indem eine Zahl drin steht und mit dem kann man dann die Wagenreihung, die man abfragen. Es ist sehr crude gebaut. Das ist dann eine komplett andere AP, eine komplett andere Datenlage, die ist in der Regel auch sehr gut. Ich kann übrigens schon mal einen Sneakpeak geben, es wird demnächst Themen, wie lange auch immer das dauern wird, es ist auf jeden Fall eine Planung, dass diese AP die Wahrheit ist. Mit anderen Worten, diese AP wird auch irgendwann mal den Bahnhof befeuern und dann steht am Bahnhof das, was in der AP steht. Das ist jetzt ja nicht so. Und da kann ich halt nur aus Erfahrung sagen, die Datenlage in dem Iris-Backend von der DB auch so ein Cluster-Fuck oder ist das da besser? Nee, es ist auch schrecklich. Die AP sind alle schrecklich, die Datenlage ist besser und man kann sich ein bisschen mehr auf Dinge verlassen. Aber die AP an sich ist auch schrecklich zu benutzen. Erst mal, danke für den Talk. Mich wird mal interessieren, mit welchen Abteilungen hast du denn schon alles geredet bei der Bahn? Ich habe mit sehr Mindbox relativ viel geredet, über die Mindbox, auch an Hackathons und ähnlichen. Station Service habe ich ganz gute Kontakte jetzt, die helfen mir auch häufig mal. Ansonsten mit dieser Sys-Tail, das ist sehr, sehr schleppend. Also die Kommunikation lief ab. Nach diesem GPN Talk kam auf Twitter eine Nachricht von jemandem. Er möchte unbedingt mal mit mir reden. Ich habe ihm dann gesagt, schlag doch mal Dinge vor und schreibe mir im Zweifel eine Mail. Dann kam Monate nichts. Dann kam irgendwann, wir wollen mal, irgendein ungepacketes Format mit dir machen. Dafür würden wir dich gerne nach Frankfurt holen. Ich habe dann so ein Datumsvorschlag, irgendwie anderthalb Monate in der Zukunft gemacht, als Antwort kam, oh, das wird knapp. Seitdem kam nichts. Der Vorschlag war Anfang August. Ja, kann ich nachvollziehen. Also, Disclaimer, ich bin auch bei der Bahn, jetzt nicht bei der Sisteln oder irgendjemandem, ganz woanders. Ich habe mit meinen Kollegen von der Reisenden Information geredet. Nein. Weil die nämlich genau sich mit so Themen beschäftigen, insbesondere mit Zusammenführung von verschiedensten Daten, Töpfen von diversen regionalen ÖPNV-Anbietern und so weiter. Und in dem Zusammenhang, ich weiß nicht, ob du das auch schon mal gehört hast, aber das soll wohl von der EU quasi eine Plattform, eine zentrale Plattform pro Land geben, wo alle Daten von ÖPNV oder sagen wir mal, alles, was einen Fahrplan hat, gesammelt wird und da entsprechend auch quasi offen der Allgemeinheit zur Verfügung gestellt werden soll. Die sollen sich ruhig mal melden. Ich kann denen wahrscheinlich ein bisschen Dinge erklären bei sich. Ansonsten, eine sehr gute Idee. Ich gehe davon aus, dass sie scheitern wird aus Gründendem. Also das Problem mit diesem wirklich alle Daten ist tatsächlich, in Neutern haben wir sehr, sehr viele Eisenbahnverkehrsunternehmen. Ich habe die Zahl vergessen, sie ist irgendwas Großdreistelliges. Und die müssten alle miteinander reden und sich alle einig sein. Das wird nicht passieren. Hindele ist noch. Von der Bahn gibt es aber keine Beschreibung zu sagen, du nutzt da unsere API oder du veröffnest da Interna, wir ändern das mal kurz, wie das mit der Verschlüsselung läuft oder mit dem Zugriff. Weil dem, wo du sagst, ja hier so funktioniert das und ich habe eine parallele Seite, kann ich mal vorstellen, dass sie Interesse haben, das zu unterbinden. Ich bin ein kritischer Infrastruktur. Ich stehe in mehreren Dingen drin, als hol dir doch hier die Informationen in internen Bahndingen. Ansonsten, ich habe tatsächlich auch aus Leuten, die in der Bahn mehr so Politikdinge tun, schon gesagt bekommen, wenn irgendwann mal Probleme entstehen, weil die Bahn sagt, nee, das kannst du aber nicht machen, dann soll ich mich mal melden. Also es gibt in der Bahn durchaus Leute, die sehr viel Interesse haben, das zu verbessern und die wissen auch, dass das alles echt doof ist gerade. Die wissen halt dadurch, dass die Interna kennt, auch das ist einfach schwierig ist und viel Bürokratie und Politik. Also vieles ist nicht, weil die Bahn technisch unfähig ist. Die Bahn hat auch fähige Informatiker und die könnten sowas technisch. Das Problem ist halt immer die Anforderungen, die sie kriegen und die Rahmenbedingungen, die sie dann erfüllen müssen. Das ist schwierig und das ist im Endeffekt Politik. Die Politik will halt nicht, dass das sinnvoll ist scheinbar. Fragen? Das sehe ich nicht, dann bedanke ich mich herzlich für den Vortrag.