Inhaltsverzeichnis

Auf der Seite suchen

Tools & More

Kurzbeschreibung

Was ist Tools & More?

Diese Seite bietet eine Übersicht über die verschiedenen Werkzeuge, Systeme, und weiterführenden Links, die NutzerInnen von OpenTransportData.swiss helfen können.

Wer steckt dahinter?

Die hier vorgestellten Werkzeuge, Systeme, und Links wurden entweder durch unser Team Systemaufgaben Kundeninformation + (SKI+), unsere PartnerInnen, oder Externe entwickelt.

Warum bietet die Open-Data-Plattform das an?

Viele der Werkzeuge helfen dabei, die Daten und Schnittstellen auf OpenTransportData.swiss besser zu beobachten und zu nutzen.

Fachliche Beschreibung

Für den Umgang mit HRDF-Fahrplandaten

HRDF Duplicates

  • Link: https://tools.odpch.ch/hrdf-check-duplicates
  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/hrdf-duplicates-report
  • Verwendungszweck: Dieses Werkzeug erlaubt es, widersprüchliche Fahrten in den HRDF Daten zu identifizieren und zu prüfen, ob es sich um Duplikate handelt, bzw. die Ähnlichkeiten zu validieren. Konkret sucht das System nach *Z Fahrtnummer-Einträgen die zum selben Transportunternehmen gehören. Laut HRDF-Definition gilt, dass die “…Fahrtnummer eine – pro Lieferung – eindeutige Nummer innerhalb einer Verwaltung…” ist. Als zusätzliche Funktionalität berücksichtigt das Werkzeug auch die im BITFELD definierten Gültigkeitszeiträume der Fahrten.
  • Anleitung:
    • Zunächst muss der HRDF-Datensatz (s. https://data.opentransportdata.swiss/dataset/timetable-54-2024-hrdf) ausgewählt werden, also der Tag. Dann muss das Transportunternehmen gewählt werden, denn die Eindeutigkeit gilt pro Transportunternehmen.
      • Das System ermittelt dann für das Transportunternehmen alle Fahrtnummern die mehrfach vorkommen, unter Berücksichtigung ihrer effektiven Gültigkeitszeiträume. Das Ergebnis wird nach Angebotskategorie bzw. Verkehrsmitteltyp gruppiert ausgegeben. Im Beispiel gibt es für den Verkehrsmitteltyp “EC” 4 Fahrtnummern (310, 320, 322, 328) die jeweils Duplikate sind. Die Fahrtnummer 771 des Typs IC 3 scheint dabei 19 Duplikate zu haben.

      • In der Detailansicht für die Duplikate kann eine NutzerIn nun die möglichen Duplikate genauer anschauen und prüfen. Eine visuelle Inspektion der ersten drei Einträge zeigt die Unterschiede klar auf, somit sind die angezeigten Varianten keine “echten” Duplikate. Nach der HRDF-RV (also in der Theorie) wären sie es jedoch.
      • Hinweis: das Werkzeug bietet eine alternative Darstellung an über die Auswahl “Consolidated Report”. Wo alle identifizierten Duplikate, über alle Transportunternehmen, und alle Tage hinweg als Tabelle ausgegeben werden.

HRDF Bitfields

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/bitfeld-viz
  • Verwendungszweck: Visuelle Darstellung der Gültigkeitszeiträume wie sie als Bit-Code in der BITFELD-Datei im HRDF-Format bereitgestellt werden. Konkret werden sie als Hexadezimal-Zahlen bereitgestellt, die wiederum die Bit-Reihenfolge repräsentieren.
  • Anleitung:
    • Zunächst fügt man den zu visualisierenden Bitfeld-Wert ein. Dann wählt man die anzuwendende Fahrplanperiode aus.

    • Danach sieht man eine Visualisierung der angegebenen Daten

    • Hinweis: Man kann auch “echte” Bitfelder eingeben, also eine Folge von Nullen und Einsen (011000101…).

HRDF Query

Für den Umgang mit GTFS-Fahrplan- und -Echtzeit-Daten

GTFS-Static & GTFS-RT Comparer

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/gtfs-rt-status
  • Verwendungszweck: Dieses Werkzeug erlaubt es, die statischen GTFS-Daten (Static) mit den Echtzeit-Daten (Realtime) zu vergleichen, um fehlende Datenelemente in den jeweiligen Datensätzen zu identifizieren. Datenelemente sind dabei Transportunternehmen, sowie spezifische Fahrten/Trips.
  • Anleitung:
    • Die GTFS-Static und GTFS-Realtime Dateien sind vorausgewählt. Man kann den Zeitraum, der auf Abweichungen geprüft werden soll, angeben. Mit dem Drücken auf den “Compare”-Knopf wird der Vergleich durchgeführt.
    • Nachdem der Vergleich durchgeführt wurde, werden zunächst die Unterschiede zum Static-Datensatz ausgehend vom Realtime-Datensatz angezeigt. Konkret, eine kleine Übersicht mit der Anzahl Abweichungen (“Stats). Dann die Transportunternehmen für die Echtzeitdaten vorliegen, die aber nicht im entsprechenden Register (https://data.opentransportdata.swiss/dataset/go-realtime) vermerkt sind (“Agencies missing from GO-Realtime”). Die Transportunternehmen die im Register vermerkt sind, aber für die keine Echtzeitdaten gefunden wurden (“Agencies without GTFS-RT”). Sowie eine Liste von GTFS-Realtime-Datensätzen, für die kein passendes Pendant im Static-Datensatz gefunden wurde (“Missing GTFS static entries”).
    • Nach der Übersicht für GTFS-Realtime, folgt eine Übersicht für GTFS-Static. Zunächst, wie zuvor, die Anzahl Abweichungen (“Stats”) mit “umgekehrten Vorzeichen”. Dann die Liste der statischen Daten, für die Echtzeitdaten fehlen. In der Spalte “Stops”sind die Haltestellen, die schon angefahren wurden, in hellgrau geschrieben; die zukünftigen Halte in schwarz.

GTFS-Static & GTFS-RT Comparer Report

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/gtfs-rt-static-report
  • Verwendungszweck: Dies ist eine visuell ansprechende Repräsentation des Vergleichsreport der oben beschrieben wurde. Sie kann bspw. genutzt werden, um ungewöhnliche Bewegungen in den Datenmengen anzuzeigen. Sowie wiederkehrende oder ungewöhnliche Muster zu erkennen. Im Vergleich zum “reinen” Comparer, dient diese Ansicht der monatlichen Übersicht der dort ermittelten Daten.
  • Anleitung:
    • Zuoberst kann man den zu visualisierenden Monat und die im Vergleich anzuzeigenden Werte auswählen. Das Ergebnis wird dann in der darunterliegenden Tabelle angezeigt, wo die Werte pro Tag und Uhrzeit am jeweiligen Tag angezeigt werden. Im Bild hier, die Anzahl der Echtzeit-Daten zu den Tagen und Uhrzeiten im September 2024. Die verschiedenen Blautöne repräsentieren verschiedene GTFS-Datensätze.

    • Je nach gewählter Zelle kann man auf der rechten Seite die Details der Daten anzeigen. Der “DATA”-Tag zeigt entweder auf Server-Probleme, oder Dateiprobleme. MATCH bedeutet, dass zu viele Datensätze abweichen. Während “RT age” auf einen RT Datensatz hinweist der zu stark temporär abweicht. Details können auch hier gelesen werden: https://github.com/openTdataCH/OJP-Showcase/blob/develop/tools/gtfs-rt-static-compare/docs/gtfs-rt-static-compare.md

GTFS Shapes Checker

  • Code: TBC
  • Verwendungszweck: Erlaubt es, zuvor (durch uns) hochgeladene GTFS-Shapes-Dateien (bspw https://tools.odpch.ch/gtfs-shapes-analyse-v2/data/gtfs-db-lookups-2023-09-05-mentz.json) visuell zu validieren.
  • Anleitung:
    • Entweder sucht man in der Shapes-Datei nach einem gewünschten Trip, oder klickt mit der linken Maustaste auf die Karte – in der Nähe der dargestellten “graph shapes”, welche als blaue Linien auf der Karte sichtbar sind (Beispiel im Screenshot gelb markiert). Daraufhin werden alle in der Nähe liegenden Trips angezeigt und man kann per Klick auf einen blauen Knopf auf der rechten Seite (beschriftet mit der Trip-ID) einen auswählen, um ihn auf der Karte visuell hervorzuheben. Zudem werden Details unten rechts textuell dargestellt.

Erstellen von Shapes

Für den Umgang mit SIRI Ereignisdaten

SIRI SX Overview

  • Mit ?debug=1  am Schluss der URL gibt es mehr Details. Bei der Textsuche muss dann eine SBOID oder SSTID eingegeben werden (keine Volltextsuche)!
  • Code: https://github.com/openTdataCH/siri-sx-situation-monitor
  • Verwendungszweck: Stellt die im SIRI-SX-Format eingehenden Ereignisinformationen als einfache Auflistung dar.
  • Anleitung: Es gibt keine besondere Konfiguration (ausser man setzt ?debug=1)

SIRI SX Map

  • Code: https://github.com/openTdataCH/siri-sx-map?tab=readme-ov-file
  • Verwendungszweck: Georeferenzierte Darstellung der SIRI-SX-Meldungen auf einer Karte.
  • Anleitung:
    • Es ist eine Karte auf der die Ereignisse dargestellt sind. Wenn man auf die farbigen Marker oder Linien klickt, erhält man mehr Details dazu. Zudem kann man die Sprache und einige weitere Parameter für die Abfrage und Darstellung auswählen.

GTFS Query 

  • Code: OJP-Showcase/apps/gtfs-query at develop · openTdataCH/OJP-Showcase (github.com)
  • Verwendungszweck: Dieses System erlaubt es auf Basis von gegebenen Ereignisdaten von SIRI-SX die passenden GTFS-Fahrplandetails anzuzeigen.
  • Anleitung:
    • Zunächst muss das Tool SIRI SX Overview (siehe oben) mit dem Zusatz ?debug=1 (am Schluss der URL) geöffnet werden. Dann muss die Entwickleransicht mit der Netzwerkprotokoll Ansicht des Browser geöffnet werden. Danach muss man auf den “Build Link” Knopf klicken. In der dann gestellten Anfrage findet man in den Header-Informationen einen Link beginnend mit https://tools.odpch.ch/gtfs-rt-status/api/gtfs-query/trips? (Beispiel im unten stehenden Screenshot gelb markiert):

    • Wenn man diesen Link im Browser aufruft, erhält man die folgende Ansicht. Dort sieht man die Fahrplandetails für den vom Ereignis betroffenen Teil in GTFS. Im dargestellten Fall die Linie 22, welche im GTFS für das gegebene Datum mit 59 Einträgen betroffen ist.

Für den Umgang mit dem Open Journey Planner

OJP Demo App

  • OJP-1.0: https://opentdatach.github.io/ojp-demo-app/search
  • OJP-1.0 BETA: https://tools.odpch.ch/beta-ojp-demo/search
  • OJP-2.0: https://tools.odpch.ch/ojp-demo-v2/search
  • Verwendungszweck: Ein Werkzeug, um die OJP-Schnittstelle und deren Funktionalitäten zu testen. Die App dient vor allem zur Demonstration der Systemfähigkeiten und ist nicht als vollwertige App gedacht! Die App erlaubt es, die typischen Anfragen an das OJP-System im OJP-Standard zu stellen. Dies ist an verschiedene Endpunkte (bspw. Test, oder Integration) möglich, jeweils für die OJP-Standard-Versionen 1 und 2. Alle geplanten Funktionalitäten können bei der BETA-Version ausprobiert werden, sie ist dafür häufiger instabil.
  • Anleitung:
    • Journey Search
      • Per Default ist der “Journey Search” Tab ausgewählt, und man kann eine klassische Routen-Suche durchführen, indem man im “From” und “To” Start und Ziel einer gewünschten Reise angibt. Ausserdem kann man die gewünschte (Multi-)Modalität der Transportform wählen, bspw. “Mode at End” und “Bicycle Sharing”, d.h. die letzte Meile mit einem Fahrrad zurückzulegen. Diese Konfigurierbarkeit dient, wie zuvor beschrieben, der Demonstration – ein Endnutzer-Programm würde dies vermutlich anders handhaben. Weiterhin kann man den Tag und die Zeit (Abfahrt oder Ankunft) einstellen. Bei den Umgebungen sollte PROD (Produktionssystem & -Server) belassen werden. LA Beta steht für Linking-Alps Beta und erlaubt es Abfragen im Rahmen des LinkingAlps-Verbunds zu testen (internationale Verbindungen Richtung Südtirol/Österreich/Slowenien). Mit dem “Debug XML”-Knopf kann man sich die XML-Anfrage anschauen.

      • Nachdem die Suche durchgeführt wurde, stehen einem weitere Funktionalitäten zur Verfügung. Mit dem “XML”-Knopf im Such-Abschnitt kann man sich die An- und Abfrage-XML anzeigen lassen. Zudem werden nun die möglichen Fahrten (Trips) angezeigt, mit diversen Meta-Informationen, wie bspw. die Reisedauer. Der “MAP” Knopf fokussiert die Sicht auf der Karte auf das entsprechende Fahrt-Segment (Trip-Leg). Den gleichen Effekt hat das Klicken auf die Modalität (bspw. “1. Zug – …”). Durch das anklicken des Liniennamens und Zugnummer (bspw. “IC6 960”) erhält man eine Übersicht über die Haltestellen des Verkehrsmittels insgesamt. Erwähnenswert ist der “Permalink”-Knopf, der es erlaubt, eine vordefinierte Abfrage in einem Link zu speichern, um diesen dann später zu teilen (bspw. für Fehlerbehebungen). Das Ergebnis enthält zudem Informationen zu Verspätungen, Eigenschaften des Verkehrsmittels, zur Barrierefreiheit, sowie eine grobe Preisauskunft.

      • Die Ergebniskarte verhält sich wie andernorts üblich.
    • Station Board
      • Mit Auswahl des “Station Board”-Tabs kann man sich den Abfahrts-/Ankunftsmonitor für eine spezifische Haltestelle anzeigen lassen. Bspw. “Bern, Wankdorf Center”. Alle weiteren Funktionalitäten verhalten sich wie beim “Journey Search”.

      • Nach der Suche wird das Ergebnis mit den einzelnen Linien, ihren Zug-/Verkehrsmittelnummern und erwarteten Ankunfts- bzw. Abfahrtszeiten, sowie möglichen Verspätungen angezeigt.

    • Trip Info
      • Der “Trip Info”-Tab erlaubt es die Detailansicht für einen spezifischen Zug aufzurufen. Diese kann man, wie oben beschrieben, ebenfalls sehen wenn man auf die spezifische Linien- und Zugnummer (bspw. IC1 709) bei der Journey Search klickt. Das ist auch der Weg, um eine “JourneyRef”, also einen Swiss Journey ID (SJYID – Schweizer Fahrt-ID) zu erhalten, bspw. “ch:1:sjyid:100001:709-001” (mehr zu den Schweizer IDs https://www.oev-info.ch/de/branchenstandard/technische-standards/strukturelle-standards). Diese SJYID gibt man dann in die Maske ein.

      • Das Ergebnis zeigt die verschiedenen Halte der Fahrt an.

API Explorer

  • Code: https://github.com/openTdataCH/api-explorer2
  • Verwendungszweck: Der API Explorer erlaubt es, OJP 1.0 und 2.0 Anfragen im XML-Format an unser Backend zu stellen. Es ist somit funktional der OJP-Demo-App ähnlich, beschränkt sich aber auf die Anfragetypen für OJP und eine “rein textuelle” Sicht mit XML-Fragen und -Antworten. Die passende Authentifizierung ist vorausgesetzt (s. auch https://opentransportdata.swiss/cookbook/verwendung-der-api/).
  • Anleitung:
    • Ein Standard Swagger-Interface stellt die Endpunkte bereit die angefragt werden können, inklusive Beispiel-Anfragen.

& More

Die folgende Webseite beinhaltet eine Liste von hilfreichen Werkzeugen, insbesondere für den Umgang mit GTFS-Daten: https://github.com/MobilityData/awesome-transit