GTFS Realtime (GTFS-RT) est une extension de GTFS Static et enrichit les informations de transit statiques avec des informations en temps réel. Les données GTFS en temps réel sont alignées sur les données GTFS Static. Les données GTFS-RT couvrent toutes les modifications connues dans les TP suisses dans 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 spécifique
- Aspects techniques
- Autorisation et services ouverts
- Nombre maximal de requêtes par minute
- Référence au GFTS Static
- Gestion des dérangements
- URL pour l’appel
- Structure des données (Protocol Buffer)
- Structure des données (JSON)
- Utilisation de JSON uniquement à des fins de test
- Précision
- Compression
- Interprétation des données
- Autres points importants
- Questions & réponses
- Informations supplémentaires
Description spécifique
GTFS-RT permet d’enrichir les informations de transit statiques avec trois types d’informations supplémentaires. Ces trois enrichissements sont généralement mis à disposition individuellement via HTTP et mis à jour régulièrement, ce qui permet aux développeurs de choisir les données en temps réel avec lesquelles ils souhaitent enrichir leurs applications.
Les trois types d’informations complémentaires sont:
- Trip Updates (mises à jour de voyage)
- Service Alerts (alertes de service)
- Vehicle Positions (positions des véhicules) – ne sont pas publiés sur la plateforme Open Data Mobilité Suisse
Trip Updates
Ex : “Le bus 18 a actuellement 10 minutes de retard”.
Les retards, les itinéraires modifiés, les véhicules de remplacement ou les suppressions pour certaines lignes y sont publiés en permanence afin de permettre aux voyageurs de planifier leur voyage le plus précisément possible.
Service Alerts
Ex : “La station de Berne, Weissenbühl est actuellement fermée en raison d’un accident”.
En cas de déplacement du bord d’arrêt ou, plus généralement, d’événements imprévus affectant un arrêt, un itinéraire ou l’ensemble du réseau, de brefs messages peuvent être publiés afin de tenir les voyageurs informés et d’expliquer la raison de la modification.
Jeu de données: GTFS Realtime – Service Alerts
Vehicle Positions
Ex : “A 18h23, ce bus se trouve à l’arrêt Berne, gare“.
Il est possible de publier ici des informations sur l’emplacement des différents véhicules Transit. En outre, le taux d’occupation actuel du véhicule, le type de véhicule ou des informations similaires peuvent également être fournis.
Les Vehicle Positions ne sont pas disponibles sur la plateforme.
Vous trouverez une liste détaillée des différentes unités d’information sur https://developers.google.com/transit/gtfs-realtime/reference/
Notions importantes
- GTFS Static: publication d’informations de transit statiques au format GTFS.
- GTFS Realtime: publication d’informations de transit en temps réel en tant qu’enrichissement des données statiques GTFS, sous forme de Protocol Buffers.
Aspects techniques
Les CFF mettent à disposition les Trip Updates via une requête GET.
Autorisation et services ouverts
Une clé API est nécessaire pour accéder à cette API. Il peut être obtenu via le portail des développeurs. Vous avez besoin d’une clé de type “Default Key“. Le jeton doit être envoyé dans l’en-tête HTTP en tant qu'”Authorization”.
Test-Key: 57c5dbbbf1fe4d000100001842c323fa9ff44fbba0b9b925f0c052d1
Nombre maximal de requêtes par minute
Vous pouvez effectuer au maximum deux requêtes par minute sur l’interface avec votre clé. Il s’agit d’une fenêtre coulissante.
Si la demande est trop rapide, le message suivant est renvoyé:
1 2 3 |
{ "error": "Rate limit exceeded" } |
Référence au GFTS Static
Chaque flux GTFS-RT est basé sur un GTFS Static. Celui-ci est mis à disposition tous les lundis et jeudis (pour les cas de panne, voir paragraphe suivant). Chaque fois à 15 heures, le flux GTFS-RT sera remplacé par le nouveau flux GTFS Static. Comme de nombreux identifiants (“service_id”, “trip_id”) sont générés pour chaque version de GTFS Static, la référence au bon GTFS Static est centrale pour une implémentation correcte de l’interface.
Publication GTFS-S | Activation GTFS-RT |
lundi entre 9 et 10 heures | lundi 3 pm |
jeudi entre 9 et 10 heures | jeudi 3 pm |
Gestion des dérangements
En cas de problème lors des publications régulières du lundi ou du jeudi, la paire de données GTFS corrigée sera publiée dès que possible après le problème.
Dans ces cas, GTFS Realtime passe à cette nouvelle version 6 heures après la publication du jeu de données GTFS Static correspondant (ce qui est également reconnaissable à la version du flux correspondante dans GTFS Realtime).
URL pour l’appel
HTTP GET auf https://api.opentransportdata.swiss/gtfsrt2020
(Attention: pas de fin “/”)
Avec l’en-tête d’autorisation et Content-Type= “text/XML” ou “application/XML”.
Content-Type: nous vous suggérons de définir “application/octet-stream”.
Structure des données (Protocol Buffer)
Le format de données GTFS Realtime est basé sur les Protocol Buffers, qui sont des mécanismes neutres en termes de langage et de plateforme pour mettre les données en ordre sériel. Il est conçu comme un format binaire, ce qui le rend plus petit, plus rapide et plus simple que XML. La structure des données est définie dans un fichier appelé gtfs-realtime.proto, qui est utilisé pour générer le code source afin de traduire facilement les données structurées dans différents langages (Java, C++, Python, etc.).
Structure des données (JSON)
La plateforme met également à disposition une implémentation JSON.
La requête se fait alors via l’URL : HTTP GET https://api.opentransportdata.swiss/gtfsrt2020?format=JSON
Notez que la variante JSON n’est pas standardisée.
Utilisation de JSON uniquement à des fins de test
JSON ne peut être utilisé qu’à des fins de test, par exemple lorsqu’un développeur d’une nouvelle application veut voir sous une forme lisible quelles sont les données contenues dans notre GTFS-RT.
Au final, l’interface GTFS-RT ne devrait pas être exploitée en JSON lisible, mais en binaire (sans ?FORMAT=JSON) pour les raisons suivantes:
- le binaire est beaucoup plus performant que le JSON et il y a beaucoup plus de données à transmettre et à lire dans le JSON (un message JSON peut peser jusqu’à environ 11 Mo),
- JSON n’est pas spécifié, avec le GTFS-RT binaire, le client GTFS peut compter sur le fait qu’il est conforme à la norme GTFS-RT
Précision
Tous les retards sont à la minute près. Une extension est envisagée, mais elle n’interviendra que plus tard.
Compression
Le flux JSON peut également être obtenu sous forme comprimée.
Pour cela, l’en-tête suivant doit être fourni:
1 |
Accept-Encoding: gzip, deflate |
La compression est d’environ 90%. C’est-à-dire que les données sont transmises beaucoup plus rapidement.
Interprétation des données
Pour une interprétation précise des données, il est possible de consulter directement la spécification GTFS.
Le cas spécial le plus important est celui des passerelles et celles-ci sont décrites sur le site du GTFS.
Autres points importants
- Une règle de mise à jour pour les retards s’applique au GTFS-RT. Par exemple, si un trajet entier a 5 minutes de retard, cela n’est indiqué que sur le premier arrêt.
Pour tous les autres arrêts, le retard doit être appliqué lors de l’importation. La mise à jour doit être effectuée à la fois pour les heures d’arrivée et de départ. - GTFS-RT ne fournit de nouvelles données que si quelque chose a changé. Notre système ne prend en compte que les prévisions de départ. Si les prévisions de départ
restent et que seules les prévisions d’arrivée changent, aucun message GTFS-RT n’est généré pour ce trajet.
Questions & réponses
Que signifie un message en temps réel sans “stop_time_updates”? | Les messages en temps réel sans “stop_time_updates” sont des déclenchements sans temps réel. Des modifications ont été apportées à cet égard, de sorte que les trajets sans temps réel ne sont plus transmis. |
Se pourrait-il que sur les lignes où la qualité des données est mauvaise, une entité gtfsrt soit toujours livrée avec delay=0, au lieu de ne pas livrer d’entité gtfsrt du tout? | Non, ce n’est pas le cas. Soit un trajet est en temps réel et tous les retards sont indiqués, soit il n’est pas en temps réel. Delay 0 signifie temps réel et ponctuel. Soit nous n’avons pas reçu de retard dans VDV 454 AUS, soit nous n’avons pas pu traiter le message avec la prévision. |
Informations supplémentaires
Vous trouverez de plus amples informations sur GTFS Realtime sur la page des développeurs GTFS de Google: https://developers.google.com/transit/gtfs-realtime/
Autres services GTFS