Ist vielleicht für den ein oder anderen hier interessant: http://data.deutschebahn.com/blog/2016/02/25/fahrplan/
Habs schon gesehen, tolle Sache!
Zwar nur Fernverkehr, aber da lässt sich sicher trotzdem viel Nützliches draus machen.
Sehr gute Neuigkeit! Was man damit alles tolles basteln könnte. 
Ist wohl auch nur ne frühe Testversion. Da soll noch viel mehr kommen.
Wie wärs erstmal mit einem eigenen Offline-Fahrplanauskuntssystem?
Das könnte man dann in die OSM-Karte integrieren – als Erweiterung der Routing-Funktion.
Dazu müsste man aber erst einmal den gesamten DB-Fahrplan über die API auslesen. Das ist eigentlich kein Problem, aber in welches Offline-Format presst man die Daten dann? Gibt es ein bereits definiertes freies Format? Oder sollte man sich selbst eines überlegen
Ich denke diese Pläne ließen sich auch verwenden um unsere eigenen Daten zu komplettieren und zu korrigieren. Wenn ich das richtig sehe, kann man damit komplette Zugläufe mit bahnsteiggenauen Haltepositionen generieren. Das sollte reichen um damit Routenrelation zu bauen was momentan sehr aufwändig ist und meist nur unvollständig und fehlerhaft gemacht wird.
Wenn die Routen korrekt sind, müsste man nur noch an jeden Bahnhof/Haltepunkt die ensprechnende Abfahrts und Ankunftsplan “anheften”, und schon hätte man alle Informationen die man für ein vollständiges Routing benötigt. Ob man die Daten dazu übernehmen soll oder nur den Key für die Api-Abfrage an die OSM-Bahnhöfe klebt müsste noch im Vorfeld entschieden werden.
Es gibt das GTFS-Format für sowas - Und es hat auch schon jemand was gebaut um aus der Schnittstelle GTFS zu erzeugen: https://github.com/patrickbr/db-api-to-gtfs
Mit gefällt zwar das JSON oder XML von der Bahn besser, aber offensichtlich ist das GTFS-Format ein offener, gut spezifizierter, weit verbreiteter Standard, was schon einige Vorteile bieten dürfte.
Danke! Ausgezeichnet!
So wie es ausschaut, kann man den freien kompletten DB-FV-Fahrplan z.B. hier runterladen:
http://patrickbrosi.de/de/projects/dbgtfs/
Darauf ein Auskunftssystem aufzusetzen, ist wahrscheinlich gar nicht mehr so schwierig.
Wir haben sogar schon eine Wikiseite bei OSM zum Thema GTRS https://wiki.openstreetmap.org/wiki/General_Transit_Feed_Specification. Offenbar ist die Idee des zusammenführens von OSM und GTRS-Daten keineswegs neu.
Mit GO-Sync gibt es offenbar bereits ein freies Tool mit dem man aus GTRS-Daten OSM-Relationen und Stop_positions generieren kann. Offenbar ist das aber nur für Buslinien gedacht und daher in diesem Fall nutzlos, hab ich aber noch nicht getestet.
Vollständig kann dieser nach GTFS konvertierte Datensatz aber nicht sein, ich seh’ da einfach keine Daten zu den Verkehrstagen.
Mir war bei den Berlin-Brandenburg-Daten ( die es im GTFS-Format, bis runter zu Bussen und Strassenbahnen, hier gibt: http://daten.berlin.de/datensaetze/vbb-fahrplandaten-februar-bis-dezember-2016 ) auch schon aufgefallen, dass GTFS ziemlich viele Freiheiten im Modell hat, und man nicht von “der” GTFS-Version sprechen kann, und bei den VBB-Daten war auch irgendwas de-normalisiert, wenn auch nicht diese radikale Gleichsetzung zwischen “route” und “trip” wie in dem o.g. Datensatz.
Aber mich beschäftigt ein ganz anderes Problem: wie schafft man den Anschluss von einem Transit-Fahrplan (mit “stop_positions” ) und dem Wegenetz in OSM?
Für den Frankfurter Hauptbahnhof ist die stop_position (“Frankfurt(Main)Hbf”) irgendwo auf dem Querbahnsteig. Die OSM-“station” (“Frankfurt (Main) Hauptbahnhof”, wäre auch zu einfach, wenn der Name Schlüsseleigenschaft hätte…) liegt ein Stück weiter vorne auf dem Gleisfeld.
Ich hab’ mir für einen Prototyp mal mühsam zu jeder stop_position einen “catch-position” von Hand erfasst, von der ich dann über eine nearest-distance-Regel gegen das OSM-Wegenetz matchen konnte.
Was sagen die ÖPNV Mapper dazu? Gibt’s dafür eine Lösung? Also vom GTFS-Name der Station auf den OSM-Namen, und von da an die Anschlusspunkte zum Wegenetz?
Also bei dem Datensatz gab es mehrere Dinge die Entwicklern nicht gefallen haben. Er war einfach nicht komprimiert. Das heißt es wurden keine Taktfahrten verwendet.
Ebenfalls sehr merkwürdig waren die Gültigkeiten gepflegt. Anstatt das man Wochentage angegeben hat wurde jeder Tag einzeln gepflegt.
Wenn man allerdings weiß woher die Daten kommen und wie sie dortgespeichert werden, ist das auch kein Wunder.
Eigentlich sinnvoll wäre doch für jedes Gleis eine Stopposition zu haben und dann im Datensatz die Gleisangaben zu verwenden. Bei dem Datensatz des VBB sollen ja früher oder später auch mastscharfe Daten geliefert werden.Das ist insbesondere sinnvoll wenn man wissen möchte auf welcher Straßenseite die Haltestelle liegt. Ist das jetzt vor oder nach der Kreuzung usw.
In Frankfurt am Main und noch wichtiger in Leipzig oder Berlin ist halt aber auch welches Gleis ist hier das benutzte. Denn nur so lassen sich nachher die Umstiegszeiten genauer berücksichtigen. Derzeit ist es aus Performancegründen bei Hafas vor allem pauschal geregelt.
Verstehe ich das richtig, dass du mit den GTFS Datensatz pro stop nur einen Stationsnamen bzw. eine einzelnes Koordinaten-Paar bekommst? Für genaues Routing ist das zu wenig, dazu bräuchtest du so etwas wie eine Bahnsteignummer. Die könnte man zuordnen. Was du gefunden hast ist offenbar der zugehörige OSM-Bahnhofsknoten mit public_transport=station richtig? der ist für das Routing leider auch recht irrelevant. Eventuell ist dieser Mitglied einer Relation mit type=stop_area über die du an die einzelnen Bahnsteige kommst. Es ist allerdings nicht garantiert, dass diese auch existiert und ohne den richtigen Bahnsteig zu kennen ist das vermutlich auch wenig hilfreich.
Gibt es vielleicht stattdessen etwas, was man einer Fahrtvariante/Routenrelation zuordnen könnte? Ich verstehe noch nicht so ganz was die Daten genau beinhalten.
Die Halteposition wird i.d.R. in die Fahrzeugmitte gesetzt. Bei verschieden langen Zügen in die Mitte des kürzesten regelmäßig eingesetzten Zuges (bei S-Bahnen i.d.R. der ortsübliche Kurzzug).
Würde man dieser Regel folgen, müsste man die Halteposition in Frankfurt (Main) Hbf auf einigen Gleisen recht nahe an den Prellbock schieben, da dort z.T. regelmäßig Itino-Doppel- und -Dreifachtraktionen halten (ein Itiono-Triebwagen ist 39,47 m lang). Zum Vergleich ein ICE 3 (nur ein Triebwagen) ist 200,84 m lang, sechs Doppelstockwagen mit E-Lok sind ca. 179 m lang.
Es gibt mehrere Systeme für Haltestellen-IDs:
Ril100-Kürzel (aka DS100-Kürzel) der DB gibt es für alle Bahnhöfe und Haltepunkte, auch wenn die Infrastruktur an eine nicht-bundeseigene Bahn verpachtet oder verkauft wurde. Auch Stationen, die noch nie der DB/DR gehört haben (z.B. Albtalbahn) haben diese Kürzel. Diese Kürzel sind bei der Bahn recht gebräuchlich und AFAIK die einzige ID, die über mehrere Konzerntöchter hinweg nutzbar ist. Stationen, die aus mehreren Betriebsstellen bestehen (z.B. diverse Berliner Bahnhöfe, Köln Messe/Deutz, Söllingen, …) haben mehrere Kürzel. Tag: railway:ref=*.
Die EVA-Nummer ist die Nummer der HAFAS-Systeme und wird in OSM als uic_ref=* erfasst.
Die IBNR-Nummer ist deutlich firmen-unabhängiger, aber anders als EVA und Ril100 nicht deutschlandweit verfügbar. In Baden-Württemberg gibt es AFAIK eine freie Liste dazu, im VRR AFAIK auch. Tag weiß ich gerade nicht auswendig.
Ansonsten bleibt noch die Möglichkeit über den Namen zu suchen.
Gleisnummern werden an Bahnsteigen als ref=* (Vorsicht, meist mit Semikolon!) erfasst, an Haltepositionen teils als ref=, teils als local_ref= erfasst.