Table des matières

Rechercher sur le site

Tools & More

#AutoTranslate

Description rapide

Qu’est-ce que Tools & More?

Cette page offre un aperçu des différents outils et systèmes, ainsi que des liens complémentaires qui peuvent aider les utilisateurs d’OpenTransportData.swiss.

Qui est impliqué?

Les outils, systèmes et liens présentés ici ont été créés par notre équipe Tâches systémiques Information clientèle + (SKI+), nos partenaires ou des externes.

Pourquoi offre-t-elle Open Data Platform utilise-t-il ces outils?

De nombreux outils permettent de mieux surveiller et exploiter les données et les interfaces sur OpenTransportData.swiss.

Description métier

Pour la gestion des Données d’horaire HRDF

Duplicata HRDF

  • Lien: https://tools.odpch.ch/hrdf-check-duplicates
  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/hrdf-duplicates-report
  • Usage prévu: Cet outil permet d’identifier les courses contradictoires dans les données HRDF et de vérifier s’il s’agit de doublons ou de valider les similitudes. Concrètement, le système recherche les entrées *Z de numéros de course qui appartiennent à la même entreprise de transport. Selon la définition HRDF, «…Numéro de trajet un numéro unique par livraison au sein d’une administration…» est disponible. En tant que fonctionnalité supplémentaire, l’outil tient également compte de la période de validité des courses définie dans le BITFELD.
  • Mode d’emploi:
    • Tout d’abord, l’enregistrement HRDF (cf. https://data.opentransportdata.swiss/dataset/timetable-54-2026-hrdf), c’est-à-dire le jour. Il faut ensuite sélectionner l’entreprise de transport car le caractère univoque vaut pour chaque entreprise.
      • Le système détermine alors pour l’entreprise de transport tous les numéros de course présents plusieurs fois, en tenant compte des périodes de validité effectives. Le résultat est ensuite regroupé par catégorie d’offre ou par type de moyen de transport. Dans cet exemple, il existe quatre numéros de course pour le type de moyen de transport «EC» (310, 320, 322, 328) qui sont des doublons. Le numéro de course 771 du type IC 3 semble en avoir 19 doublons.

      • Dans la vue détaillée des doublons, un utilisateur peut désormais examiner et contrôler les éventuels doublons de plus près. Un contrôle visuel des trois premières entrées met clairement en évidence les différences, de sorte que les variantes affichées ne sont pas de «véritables» doublons. Or, ce serait le cas selon le HRDF-RV (donc en théorie).
      • Remarque: l’outil propose une alternative en sélectionnant «Consolidated Report». Dans ce cadre, tous les doublons identifiés sont émis sous forme de tableau pour toutes les entreprises de transport, tous jours confondus.

Champs de bit HRDF

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/bitfeld-viz
  • Usage prévu: Représentation visuelle des périodes de validité telles qu’elles sont mises à disposition sous forme de code binaire dans le fichier BITFELD au format HRDF. Concrètement, elles sont mises à disposition sous forme de nombres hexadécimaux, qui représentent à leur tour l’ordre des bits.
  • Mode d’emploi:
    • Insérer d’abord la valeur du champ d’éléments binaires à visualiser, puis sélectionner la période d’horaire à utiliser.

    • Une visualisation des données indiquées s’affiche alors

    • Remarque: On peut aussi saisir de «vrais» champs de bits, c’est-à-dire une suite de zéros et de un (011000101…).

Requête HRDF

Pour la gestion des Données d’horaire et données en temps réel GTFS

GTFS-Static et GTFS-RT Comparer

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/gtfs-rt-status
  • Usage prévu: Cet outil permet de comparer les données GTFS statiques (Static) avec les données en temps réel (Realtime) afin d’identifier les éléments de données manquants dans les jeux de données respectifs. Les éléments de données sont les entreprises de transport et les trajets/Trips spécifiques.
  • Mode d’emploi:
    • Les fichiers GTFS-Static et GTFS-Realtime sont présélectionnés. Vous pouvez spécifier la période pour laquelle vous souhaitez vérifier les écarts. Appuyez sur le bouton «Compare» pour effectuer la comparaison.
    • Une fois la comparaison effectuée, les différences par rapport à l’enregistrement statique sont affichées à partir de l’enregistrement en temps réel. Concrètement, un petit aperçu avec le nombre d’écarts («Stats). Ensuite, les entreprises de transport sont disponibles pour les données en temps réel mais pas dans l’onglet correspondant (https://data.opentransportdata.swiss/dataset/go-realtime) («Agencies missing from GO-Realtime»). Les entreprises de transport figurant dans le registre, mais pour lesquelles aucune donnée en temps réel n’a été trouvée («Agencies without GTFS-RT»). Ainsi qu’une liste de blocs de données GTFS en temps réel pour lesquels aucun équivalent correspondant n’a été trouvé dans le bloc de données statiques («Missing GTFS static entries»).
    • Après l’aperçu pour GTFS-Realtime, voici un aperçu pour GTFS-Static. Tout d’abord, comme précédemment, le nombre d’écarts («Stats») avec «signe inversé». Puis la liste des données statiques pour lesquelles il manque les données en temps réel. Dans la colonne «Stops», les arrêts déjà desservis sont indiqués en gris clair; les arrêts à venir sont indiqués en noir.

GTFS-Static et GTFS-RT Comparer Report

  • Code: https://github.com/openTdataCH/OJP-Showcase/tree/develop/apps/gtfs-rt-static-report
  • Usage prévu: Il s’agit d’une représentation visuellement attrayante du rapport comparatif décrit ci-dessus. Elle peut par exemple être utilisée pour afficher les mouvements inhabituels dans les volumes de données. Et pour identifier des schémas récurrents ou inhabituels. Par rapport au «simple» comparateur, cette vue fournit une vue d’ensemble mensuelle des données qui y sont obtenues.
  • Mode d’emploi:
    • Tout en haut, vous pouvez sélectionner le mois à visualiser et les valeurs à comparer. Le résultat est ensuite affiché dans le tableau ci-dessous, où sont affichées les valeurs par jour et par heure pour le jour concerné. Sur l’image ci-dessous, le nombre de données en temps réel concernant les jours et les heures en septembre 2024. Les différentes nuances de bleu représentent différents blocs de données GTFS.

    • Selon la cellule sélectionnée, vous pouvez afficher les détails des données sur le côté droit. La balise «DATA» indique des problèmes de serveur ou de fichiers. MATCH signifie que trop d’enregistrements diffèrent. Tandis que «RT age» indique un enregistrement RT qui diffère trop temporairement. Les détails peuvent aussi être consultés ici: https://github.com/openTdataCH/OJP-Showcase/blob/develop/tools/gtfs-rt-static-compare/docs/gtfs-rt-static-compare.md

GTFS Shapes Checker

  • Code: À confirmer
  • Usage prévu: Permet de sauvegarder les fichiers GTFS de formes préalablement téléchargés (par ex. https://tools.odpch.ch/gtfs-shapes-analyse-v2/data/gtfs-db-lookups-2023-09-05-mentz.json) doivent être validés visuellement.
  • Mode d’emploi:
    • Soit vous recherchez un Trip souhaité dans le fichier Shapes, soit vous cliquez avec le bouton gauche de la souris sur la carte, à proximité des «graph shapes» représentées, qui sont visibles sur la carte sous forme de lignes bleues (exemple en jaune sur la capture d’écran). Tous les Trips à proximité s’affichent et vous pouvez cliquer sur un bouton bleu sur le côté droit (identifiant du Trip) pour en sélectionner un pour le mettre en évidence visuellement sur la carte. De plus, les détails sont représentés sous forme de texte en bas à droite.

Création de formes

  • Code: https://github.com/ad-freiburg/pfaedle
  • Finalité: Création de correspondances cartographiques pour les flux GTFS basés sur les données OSM
  • Marche à suivre: Les instructions figurant dans le dépôt de garantie doivent être suivies.

Pour la gestion des Données d’événement SIRI

Vue d’ensemble de SIRI SX

  • Avec ?debug=1  des informations détaillées sont fournies à la fin de l’URL. Il faut ensuite saisir un SBOID ou SSTID lors de la recherche textuelle (pas de recherche plein texte)!
  • Code: https://github.com/openTdataCH/siri-sx-situation-monitor
  • Usage prévu: Représente les informations sur les événements reçues au format SIRI-SX sous la forme d’une simple liste.
  • Mode d’emploi: Pas de configuration particulière (sauf si vous définissez?debug=1)

Carte SIRI SX

  • Code: https://github.com/openTdataCH/siri-sx-map?tab=readme-ov-file
  • Usage prévu: Représentation géoréférencée des messages SIRI-SX sur une carte.
  • Mode d’emploi:
    • Il s’agit d’une carte sur laquelle les événements sont représentés. Il suffit de cliquer sur les marquages ou les lignes de couleur pour afficher plus d’informations. Il est également possible de sélectionner la langue et d’autres paramètres de consultation et d’affichage.

Requête GTFS

  • Code: OJP-Showcase/apps/gtfs-query at develop · openTdataCH/OJP-Showcase (github.com)
  • Usage prévu: Ce système permet d’afficher les détails de l’horaire GTFS appropriés sur la base des données relatives aux événements de SIRI-SX.
  • Mode d’emploi:
    • Tout d’abord, l’outil doit Vue d’ensemble de SIRI SX (voir ci-dessus) avec l’ajout?debug=1 (à la fin de l’URL).
    • Il faut ensuite ouvrir la vue développeur avec la vue du protocole réseau du navigateur.
    • Ensuite, il faut cliquer sur le bouton «Build Link». Dans la demande envoyée, un lien commençant par ce qui suit figure dans les informations d’en-tête https://tools.odpch.ch/gtfs-rt-status/api/gtfs-query/trips? (Exemple en jaune dans la capture d’écran ci-dessous):

    • L’affichage suivant s’affiche dans le navigateur. Les détails de l’horaire pour la partie concernée par l’événement s’affichent dans GTFS. Dans le cas présenté, il s’agit de la ligne 22, qui est concernée dans GTFS pour la date indiquée avec 59 entrées.

Pour la gestion du Open Journey Planner

Appli de démonstration OJP

  • OJP 1,0: https://opentdatach.github.io/ojp-demo-app/search
  • OJP 1,0 BÊTA: https://tools.odpch.ch/beta-ojp-demo/search
  • OJP 2,0: https://tools.odpch.ch/ojp-demo-v2/search
  • Usage prévu: un outil pour tester l’interface OJP et ses fonctionnalités. L’appli sert avant tout à démontrer les capacités du système et n’a pas été conçue comme une appli à part entière! Elle permet d’effectuer les requêtes classiques au système OJP dans le standard OJP. Cela est possible à différents points d’extrémité (p. ex. test ou intégration), respectivement pour les versions standard OJP 1 et 2. Toutes les fonctionnalités prévues peuvent être testées avec la version bêta, qui est en revanche plus souvent instable.
  • Mode d’emploi:
    • Recherche d’itinéraire
      • L’onglet «Journey Search» est sélectionné par défaut et il est possible d’effectuer une recherche d’itinéraire classique en saisissant le lieu de départ et la destination dans les champs «De» et «À». En outre, il est possible de sélectionner la (multi)modalité souhaitée pour la forme de transport, p. ex. «Mode at End» ou «Bicycle Sharing», c’est-à-dire parcourir le dernier kilomètre avec un vélo. Comme décrit précédemment, cette possibilité de configuration sert à la démonstration – un programme utilisateur final procéderait probablement différemment. Par ailleurs, il est possible de régler le jour et l’heure (départ ou arrivée). Concernant les environnements, il convient de laisser PROD (système et serveur de production). LA Beta signifie Linking-Alps Beta et permet des requêtes dans le cadre du Communautés LinkingAlps à tester (liaisons internationales vers le Tyrol du Sud/l’Autriche/la Slovénie). Le bouton «Debug XML» permet de visualiser la demande XML.

      • Une fois la recherche effectuée, d’autres fonctionnalités sont disponibles. Le bouton «XML» de la section de recherche permet d’afficher le XML de la demande et de la requête. En outre, les trajets possibles (Trips) sont désormais affichés, avec diverses méta-informations comme la durée du voyage. Le bouton «MAP» concentre la vue sur la carte sur le segment de trajet correspondant (Trip-Leg). Le clic sur la modalité a le même effet (p. ex. «1er train – …»). Un clic sur le nom de la ligne et le numéro de train (p. ex. «IC6 960») permet d’obtenir un aperçu de tous les arrêts du moyen de transport. Citons notamment le bouton «Permalien» qui permet d’enregistrer une requête prédéfinie dans un lien et de la partager ensuite (p. ex. pour corriger des erreurs). Le résultat comprend également des informations sur les retards, les caractéristiques du moyen de transport, l’accessibilité et des informations approximatives sur les prix.

      • La carte de résultat se comporte comme d’habitude ailleurs.
    • Station Board
      • En sélectionnant l’onglet «Station Board», il est possible d’afficher l’écran des départs/arrivées pour un arrêt spécifique. P. ex. «Bern, Wankdorf Center». Toutes les autres fonctionnalités fonctionnent de la même manière que «Recherche d’itinéraire».

      • Après la recherche, le résultat s’affiche avec les lignes concernées, le numéro de train/moyen de transport et les heures de départ ou d’arrivée prévues ainsi que les éventuels retards.

    • Informations sur le voyage
      • L’onglet «Trip Info» permet de consulter la vue détaillée d’un train spécifique. Comme décrit ci-dessus, il est également possible de les consulter en cliquant sur le numéro de ligne et de train spécifique (p. ex. IC1 709) dans le Journey Search. C’est également le moyen d’obtenir une «JourneyRef», c’est-à-dire un Swiss Journey ID (SJYID – ID suisse du trajet), par exemple «ch:1:sjyid:100001:709-001» (en savoir plus sur les ID suisses https://www.oev-info.ch/de/branchenstandard/technische-standards/strukturelle-standards). Saisir ensuite ce SJYID dans le masque.

      • Le résultat indique les différents arrêts du parcours.

Explorateur de l’API

  • Code: https://github.com/openTdataCH/api-explorer2
  • Usage prévu: L’API Explorer permet d’émettre des requêtes OJP 1,0 et 2,0 au format XML sur notre back-end. Sur le plan fonctionnel, elle est donc similaire à l’application de démonstration OJP, mais se limite aux types de requêtes pour OJP et à une vue «purement textuelle» avec des questions et réponses XML. Une authentification appropriée est requise (cf. Howto: Accès à nos API avec des clés API).
  • Mode d’emploi:
    • Une interface standard Swagger fournit les points de terminaison qui peuvent être demandés, y compris des exemples de requêtes.

Pour l’utilisation des données en temps réel pour les tests

Sur GitHub, les requêtes et réponses OJP sont mises à disposition, en partie avec des données SIRI et GTFS enregistrées au cours de l’exploitation. Celles-ci peuvent être utilisées comme données de simulation pour leurs propres tests et montrent à titre d’exemple comment les données en temps réel sont communiquées via différents canaux, ce qui peut varier en fonction du moyen de transport ou de l’exploitant.

Comme autre possibilité de tester ses propres applications avec des adaptations dans le domaine du temps réel, des cas concrets sont régulièrement introduits dans OJP 2,0 INT. Des requêtes avec conditions de test concernant ces adaptations sont disponibles sur GitHub en tant que collection Postman et Bruno. Ces cas d’usage en temps réel peuvent être utilisés à des fins de test. Pour cela, une clé API est toutefois nécessaire pour l’accès INT à OJP 2,0 avec justification à opendata@sbb.ch demande.

De plus amples informations figurent dans le Prise en charge sur GitHub à trouver.

Appli de démonstration OJP

Et plus

Le site Web suivant contient une liste d’outils utiles, notamment pour la gestion des données GTFS: https://github.com/MobilityData/awesome-transit