GTFS Realtime (GTFS-RT)

Description rapide

GTFS Realtime (GTFS-RT) est une extension du GTFS Static qui complète les informations statiques sur le transit par des informations en temps réel. Les données GTFS Realtime sont alignées sur les données GTFS Static. Le flux en temps réel comprend toutes les modifications connues dans les TP suisses pendant toute la fenêtre d’aperçu (trois heures) pour toutes les entreprises de transport qui fournissent des données en temps réel.

Description métier

GTFS-RT permet d’enrichir les informations statiques de transit avec trois types différents d’informations supplémentaires. Ces trois enrichissements sont généralement mis à disposition individuellement via HTTP et régulièrement mis à jour, ce qui permet aux développeurs de choisir avec quelles données en temps réel ils souhaitent enrichir leurs applications.

Les trois types d’informations complémentaires sont les suivants:

• Trip Updates (principales descriptions ici)
• Service Alerts (GTFS-SA)
• Vehicle Positions (non publiés sur la plateforme open data pour la mobilité en Suisse)

Le profil GTFS suisse, qui décrit en détail les propriétés reprises de la norme ou s’écartant de la norme, est disponible ici: https://www.oev-info.ch/datenmanagement/ski/standards-der-ski (Le lien mène à la page d’aperçu, car le document (General Transit Feed Specification (GTFS) PROFILE SWITZERLAND) est encore souvent adapté).

Remarques importantes: aucune mise à jour n’est effectuée les jours fériés (p. ex. lundi de Pâques, lundi de Pentecôte, etc.).

Trip Updates

Exemple: «Le bus 18 a actuellement 10 minutes de retard.»

Les retards, les changements d’itinéraire, les véhicules de remplacement ou les suppressions de lignes individuelles y sont publiés en continu afin que les voyageuses et voyageurs puissent planifier leur voyage aussi précisément que possible.

Si un SJYID n’est pas toujours livré via VDV 454, le «FahrtBezeichner» VDV 454 est livré dans GTFS-RT dans un original_trip_id pour les cas où aucun SJYID n’est disponible:

// Matches the original_trip_id in GTFS static.
optional string original_trip_id = 8;

Service Alerts

Exemple: «Arrêt Berne, Weissenbühl est actuellement fermé en raison d’un accident.»

En cas de déplacement de la bordure d’arrêt ou d’événements généraux imprévus ayant un impact sur un arrêt, un itinéraire ou l’ensemble du réseau, de brèves annonces peuvent être publiées afin d’informer les voyageurs et voyageuses et de leur expliquer la raison du changement.

Jeu de données GTFS-RT: Service Alerts (informations sur les événements)

Cookbook: GTFS-RT: Service Alerts (informations sur les événements en Suisse)

Vehicle Positions

Exemple: «Ce bus est à l’arrêt à 18h23 Berne, gare.«

Il est possible de publier ici des informations sur l’emplacement de différents véhicules de transit. Il est également possible de fournir le taux d’occupation actuel du véhicule, le type de véhicule ou d’autres informations similaires.

Les Vehicle Positions ne sont pas disponibles sur la plate-forme.

Concepts importants

• GTFS statique (aussi connu sous le nom de GTFS Schedule): Publication d’informations statiques de transit au format GTFS.
• GTFS Realtime: Publication d’informations de transit en temps réel en tant qu’enrichissement des données statiques GTFS, sous la forme de tampons de protocole.

Les différents éléments sont expliqués en détail sur les pages susmentionnées. Ils ne sont donc pas tous reproduits ici.

Description technique

Les mises à jour des Trip sont mises à disposition via une GET Request. Elles sont mises en veilleuse pendant 30 secondes, c’est pourquoi il n’y a que deux nouvelles données par minute.
Pour optimiser notre mise en cache, le gestionnaire d’API envoie une redirection avec un nouveau lien, c’est pourquoi les redirections doivent toujours être activées lors de l’utilisation de ce service. Pour de nombreuses bibliothèques de code, cela peut être réalisé avec des paramètres appropriés tels que «allow_redirects».

Autorisation et Open Services

Une clé API est nécessaire pour accéder à cette API. Elle peut être obtenue via notre API Manager (cf. instructions dans Howto: Accès à nos API avec des clés API.

Nombre maximal de requêtes par minute

Avec votre clé, vous pouvez effectuer au maximum deux requêtes par minute sur l’interface. Il s’agit d’une fenêtre coulissante.

En cas de demande trop rapide, le message suivant revient:

{
    "error": "Rate limit exceeded"
}

Référence à GFTS Static

Chaque flux GTFS-RT est basé sur un GTFS Static. Celui-ci est disponible les lundis et jeudis (en cas de panne, voir section suivante). À 15 heures, le flux GTFS-RT passe au nouveau GTFS Static. Comme les identifiants («service_id», «trip_id») peuvent changer avec n’importe quelle version du GTFS Static, la référence à la bonne GTFS Static est essentielle pour une implémentation correcte de l’interface.

Dans l’élément d’en-tête, il est fait référence à la version GTFS-Static correspondante dans l’élément feed_version (écriture en .json: FeedVersion). En cas d’affichage en JSON, l’en-tête pourrait alors ressembler à ceci (utiliser JSON uniquement à des fins de test, voir en bas):

  "Header": {
    "GtfsRealtimeVersion": "1.0",
    "Incrementality": "FullDataset",
    "Timestamp": 1727429583,
    "FeedVersion": "20240926"
  }

En cas de dérangement

L’export GTFS statique est publié le plus rapidement possible, suivi de GTFS Realtime environ 5 à 6 heures plus tard, mais au plus tard jusqu’à 18h00 le jour même. Si cela n’est pas possible, les nouvelles données sont activées dans GTFS Realtime le lendemain.

Exemple: Les nouvelles données GTFS statiques n’ont pu être publiées que dans l’après-midi. L’activation des données GTFS en temps réel aura lieu le lendemain vers 8h00.

URL d’appel

HTTP GET auf https://api.opentransportdata.swiss/la/gtfs-rt

(Attention: Pas de fin «/»)

En-tête:

• Content-Type: «application/octet-stream»
• L’agent utilisateur doit être défini (n’importe quelle valeur).
• «Accept-Encoding: br, gzip, deflate»
• Les redirections doivent être autorisées.

Exemple dans curl

curl -H "Authorization: Bearer eyJvcmciOiI2NDA2NTFhNTIyZmEwNTAwMDEyOWJiZTEiLCJpZCI6ImZjNzdjMzk2M2MwNjRjYzM4ZmNjOWZjYWQ4MjVlZWZkIiwiaCI6Im11cm11cjEyOCJ9"  -L -H "User-Agent: testuser" https://api.opentransportdata.swiss/la/gtfs-rt --compressed --output gtfs_rt_as_proto_buf.pb

Structure des données (Protocol Buffer)

Le format de données GTFS Realtime est basé sur des tampons de protocole, qui sont indépendants de la langue et de la plate-forme pour organiser les données dans un ordre sériel. Il est conçu comme un format binaire, ce qui le rend plus petit, plus rapide et plus simple que le XML. La structure des données est gtfs-realtime.proto-Fichier qui est utilisé pour générer le code source afin de traduire facilement les données structurées dans différentes langues (Java, C++, Python, etc.).

Structure des données (JSON)

La plate-forme propose également une implémentation JSON.

La requête s’effectue via l’URL:

HTTP GET https://api.opentransportdata.swiss/la/gtfs-rt?format=JSON

Cependant, la variante JSON n’est pas standardisée.

Utilisation de JSON à des fins de test uniquement

JSON ne peut être utilisé à des fins de test, par exemple lorsque le développeur d’une nouvelle application souhaite voir sous une forme lisible quelles données sont contenues dans notre GTFS-RT.

Au final, l’interface GTFS-RT ne devrait pas être utilisée en JSON lisible, mais en binaire (sans?FORMAT=JSON) pour les raisons suivantes:

• binaire est beaucoup plus performant que JSON et il faut envoyer et lire beaucoup plus de données en JSON (un message JSON peut atteindre env. 11 Mo),
• JSON n’est pas spécifié, mais avec GTFS-RT binaire, le client GTFS peut être sûr qu’il est conforme à la norme GTFS-RT

Précision

Les retards ont une précision d’un dixième de minute (0,1 min = 6 s).

Interprétation des données

Pour une interprétation précise des données, il est possible de consulter directement la spécification GTFS.

Les cas particuliers les plus importants concernent les quais qui Côté GTFS sont décrites.

Autres points importants

• GTFS-RT ne fournit de nouvelles données qu’en cas de changement. Notre système ne tient compte que des prévisions de départ. Si les prévisions de départ sont maintenues et que seules les prévisions d’arrivée changent, aucune annonce GTFS-RT n’est générée pour le trajet concerné.
• Si un trajet circule à l’heure, il est affiché avec «Delay»: 0 dans StopTimeUpdate.
• Exemple

    {
      "id": ".ojp-92-206.1.TA.50.j26|20260624",
      "tripUpdate": {
        "trip": {
          "tripId": ".ojp-92-206.1.TA.50.j26",
          "startTime": "12:41:00",
          "startDate": "20260624",
          "scheduleRelationship": "SCHEDULED",
          "routeId": "92-206-j26-1",
          "originalTripId": "85:876:6037_103"
        },
        "stopTimeUpdate": [
          {
            "stopSequence": 1,
            "departure": {
              "delay": 0
            },
            "stopId": "ch:1:sloid:93924:0:2",
            "scheduleRelationship": "SCHEDULED"
          },
          {
            "stopSequence": 8,
            "arrival": {
              "delay": 30
            },
            "departure": {
              "delay": 30
            },
            "stopId": "ch:1:sloid:93932:0:1",
            "scheduleRelationship": "SCHEDULED"
          },
          {
            "stopSequence": 9,
            "arrival": {
              "delay": 0
            },
            "departure": {
              "delay": 0
            },
            "stopId": "ch:1:sloid:93933:0:1",
            "scheduleRelationship": "SCHEDULED"
          }
        ]
      }
    },

Questions et réponses