GTFS Realtime Reference¶

Un flux GTFS Realtime permet aux agences de transport de fournir aux consommateurs des informations en temps réel sur les perturbations de leur service (gares fermées, lignes hors service, retards importants, etc.), la localisation de leurs véhicules et les heures d’arrivée prévues.

La version 2.0 de la spécification du flux est discutée et documentée sur ce site. Les versions valides sont "2.0", "1.0".

Définitions des termes¶

Requis¶

Dans GTFS-realtime v2.0 et versions ultérieures, la colonne * Requis* décrit les champs qui doivent être fournis par un producteur pour que les données de transit pour être valide et avoir un sens pour une application consommatrice.

Les valeurs suivantes sont utilisées dans le champ * Requis* :

Requis : Ce champ doit être fourni par un producteur de flux GTFS Realtime.
Requis sous condition : Ce champ est obligatoire sous certaines conditions, qui sont décrites dans le champ Description. En dehors de ces conditions, le champ est facultatif.
Optionnel : Ce champ est facultatif et n’a pas besoin d’être implémenté par les producteurs. Cependant, si les données sont disponibles dans les systèmes de localisation automatique des véhicules sous-jacents (par exemple, VehiclePosition timestamp), il est recommandé aux producteurs de fournir ces champs facultatifs lorsque cela est possible.

Notez que les exigences sémantiques n’ont pas été définies dans la version 1.0 de GTFS-realtime, et par conséquent les flux avec gtfs_realtime_version de 1 peuvent ne pas répondre à ces exigences (voir la proposition d’exigences sémantiques pour plus de détails).

Cardinalité¶

Cardinalité représente le nombre d’éléments pouvant être fournis pour un champ particulier, avec les valeurs suivantes :

Un - Un seul élément peut être fourni pour ce champ. Cela correspond aux cardinalités du tampon de protocole obligatoire et facultatif.
Plusieurs - Plusieurs éléments (0, 1 ou plus) peuvent être fournis pour ce champ. Cela correspond à la cardinalité répétée du tampon de protocole.

Faites toujours référence aux champs * Requis et Description* pour voir quand un champ est obligatoire, obligatoire sous condition ou facultatif. Veuillez faire référence à gtfs-realtime.proto pour la cardinalité du tampon de protocole.

Types de données du tampon de protocole¶

Les types de données du tampon de protocole suivants sont utilisés pour décrire les éléments de flux :

message : type complexe
enum : Liste des valeurs fixes

Champs expérimentaux¶

Les champs étiquetés comme expérimentaux sont sujets à changement et ne sont pas encore formellement adoptés dans la spécification. Un champ expérimental pourrait être formellement adopté à l’avenir.

Index des éléments¶

FeedMessage

Elements¶

message FeedMessage¶

Le contenu d’un message de flux. Chaque message du flux est obtenu en réponse à une requête HTTP GET appropriée. Un flux en temps réel est toujours défini par rapport à un flux GTFS existant. Tous les identifiants d’entité sont résolus par rapport au flux GTFS.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
header	FeedHeader	Requis	Un	Métadonnées sur ce flux et message de flux.
entity	FeedEntity	Requis sous condition	Plusieurs	Contenu du flux. Si des informations en temps réel sont disponibles pour le système de transport en commun, ce champ doit être renseigné. Si ce champ est vide, les consommateurs doivent supposer qu’aucune information en temps réel n’est disponible pour le système.

message FeedHeader¶

Métadonnées sur un flux, incluses dans les messages du flux.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
gtfs_realtime_version	string	Requis	Un	Version de la spécification du flux. La version actuelle est la 2.0.
incrementality	Incrementality	Requis	Un
timestamp	uint64	Requis	Un	Cet horodatage identifie le moment où le contenu de ce flux a été créé (en heure du serveur). En temps POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). Pour éviter les décalages horaires entre les systèmes produisant et consommant des informations en temps réel, il est fortement conseillé de dériver l’horodatage d’un serveur de temps. Il est tout à fait acceptable d’utiliser des serveurs de strate 3 ou même inférieure, car des différences horaires allant jusqu’à quelques secondes sont tolérables.

enum Incrementality¶

Détermine si la récupération actuelle est incrémentielle.

FULL_DATASET: cette mise à jour du flux écrasera toutes les informations précédentes en temps réel pour le flux. Ainsi, cette mise à jour devrait fournir un instantané complet de toutes les informations connues en temps réel.
DIFFERENTIAL: actuellement, ce mode est non pris en charge et le comportement est non spécifié pour les flux qui utilisent ce mode. Il y a des discussions sur la liste de diffusion GTFS Realtime autour de la spécification complète du comportement du mode DIFFÉRENTIEL et la documentation sera mise à jour lorsque ces discussions seront finalisées.

Valeurs

Valeur
FULL_DATASET
DIFFERENTIAL

message FeedEntity¶

Une définition (ou une mise à jour) d’une entité dans le flux de transit. Si l’entité n’est pas supprimée, exactement l’un des champs ’trip_update’, ’vehicle’, ’alert’, ’shape’, ’stop’ ou ’trip_modification’ doit être renseigné.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
id	string	Requis	Un	Identifiant unique du flux pour cette entité. Les identifiants sont utilisés uniquement pour fournir une prise en charge de l’incrémentalité. Les entités réelles référencées par le flux doivent être spécifiées par des sélecteurs explicites (voir EntitySelector ci-dessous pour plus d’informations).
is_deleted	bool	Optionnel	Un	Si cette entité doit être supprimée. Doit être fourni uniquement pour les flux avec une Incrementality de DIFFERENTIAL ; ce champ ne doit PAS être fourni pour les flux avec une Incrementality de FULL_DATASET.
trip_update	TripUpdate	Requis sous condition	Un	Données sur les retards de départ en temps réel d’un voyage. Au moins un des champs trip_update, véhicule, alerte ou forme doit être fourni- tous ces champs ne peuvent pas être vides.
vehicle	VehiclePosition	Requis sous condition	Un	Données sur la position en temps réel d’un véhicule. Au moins un des champs trip_update, véhicule, alerte ou forme doit être fourni- tous ces champs ne peuvent pas être vides.
alert	Alerte	Requis sous condition	Un	Données sur l’alerte en temps réel. Au moins un des champs trip_update, véhicule, alerte ou forme doit être fourni- tous ces champs ne peuvent pas être vides.
shape	Forme	Requis sous condition	Un	Données sur les formes ajoutées en temps réel, par exemple pour un détour. Au moins un des champs trip_update, véhicule, alerte ou forme doit être fourni- tous ces champs ne peuvent pas être vides. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
stop	Stop	Conditionnellement requis	Un	Un nouvel arrêt ajouté au flux de manière dynamique. Attention :ce champ est encoreexpérimentalet sujet à changement. Il pourra être formellement adopté à l’avenir.
trip_modifications	TripModifications	Conditionnellement requis	Un	Liste des trajets affectés par des modifications particulières, comme un détour. Attention : ce champ est encore expérimental et sujet à changement. Il peut être formellement adopté dans le futur.

message TripUpdate¶

Mise à jour en temps réel sur la progression d’un véhicule tout au long d’un trajet. Veuillez également vous référer à la discussion générale sur les entités de mises à jour de voyage. upd En fonction de la valeur de ScheduleRelationship, un TripUpdate peut spécifier :

Un voyage qui se déroule selon le planning.
Un voyage qui s’effectue le long d’un itinéraire mais n’a pas d’horaire fixe.
Un trajet qui a été ajouté ou supprimé par rapport à l’horaire.
Un nouveau voyage qui est une copie d’un voyage existant en GTFS statique. Il s’exécutera à la date et à l’heure de service spécifiées dans TripProperties.

Les mises à jour peuvent concerner des événements d’arrivée/départ futurs et prévus, ou des événements passés déjà survenus. Dans la plupart des cas, les informations sur les événements passés sont une valeur mesurée, il est donc recommandé que sa valeur d’incertitude soit 0. Bien qu’il puisse y avoir des cas où cela ne soit pas le cas, il est donc permis d’avoir une valeur d’incertitude différente de 0 pour les événements passés. Si l’incertitude d’une mise à jour n’est pas 0, soit la mise à jour est une prédiction approximative pour un voyage qui n’est pas terminé, soit la mesure n’est pas précise, soit la mise à jour est une prédiction pour le passé qui n’a pas été vérifiée après que l’événement s’est produit.

Si un véhicule effectue plusieurs trajets dans le même bloc (pour plus d’informations sur les trajets et les blocs, veuillez vous référer à GTFS trips.txt) :

le flux doit inclure une TripUpdate pour le trajet actuellement effectué par le véhicule. Les producteurs sont encouragés à inclure des TripUpdates pour un ou plusieurs voyages après le voyage en cours dans le bloc de ce véhicule s’ils sont confiants dans la qualité des prévisions pour ces futurs voyages. L’inclusion de plusieurs TripUpdates pour le même véhicule évite les « pop-in » de prédiction pour les usagers lorsque le véhicule passe d’un trajet à un autre et donne également aux usagers un préavis des retards qui ont un impact sur les trajets en aval (par exemple, lorsque le retard connu dépasse les temps d’escale prévus entre les trajets).
Il n’est pas nécessaire que les entités TripUpdate respectives soient ajoutées au flux dans le même ordre dans lequel elles sont planifiées dans le bloc. Par exemple, s’il y a des trajets avec les trip_ids 1, 2 et 3 qui appartiennent tous à un seul bloc, et que le véhicule effectue le trajet 1, puis le trajet 2, puis le trajet 3, les entités trip_update peuvent apparaître dans n’importe quel ordre. - par exemple, ajouter le trajet 2, puis le trajet 1, puis le trajet 3 est autorisé.

A noter que la mise à jour peut décrire un trajet déjà effectué. Pour cela, il suffit de fournir une mise à jour pour la dernière étape du trajet. Si l’heure d’arrivée au dernier arrêt est dans le passé, le client conclura que tout le voyage est dans le passé (il est possible, bien que sans conséquence, de fournir également des mises à jour pour les arrêts précédents). Cette option est plus pertinente pour un voyage qui s’est terminé plus tôt que prévu, mais selon le calendrier, le voyage est toujours en cours à l’heure actuelle. La suppression des mises à jour pour ce voyage pourrait faire supposer au client que le voyage est toujours en cours. Notez que le fournisseur de flux est autorisé, mais pas obligé, à purger les mises à jour passées- c’est un cas où cela serait utile en pratique.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
trip	TripDescriptor	Requis	Un	Le voyage auquel ce message s’applique. Il peut y avoir au plus une entité TripUpdate pour chaque instance de voyage réelle. S’il n’y en a pas, cela signifie qu’aucune information de prédiction n’est disponible. Cela ne signifie pas que le voyage se déroule comme prévu.
vehicle	VehicleDescriptor	Optionnel	Un	Informations complémentaires sur le véhicule qui assure ce trajet.
stop_time_update	StopTimeUpdate	Requis sous condition	Plusieurs	Mises à jour des StopTimes pour le voyage (à la fois futures, c’est-à-dire les prévisions, et dans certains cas, passées, c’est-à-dire celles qui se sont déjà produites). Les mises à jour doivent être triées par stop_sequence et s’appliquer à tous les arrêts suivants du trajet jusqu’au prochain stop_time_update spécifié. Au moins un stop_time_update doit être fourni pour le voyage, sauf si trip.schedule_relationship est CANCELED, DELETED ou DUPLICATED. Si le voyage est annulé ou supprimé, aucun stop_time_updates ne doit être fourni. Si des stop_time_updates sont fournis pour un voyage annulé ou supprimé, alors trip.schedule_relationship a priorité sur tous les stop_time_updates et leur planning_relationship associé. Si le trajet est dupliqué, stop_time_updates peut être fourni pour indiquer des informations en temps réel pour le nouveau trajet.
timestamp	uint64	Optionnel	Un	Moment le plus récent auquel la progression en temps réel du véhicule a été mesurée pour estimer les StopTimes dans le futur. Lorsque des StopTimes passés sont fournis, les heures d’arrivée/départ peuvent être antérieures à cette valeur. En temps POSIX (c’est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC).
delay	int32	Optionnel	Un	L’écart d’horaire actuel pour le voyage. Le délai ne doit être spécifié que lorsque la prédiction est donnée par rapport à un calendrier existant dans GTFS. Le retard (en secondes) peut être positif (ce qui signifie que le véhicule est en retard) ou négatif (ce qui signifie que le véhicule est en avance sur l’horaire prévu). Un retard de 0 signifie que le véhicule est exactement à l’heure. Les informations de retard dans StopTimeUpdates ont priorité sur les informations de retard au niveau du déclenchement, de sorte que le retard au niveau du déclenchement se propage uniquement jusqu’au prochain arrêt du trajet avec une valeur de délai StopTimeUpdate spécifiée. Les fournisseurs de flux sont fortement encouragés à fournir une valeur TripUpdate.timestamp indiquant la dernière fois que la valeur du délai a été mise à jour, afin d’évaluer la fraîcheur des données. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
trip_properties	TripProperties	Optionnel	Un	Fournit les propriétés mises à jour pour le voyage. Attention :ce message est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message StopTimeEvent¶

Informations de synchronisation pour un seul événement prédit (arrivée ou départ). Le timing comprend le retard et/ou le temps estimé et l’incertitude.

le délai doit être utilisé lorsque la prédiction est donnée par rapport à un calendrier existant dans GTFS.
L’heure doit être indiquée, qu’il y ait un horaire prévu ou non. Si l’heure et le retard sont spécifiés, l’heure aura la priorité (bien que normalement, l’heure, si elle est donnée pour un trajet programmé, doit être égale à l’heure programmée en GTFS + délai).

L’incertitude s’applique également au temps et au retard. L’incertitude spécifie approximativement l’erreur attendue dans le délai réel (mais notez que nous ne définissons pas encore sa signification statistique précise). Il est possible que l’incertitude soit de 0, par exemple pour les trains circulant sous contrôle de synchronisation informatique.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
delay	int32	Requis sous condition	Un	Le retard (en secondes) peut être positif (ce qui signifie que le véhicule est en retard) ou négatif (ce qui signifie que le véhicule est en avance sur l’horaire prévu). Un retard de 0 signifie que le véhicule est exactement à l’heure. Soit le délai, soit l’heure doivent être fournis dans un StopTimeEvent- les deux champs ne peuvent pas être vides.
time	int64	Requis sous condition	Un	Événement en temps absolu. En temps POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). Soit le délai, soit l’heure doivent être fournis dans un StopTimeEvent- les deux champs ne peuvent pas être vides.
uncertainty	int32	Optionnel	Un	Si l’incertitude est omise, elle est interprétée comme inconnue. Pour spécifier une prédiction totalement certaine, définissez son incertitude sur 0.

message StopTimeUpdate¶

Mise à jour en temps réel des événements d’arrivée et/ou de départ pour un arrêt donné d’un voyage. Veuillez également vous référer à la discussion générale sur les mises à jour des horaires d'arrêt dans la documentation TripDescriptor et trip mises à jour entités.

Des mises à jour peuvent être fournies pour les événements passés et futurs. Le producteur est autorisé, bien que cela ne soit pas obligatoire, à abandonner les événements passés. La mise à jour est liée à un arrêt spécifique soit via stop_sequence soit stop_id, donc l’un de ces champs doit obligatoirement être renseigné. Si le même stop_id est visité plus d’une fois au cours d’un trajet, alors stop_sequence doit être fourni dans toutes les StopTimeUpdates pour ce stop_id lors de ce trajet.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
stop_sequence	uint32	Requis sous condition	Un	Doit être le même que dans stop_times.txt dans le flux GTFS correspondant.stop_sequence ou stop_id doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides.stop_sequence est requis pour les trajets qui visitent le même stop_id plus d’une fois (par exemple, une boucle) pour lever l’ambiguïté à quel arrêt la prédiction est destinée. Si `StopTimeProperties.assigned_stop_id` est renseigné, alors `stop_sequence` doit être renseigné.
stop_id	string	Requis sous condition	Un	Doit être le même que dans le fichier stops.txt du flux GTFS correspondant.stop_sequence ou stop_id doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. Si `StopTimeProperties.assigned_stop_id` est renseigné, il est préférable d’omettre `stop_id` et d’utiliser uniquement `stop_sequence`. Si `StopTimeProperties.assigned_stop_id` et `stop_id` sont renseignés, `stop_id` doit correspondre à `assigned_stop_id`.
arrival	StopTimeEvent	Requis sous condition	Un	Si Schedule_relationship est vide ou SCHEDULED, l’arrivée ou le départ doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. L’arrivée et le départ peuvent tous deux être vides lorsque Schedule_relationship est SKIPPED. Si Schedule_relationship est NO_DATA, l’arrivée et le départ doivent être vides.
departure	StopTimeEvent	Requis sous condition	Un	Si Schedule_relationship est vide ou SCHEDULED, l’arrivée ou le départ doivent être fournis dans un StopTimeUpdate- les deux champs ne peuvent pas être vides. L’arrivée et le départ peuvent tous deux être vides lorsque Schedule_relationship est SKIPPED. Si Schedule_relationship est NO_DATA, l’arrivée et le départ doivent être vides.
departure_occupancy_status	OccupancyStatus	Optionnel	Un	L’état prévu d’occupation des passagers pour le véhicule immédiatement après le départ de l’arrêt donné. S’il est fourni, stop_sequence doit être fourni. Pour fournir exit_occupancy_status sans fournir de prévisions d’arrivée ou de départ en temps réel, remplissez ce champ et définissez StopTimeUpdate.schedule_relationship = NO_DATA. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
schedule_relationship	ScheduleRelationship	Optionnel	Un	La relation par défaut est PLANIFIÉE.
stop_time_properties	StopTimeProperties	Optionnel	Un	Mises à jour en temps réel pour certaines propriétés définies dans GTFS stop_times.txt Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

enum ScheduleRelationship¶

La relation entre ce StopTime et le planning statique.

Valeurs

Valeur	Commentaire
SCHEDULED	Le véhicule avance conformément à son horaire d’arrêts statique, mais pas nécessairement selon les horaires de l’horaire. Ceci est le comportement par défaut. Au moins un d’arrivée et de départ doit être fourni. Les trajets basés sur la fréquence (GTFS frequencies.txt avec exact_times = 0) ne doivent pas avoir de valeur SCHEDULED et doivent plutôt utiliser UNSCHEDULED.
SKIPPED	L’arrêt est sauté, c’est-à-dire que le véhicule ne s’arrêtera pas à cet arrêt. L’arrivée et le départ sont facultatifs. Lorsqu’il est défini, `SKIPPED` n’est pas propagé aux arrêts suivants du même trajet (c’est-à-dire que le véhicule s’arrêtera aux arrêts suivants du trajet à moins que ces arrêts n’aient également un `stop_time_update` avec `schedule_relationship: SKIPPED`). Le retard par rapport à un arrêt précédent du trajet se se propage à l’arrêt « `SKIPPED` ». En d’autres termes, si un `stop_time_update` avec une prédiction `arrival` ou `departure` n’est pas défini pour un arrêt après l’arrêt `SKIPPED`, la prédiction en amont de l’arrêt `SKIPPED` sera propagée à l’arrêt après le `Arrêt`SKIPPED`et arrêts suivants dans le trajet jusqu’à ce qu’un`stop_time_update` pour un arrêt ultérieur soit fourni.
NO_DATA	Aucune donnée n’est fournie pour cet arrêt. Cela indique qu’aucune information de synchronisation en temps réel n’est disponible. Lorsque NO_DATA est défini, il se propage aux arrêts suivants. C’est donc la méthode recommandée pour spécifier à partir de quel arrêt vous n’avez pas d’informations de synchronisation en temps réel. Lorsque NO_DATA est défini, ni l’arrivée ni le départ ne doivent être fournis.
UNSCHEDULED	Le véhicule effectue un trajet basé sur la fréquence (GTFS frequencies.txt avec exact_times = 0). Cette valeur ne doit pas être utilisée pour les trajets qui ne sont pas définis dans GTFS frequencies.txt, ou pour les trajets dans GTFS frequencies.txt avec exact_times = 1. Les trajets contenant `stop_time_updates` avec `schedule_relationship: UNSCHEDULED` doivent également définir le TripDescriptor `schedule_relationship: UNSCHEDULED` Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message StopTimeProperties¶

Mise à jour en temps réel de certaines propriétés définies dans GTFS stop_times.txt.

Attention :ce message est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
assigned_stop_id	string	Optionnel	Un	Prend en charge les affectations d’arrêt en temps réel. Fait référence à un `stop_id` défini dans le GTFS `stops.txt`. Le nouveau « `assigned_stop_id` » ne devrait pas entraîner une expérience de voyage significativement différente pour l'utilisateur final que le « `stop_id` » défini dans GTFS « `stop_times.txt` ». En d’autres termes, l'utilisateur final ne doit pas considérer ce nouveau « `stop_id` » comme un « changement inhabituel » si le nouvel arrêt a été présenté dans une application sans aucun contexte supplémentaire. Par exemple, ce champ est destiné à être utilisé pour les affectations de quai en utilisant un `stop_id` qui appartient à la même station que l’arrêt initialement défini dans GTFS `stop_times.txt`. Pour attribuer un arrêt sans fournir de prévisions d’arrivée ou de départ en temps réel, remplissez ce champ et définissez `StopTimeUpdate.schedule_relationship = NO_DATA`. Si ce champ est renseigné, `StopTimeUpdate.stop_sequence` doit être renseigné et `StopTimeUpdate.stop_id` ne doit pas être renseigné. Les affectations d’arrêt doivent également être reflétées dans d’autres champs GTFS Realtime (par exemple, `VehiclePosition.stop_id`). Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message TripProperties¶

Définit les propriétés mises à jour du voyage

Attention : ce message est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
trip_id	string	Requis sous condition	Un	Définit l’identifiant d’un nouveau voyage qui est un doublon d’un voyage existant défini dans (CSV) GTFS trips.txt mais qui commencera à une date et/ou une heure de service différente (définie à l’aide de `TripProperties.start_date` et `TripProperties.start_time`). Voir la définition de `trips.trip_id` dans (CSV) GTFS. Sa valeur doit être différente de celles utilisées dans le (CSV) GTFS. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ ne doit pas être renseigné et sera ignoré par les consommateurs. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
start_date	string	Requis sous condition	Un	date de prestation à laquelle le trajet dupliqué sera effectué. Doit être fourni au format AAAAMMJJ. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ ne doit pas être renseigné et sera ignoré par les consommateurs. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
start_time	string	Requis sous condition	Un	Définit l’heure de début de départ du trajet lorsqu’il est dupliqué. Voir la définition de `stop_times.departure_time` dans (CSV) GTFS. Les heures d’arrivée et de départ prévues pour le voyage dupliqué sont calculées en fonction du décalage entre le voyage d’origine `departure_time` et ce champ. Par exemple, si un trajet GTFS a l’arrêt A avec une `departure_time` de `10:00:00` et l’arrêt B avec une `departure_time` de `10:01:00`, et que ce champ est renseigné avec la valeur `10:30:00`, l’arrêt B du trajet dupliqué aura une `departure_time` programmée de `10:31:00`. Des valeurs de `delay` de prédiction en temps réel sont appliquées à cette heure programmée calculée pour déterminer l’heure prédite. Par exemple, si un `delay` de départ de `30` est prévu pour l’arrêt B, alors l’heure de départ prévue est `10:31:30`. Les valeurs `time` de prédiction en temps réel ne sont soumises à aucun décalage et indiquent l’heure prédite telle que fournie. Par exemple, si une `time` de départ représentant 10:31:30 est fournie pour l’arrêt B, alors l’heure de départ prévue est `10:31:30`. Ce champ est obligatoire si `schedule_relationship` est `DUPLICATED`, sinon ce champ est obligatoire. Le champ ne doit pas être renseigné et sera ignoré par les consommateurs. Attention : son domaine est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.
shape_id	string	Optionnel	Un	Spécifie la forme du trajet du véhicule pour ce trajet lorsqu’il diffère de l’original. Fait référence à une forme définie dans le GTFS (CSV) ou à une nouvelle entité de forme dans un flux en temps réel. Voir la définition de `trips.shape_id` dans (CSV) GTFS. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message VehiclePosition¶

Informations de positionnement en temps réel pour un véhicule donné.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
trip	TripDescriptor	Optionnel	Un	Le voyage que ce véhicule dessert. Peut être vide ou partiel si le véhicule ne peut pas être identifié avec une instance de trajet donnée.
vehicle	VehicleDescriptor	Optionnel	Un	Informations complémentaires sur le véhicule qui assure ce trajet. Chaque entrée doit avoir un identifiant de véhicule unique.
position	Position	Optionnel	Un	Position actuelle de ce véhicule.
current_stop_sequence	uint32	Optionnel	Un	L’index de séquence d’arrêt de l’arrêt actuel. La signification de current_stop_sequence (c’est-à-dire l’arrêt auquel elle fait référence) est déterminée par current_status. Si current_status est manquant, IN_TRANSIT_TO est supposé.
stop_id	string	Optionnel	Un	Identifie l’arrêt actuel. La valeur doit être la même que dans le fichier stops.txt du flux GTFS correspondant. Si `StopTimeProperties.assigned_stop_id` est utilisé pour attribuer un `stop_id`, ce champ doit également refléter le changement dans `stop_id`.
current_status	VehicleStopStatus	Optionnel	Un	L’état exact du véhicule par rapport à l’arrêt en cours. Ignoré si current_stop_sequence est manquant.
timestamp	uint64	Optionnel	Un	Moment auquel la position du véhicule a été mesurée. En temps POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC).
congestion_level	CongestionLevel	Optionnel	Un
occupancy_status	OccupancyStatus	Facultatif	Un	L’état d’occupation des passagers du véhicule ou du transport. Si multi_carriage_details est renseigné avec OccupancyStatus par voiture, alors ce champ doit décrire l’ensemble du véhicule avec toutes les voitures acceptant des passagers prises en compte. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
occupancy_percentage	uint32	Optionnel	Un	Une valeur en pourcentage indiquant le degré d’occupation des passagers dans le véhicule. La valeur 100 doit représenter l’occupation maximale totale pour laquelle le véhicule a été conçu, y compris le nombre de places assises et debout, et les réglementations d’exploitation en vigueur le permettent. La valeur peut dépasser 100 s’il y a plus de passagers que la capacité maximale prévue. La précision de occupancy_percentage doit être suffisamment faible pour que les passagers individuels ne puissent pas être suivis à l’embarquement ou à la descente du véhicule. Si multi_carriage_details est renseigné avec occupancy_percentage par voiture, alors ce champ doit décrire l’ensemble du véhicule avec toutes les voitures acceptant des passagers prises en compte. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
multi_carriage_details	CarriageDetails	Optionnel	Plusieurs	Détails des multiples wagons de ce véhicule donné. La première occurrence représente le premier transport du véhicule, étant donné le sens de déplacement actuel. Le nombre d’occurrences du champ multi_carriage_details représente le nombre de wagons du véhicule. Cela inclut également les wagons non embarquables, comme les moteurs, les wagons de maintenance, etc… car ils fournissent des informations précieuses aux passagers sur l’endroit où se tenir sur une plate-forme. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

enum VehicleStopStatus¶

Valeurs

Valeur	Commentaire
INCOMING_AT	Le véhicule est sur le point d’arriver à l’arrêt (sur un affichage d’arrêt, le symbole du véhicule clignote généralement).
STOPPED_AT	Le véhicule est à l’arrêt.
IN_TRANSIT_TO	Le véhicule a quitté l’arrêt précédent et est en transit.

enum CongestionLevel¶

Niveau de congestion qui affecte ce véhicule.

Valeurs

Valeur
UNKNOWN_CONGESTION_LEVEL
RUNNING_SMOOTHLY
STOP_AND_GO
CONGESTION
SEVERE_CONGESTION

enum OccupancyStatus¶

L’état d’occupation des passagers du véhicule ou du transport.

Les producteurs individuels ne peuvent pas publier toutes les valeurs OccupancyStatus. Par conséquent, les consommateurs ne doivent pas supposer que les valeurs OccupancyStatus suivent une échelle linéaire. Les consommateurs doivent représenter les valeurs OccupancyStatus comme l’état indiqué et prévu par le producteur. De même, les producteurs doivent utiliser des valeurs OccupancyStatus qui correspondent aux états d’occupation réels des véhicules.

Pour décrire les niveaux d’occupation des passagers sur une échelle linéaire, voir occupancy_percentage.

Attention : ce champ est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.

Valeurs

Valeur	Commentaire
EMPTY	Le véhicule est considéré comme vide par la plupart des mesures et a peu ou pas de passagers à bord, mais accepte toujours des passagers.
MANY_SEATS_AVAILABLE	Le véhicule ou la voiture dispose d’un grand nombre de places disponibles. Le nombre de places gratuites sur le total des places disponibles pour être considéré comme suffisamment important pour entrer dans cette catégorie est déterminé à la discrétion du producteur.
FEW_SEATS_AVAILABLE	Le véhicule ou la voiture dispose d’un petit nombre de places disponibles. Le nombre de places gratuites sur le total des places disponibles pour être considéré comme suffisamment petit pour entrer dans cette catégorie est déterminé à la discrétion du producteur.
STANDING_ROOM_ONLY	Le véhicule ou la voiture ne peut actuellement accueillir que des passagers debout.
CRUSHED_STANDING_ROOM_ONLY	Le véhicule ou la voiture ne peut actuellement accueillir que des passagers debout et dispose d’un espace limité pour eux.
FULL	Le véhicule est considéré comme plein selon la plupart des mesures, mais il se peut qu’il permette toujours aux passagers de monter à bord.
NOT_ACCEPTING_PASSENGERS	Le véhicule ou la voiture n’accepte pas de passagers. Le véhicule ou la voiture accepte généralement des passagers pour l’embarquement.
NO_DATA_AVAILABLE	Le véhicule ou la voiture ne dispose d’aucune donnée d’occupation disponible à ce moment-là.
NOT_BOARDABLE	Le véhicule ou la calèche n’est pas embarquable et n’accepte jamais de passagers. Utile pour les véhicules ou chariots spéciaux (moteur, chariot de maintenance, etc…).

message CarriageDetails¶

Détails spécifiques au chariot, utilisés pour les véhicules composés de plusieurs wagons.

Attention : ce message est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
id	string	Optionnel	Un	Identification du chariot. Doit être unique par véhicule. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
label	string	Optionnel	Un	Étiquette visible par l’utilisateur qui peut être montrée au passager pour aider à identifier le transport. Exemple : "7712", "Voiture ABC-32", etc... Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
occupancy_status	OccupancyStatus	Optionnel	Un	Statut d’occupation pour ce transport donné, dans ce véhicule. La valeur par défaut est `NO_DATA_AVAILABLE`. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
occupancy_percentage	int32	Optionnel	Un	Pourcentage d’occupation pour ce transport donné, dans ce véhicule. Suit les mêmes règles que "VehiclePosition.occupancy_percentage". Utilisez-1 au cas où les données ne seraient pas disponibles pour ce transport donné. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
carriage_sequence	uint32	Requis	Un	Identifie l’ordre de ce transport par rapport aux autres wagons dans la liste CarriageStatus du véhicule. Le premier chariot dans le sens de déplacement doit avoir la valeur 1. La deuxième valeur correspond au deuxième chariot dans le sens de déplacement et doit avoir la valeur 2, et ainsi de suite. Par exemple, le premier chariot dans le sens du déplacement a une valeur de 1. Si le deuxième chariot dans le sens du déplacement a une valeur de 3, les consommateurs ignoreront les données de tous les chariots (c’est-à-dire le champ multi_carriage_details). Les chariots sans données doivent être représentés avec un numéro de séquence de transport valide et les champs sans données doivent être omis (alternativement, ces champs pourraient également être inclus et définis sur les valeurs « pas de données »). Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message Alert¶

Une alerte, indiquant une sorte d’incident dans le réseau de transport en commun.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
active_period	TimeRange	Optionnel	Plusieurs	Heure à laquelle l’alerte doit être affichée à l'utilisateur. En cas d’absence, l’alerte sera affichée tant qu’elle apparaîtra dans le flux. Si plusieurs plages sont données, l’alerte sera affichée pendant chacune d’elles.
informed_entity	EntitySelector	Requis	Plusieurs	Entités dont nous devons informer les utilisateurs de cette alerte. Au moins une entité informée doit être fournie.
cause	Cause	Requis sous condition	Un	Si cause_detail est inclus, alors Cause doit également être inclus.
cause_detail	TranslatedString	Optionnel	Un	Description de la cause de l’alerte qui permet d’utiliser un langage spécifique à l’agence ; plus spécifique que la Cause. Si cause_detail est inclus, alors Cause doit également être inclus. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
effect	Effect	Requis sous condition	Un	Si effect_detail est inclus, alors Effect doit également être inclus.
effect_detail	TranslatedString	Optionnel	Un	Description de l’effet de l’alerte qui permet d’utiliser un langage spécifique à l’agence ; plus spécifique que l’effet. Si effect_detail est inclus, alors Effect doit également être inclus. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
url	TranslatedString	Optionnel	Un	L’URL qui fournit des informations supplémentaires sur l’alerte.
header_text	TranslatedString	Requis	Un	En-tête de l’alerte. Cette string de texte brut sera mise en évidence, par exemple en gras.
description_text	TranslatedString	Requis	Un	Description de l’alerte. Cette string de texte brut sera formatée comme le corps de l’alerte (ou affichée sur une demande "d’expansion" explicite de l'utilisateur). Les informations contenues dans la description doivent s’ajouter aux informations de l’en-tête.
tts_header_text	TranslatedString	Optionnel	Un	Text contenant l’en-tête de l’alerte à utiliser pour les implémentations de synthèse vocale. Ce champ est la version synthèse vocale de header_text. Il doit contenir les mêmes informations que header_text mais formaté de manière à pouvoir être lu sous forme de synthèse vocale (par exemple, les abréviations supprimées, les chiffres épelés, etc.)
tts_description_text	TranslatedString	Optionnel	Un	Text contenant une description de l’alerte à utiliser pour les implémentations de synthèse vocale. Ce champ est la version synthèse vocale de description_text. Il doit contenir les mêmes informations que description_text mais formaté de manière à pouvoir être lu sous forme de synthèse vocale (par exemple, les abréviations supprimées, les chiffres épelés, etc.)
severity_level	SeverityLevel	Optionnel	Un	Gravité de l’alerte.
image	TranslatedImage	Optionnel	Un	TranslatedImage à afficher avec le texte de l’alerte. Utilisé pour expliquer visuellement l’effet d’alerte d’un détour, d’une fermeture de gare, etc. L’image doit améliorer la compréhension de l’alerte et ne doit pas être le seul emplacement d’informations essentielles. Les types d’images suivants sont déconseillés : image contenant principalement du texte, images marketing ou de marque n’ajoutant aucune information supplémentaire. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
image_alternative_text	TranslatedString	Optionnel	Un	Text décrivant l’apparence de l’image liée dans le champ « `image` » (par exemple, dans le cas où l’image ne peut pas être affichée ou si l'utilisateur ne peut pas voir l’image pour des raisons d’accessibilité). Voir le HTML spécification pour le texte de l’image alternative. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

enum Cause¶

Cause de cette alerte.

Valeurs

Valeur
UNKNOWN_CAUSE
OTHER_CAUSE
TECHNICAL_PROBLEM
STRIKE
DEMONSTRATION
ACCIDENT
HOLIDAY
WEATHER
MAINTENANCE
CONSTRUCTION
POLICE_ACTIVITY
MEDICAL_EMERGENCY

enum Effect¶

L’effet de ce problème sur l’entité affectée.

Valeurs

Valeur
NO_SERVICE
REDUCED_SERVICE
SIGNIFICANT_DELAYS
DETOUR
ADDITIONAL_SERVICE
MODIFIED_SERVICE
OTHER_EFFECT
UNKNOWN_EFFECT
STOP_MOVED
NO_EFFECT
ACCESSIBILITY_ISSUE

enum SeverityLevel¶

La gravité de l’alerte.

Attention : ce champ est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.

Valeurs

Valeur
UNKNOWN_SEVERITY
INFO
WARNING
SEVERE

message TimeRange¶

Un intervalle de temps. L’intervalle est considéré comme actif à l’instant t si t est supérieur ou égal à l’heure de début et inférieur à l’heure de fin.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
start	uint64	Requis sous condition	Un	Heure de début, en heure POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). S’il est manquant, l’intervalle commence à moins l’infini. Si un TimeRange est fourni, le début ou la fin doivent être fournis- les deux champs ne peuvent pas être vides.
end	uint64	Requis sous condition	Un	Heure de fin, en heure POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). S’il est manquant, l’intervalle se termine à plus l’infini. Si un TimeRange est fourni, le début ou la fin doivent être fournis- les deux champs ne peuvent pas être vides.

message Position¶

Une position géographique d’un véhicule.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
latitude	float	Requis	Un	Degrés Nord, dans le système de coordonnées WGS-84.
longitude	float	Requis	Un	Degrés Est, dans le système de coordonnées WGS-84.
bearing	float	Optionnel	Un	Orientation, en degrés, dans le sens des aiguilles d’une montre à partir du nord géographique, c’est-à-dire que 0 correspond au nord et 90 à l’est. Il peut s’agir du relèvement de la boussole ou de la direction vers le prochain arrêt ou emplacement intermédiaire. Cela ne doit pas être déduit de la séquence des positions précédentes, que les clients peuvent calculer à partir des données précédentes.
odometer	double	Optionnel	Un	Valeur du compteur kilométrique, en mètres.
speed	float	Optionnel	Un	Vitesse momentanée mesurée par le véhicule, en mètres par seconde.

message TripDescriptor¶

Un descripteur qui identifie une instance unique d’un voyage GTFS.

Pour spécifier une seule instance de voyage, dans de nombreux cas, un trip_id à lui seul suffit. Cependant, les cas suivants nécessitent des informations supplémentaires pour être résolus en une seule instance de voyage :

Pour les voyages définis dans le frequencies.txt, start_date et start_time sont requis en plus de trip_id
Si le voyage dure plus de 24 heures, ou est retardé de telle sorte qu’il entre en collision avec un voyage prévu le jour suivant, alors start_date est requis en plus de trip_id
Si le champ trip_id ne peut pas être fourni, alors route_id, direction_id, start_date et start_time doivent tous être fournis

Dans tous les cas, si route_id est fourni en plus de trip_id, alors route_id doit être le même route_id que celui attribué au voyage donné dans GTFS trips.txt.

Le champ trip_id ne peut pas, seul ou en combinaison avec d’autres champs TripDescriptor, être utilisé pour identifier plusieurs instances de voyage. Par exemple, un TripDescriptor ne doit jamais spécifier trip_id par lui-même pour les trajets GTFS frequencies.txt exact_times=0, car start_time est également requis pour résoudre une seule instance de trajet commençant à une heure spécifique de la journée. Si le TripDescriptor ne se résout pas en une seule instance de voyage (c’est-à-dire s’il se résout en zéro ou en plusieurs instances de voyage), cela est considéré comme une erreur et l’entité contenant le TripDescriptor erroné peut être rejetée par les consommateurs.

Notez que si le trip_id n’est pas connu, alors les identifiants de séquence de stations dans TripUpdate ne sont pas suffisants et les stop_ids doivent également être fournis. De plus, les heures absolues d’arrivée/départ doivent être fournies.

TripDescriptor.route_id ne peut pas être utilisé dans un Alert EntitySelector pour spécifier une alerte à l’échelle de l’itinéraire qui affecte tous les trajets d’un itinéraire- utilisez EntitySelector.route_id à la place.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
trip_id	string	Requis sous condition	Un	Le trip_id du flux GTFS auquel ce sélecteur fait référence. Pour les déplacements non basés sur la fréquence (trajets non définis dans GTFS frequencies.txt), ce champ suffit à identifier de manière unique le déplacement. Pour les trajets basés sur la fréquence définis dans GTFS frequencies.txt, trip_id, start_time et start_date sont tous requis. Pour les trajets planifiés (trajets non définis dans GTFS frequencies.txt), trip_id ne peut être omis que si le trajet peut être identifié de manière unique par une combinaison de route_id, direction_id, start_time et start_date, et que tous ces champs sont fournis. Lorsque Schedule_relationship est DUPLICATED dans un TripUpdate, le trip_id identifie le voyage à partir du GTFS statique à dupliquer. Lorsque Schedule_relationship est DUPLICATED dans un VehiclePosition, le trip_id identifie le nouveau voyage en double et doit contenir la valeur du TripUpdate correspondant. TripProperties.trip_id.
route_id	string	Requis sous condition	Un	Le route_id du GTFS auquel ce sélecteur fait référence. Si trip_id est omis, route_id, direction_id, start_time et planning_relationship=SCHEDULED doivent tous être définis pour identifier une instance de voyage. TripDescriptor.route_id ne doit pas être utilisé dans un Alert EntitySelector pour spécifier une alerte à l’échelle de l’itinéraire qui affecte tous les trajets d’un itinéraire- utilisez EntitySelector.route_id à la place.
direction_id	uint32	Requis sous condition	Un	Le direction_id du fichier trips.txt du flux GTFS, indiquant la direction du déplacement pour les trajets auxquels ce sélecteur fait référence. Si trip_id est omis, direction_id doit être fourni. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
start_time	string	Requis sous condition	Un	Heure de début initialement prévue de cette instance de voyage. Lorsque le trip_id correspond à un voyage non basé sur la fréquence, ce champ doit être omis ou être égal à la valeur du flux GTFS. Lorsque le trip_id correspond à un trajet basé sur la fréquence défini dans GTFS frequencies.txt, start_time est requis et doit être spécifié pour les mises à jour du trajet et les positions des véhicules. Si le trajet correspond à l’enregistrement GTFS exact_times=1, alors start_time doit être un multiple (y compris zéro) de headway_secs après frequencies.txt start_time pour la période correspondante. Si le trajet correspond à exact_times=0, alors son heure de début peut être arbitraire et devrait initialement être le premier départ du voyage. Une fois établi, le start_time de ce trajet exact_times=0 basé sur la fréquence doit être considéré comme immuable, même si la première heure de départ change- ce changement d’heure peut plutôt être reflété dans un StopTimeUpdate. Si trip_id est omis, start_time doit être fourni. Le format et la sémantique du champ sont les mêmes que ceux de GTFS/frequencies.txt/start_time, par exemple 11:15:35 ou 25:15:35.
start_date	string	Requis sous condition	Un	La date de début de cette instance de voyage au format AAAAMMJJ. Pour les trajets programmés (trajets non définis dans GTFS frequencies.txt), ce champ doit être fourni pour lever l’ambiguïté des trajets qui sont si tardifs qu’ils entrent en collision avec un trajet programmé le jour suivant. Par exemple, pour un train qui part à 8h00 et à 20h00 tous les jours et qui a 12 heures de retard, il y aurait deux trajets distincts à la même heure. Ce champ peut être fourni mais n’est pas obligatoire pour les horaires dans lesquels de telles collisions sont impossibles- par exemple, un service fonctionnant selon un horaire horaire où un véhicule en retard d’une heure n’est plus considéré comme étant lié à l’horaire. Ce champ est obligatoire pour les trajets basés sur la fréquence définis dans GTFS frequencies.txt. Si trip_id est omis, start_date doit être fourni.
schedule_relationship	ScheduleRelationship	Optionnel	Un	La relation entre ce déplacement et l’horaire statique. Si TripDescriptor est fourni dans une alerte `EntitySelector`, le champ `schedule_relationship` est ignoré par les consommateurs lors de l’identification de l’instance de voyage correspondante.
modified_trip	ModifiedTripSelector	Optionnel	Un	Lien vers toutes les modifications apportées à ce voyage (changements de forme, suppression ou ajout d’arrêts). Si ce champ est fourni, les champs `trip_id`, `route_id`, `direction_id`, `start_time`, `start_date` de `TripDescriptor` DOIVENT être laissés vides, pour éviter toute confusion chez les consommateurs qui ne recherchent pas la valeur `ModifiedTripSelector`.

enum ScheduleRelationship¶

La relation entre ce trajet et l’horaire statique. Si un voyage est effectué conformément à un horaire temporaire, non reflété dans GTFS, il ne doit pas être marqué comme PLANIFIÉ, mais comme AJOUTÉ.

Valeurs

Valeur	Commentaire
SCHEDULED	Voyage qui se déroule conformément à son horaire GTFS ou qui est suffisamment proche du voyage planifié pour y être associé.
ADDED	Un trajet supplémentaire qui a été ajouté en plus d’un horaire de course, par exemple pour remplacer un véhicule en panne ou pour répondre à un afflux soudain de passagers. REMARQUE : actuellement, le comportement n’est pas spécifié pour les flux qui utilisent ce mode. Il y a des discussions sur le GTFS GitHub (1) (2) (3) autour de la spécification complète ou de la dépréciation des voyages AJOUTÉS et la documentation sera mise à jour lorsque ces discussions seront finalisées.
UNSCHEDULED	Un voyage en cours sans horaire associé - cette valeur est utilisée pour identifier les voyages définis dans GTFS frequencies.txt avec exact_times = 0. Elle ne doit pas être utilisée pour décrire des voyages non définis dans GTFS frequencies.txt ou des voyages dans GTFS. frequencies.txt avec exact_times = 1. Les trajets avec `schedule_relationship: UNSCHEDULED` doivent également définir toutes les StopTimeUpdates `schedule_relationship: UNSCHEDULED`
CANCELED	Un voyage qui existait dans le planning mais qui a été supprimé.
DUPLICATED	Un nouveau trajet identique à un trajet programmé existant, à l’exception de la date et de l’heure de début du service. Utilisé avec `TripUpdate.TripProperties.trip_id`, `TripUpdate.TripProperties.start_date` et `TripUpdate.TripProperties.start_time` pour copier un voyage existant à partir de GTFS statique mais commencer à une date et/ou une heure de service différente. La duplication d’un voyage est autorisée si le service lié au voyage d’origine au format (CSV) GTFS (dans `calendar.txt` ou `calendar_dates.txt`) fonctionne dans les 30 prochains jours. Le voyage à dupliquer est identifié via `TripUpdate.TripDescriptor.trip_id`. Cette énumération ne modifie pas le voyage existant référencé par `TripUpdate.TripDescriptor.trip_id` - si un producteur souhaite annuler le voyage d’origine, il doit publier un `TripUpdate` séparé avec la valeur CANCELED. Les trajets définis dans GTFS `frequencies.txt` avec `exact_times` vide ou égal à `0` ne peuvent pas être dupliqués. Le `VehiclePosition.TripDescriptor.trip_id` pour le nouveau voyage doit contenir la valeur correspondante de `TripUpdate.TripProperties.trip_id` et `VehiclePosition.TripDescriptor.ScheduleRelationship` doit également être défini sur `DUPLICATED`. Les producteurs et consommateurs existants qui utilisaient l’énumération ADDED pour représenter les voyages en double doivent suivre le guide de migration pour passer à l’énumération DUPLICATED.
DELETED	Un trajet qui existait dans le planning mais qui a été supprimé et qui ne doit pas être montré aux utilisateurs. DELETED doit être utilisé au lieu de CANCELED pour indiquer qu’un fournisseur de transport souhaite supprimer entièrement les informations sur le trajet correspondant des applications consommatrices, afin que le trajet ne soit pas affiché comme annulé aux usagers, par exemple un trajet qui est entièrement remplacé par un autre trajet. Cette désignation devient particulièrement importante si plusieurs voyages sont annulés et remplacés par un service de substitution. Si les consommateurs devaient afficher des informations explicites sur les annulations, cela les détournerait des prévisions en temps réel les plus importantes. Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message ModifiedTripSelector¶

Lorsqu’un service est affecté par une modification de trajet, ModifiedTripSelector est utilisé pour sélectionner un trajet. Plus de détails dans la spécification Trip Modification.

Valeurs

Nom de champ	Type	Requis	Cardinalité	Description
modifications_id	string	Requis	Un	L’ `id` de l’ `FeedEntity` dans laquelle l’objet `TripModifications` contenu affecte ce voyage.
affected_trip_id	string	Requis	Un	Le `trip_id` du flux GTFS modifié par le `modifications_id`
start_time	string	Optionnel	Un	L’heure de début initialement prévue de cette instance de voyage, appliquée au voyage modifié qui est basé sur la fréquence. Même définition que start_time dans TripDescriptor.
start_date	string	Optionnel	Un	Date de début de cette instance de voyage au format AAAAMMJJ, appliquée au voyage modifié. Même définition que start_date dans TripDescriptor.

message VehicleDescriptor¶

Informations d’identification du véhicule effectuant le trajet.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
id	string	Optionnel	Un	Identification du système interne du véhicule. Doit être unique par véhicule et est utilisé pour suivre le véhicule à mesure qu’il progresse dans le système. Cet identifiant ne doit pas être rendu visible à l’utilisateur final ; utilisez pour cela le champ label
label	string	Optionnel	Un	Étiquette visible par l’utilisateur, c’est-à-dire quelque chose qui doit être montré au passager pour l’aider à identifier le bon véhicule.
license_plate	string	Optionnel	Un	La plaque d’immatriculation du véhicule.
wheelchair_accessible	WheelchairAccessible	Optionnel	Un	Si fourni, peut écraser la valeur wheelchair_accessible du GTFS statique.

enum WheelchairAccessible¶

Si un trajet particulier est accessible aux fauteuils roulants. Lorsqu’elle est disponible, cette valeur doit remplacer la valeur wheelchair_accessible du GTFS statique.

Valeurs¶

Valeur	Commentaire
NO_VALUE	Le voyage ne contient aucune information sur l’accessibilité en fauteuil roulant. Ceci est le comportement par défaut. Si le GTFS statique contient une valeur wheelchair_accessible, elle ne sera pas écrasée.
UNKNOWN	Le voyage n’a aucune valeur d’accessibilité présente. Cette valeur écrasera la valeur du GTFS.
FAUTEUIL ROULANT_ACCESSIBLE	Le voyage est accessible aux fauteuils roulants. Cette valeur écrasera la valeur du GTFS.
WHEELCHAIR_INACCESSIBLE	Le voyage n’est pas accessible aux fauteuils roulants. Cette valeur écrasera la valeur du GTFS.

message EntitySelector¶

Un sélecteur pour une entité dans un flux GTFS. Les valeurs des champs doivent correspondre aux champs appropriés dans le flux GTFS. Au moins un spécificateur doit être indiqué. Si plusieurs sont donnés, ils doivent être interprétés comme étant joints par l’opérateur logique « ET ». De plus, la combinaison de spécificateurs doit correspondre aux informations correspondantes dans le flux GTFS. En d’autres termes, pour qu’une alerte s’applique à une entité dans GTFS, elle doit correspondre à tous les champs EntitySelector fournis. Par exemple, un EntitySelector qui inclut les champs route_id: "5" et route_type: "3" s’applique uniquement au bus route_id: "5" - il ne s’applique à aucune autre route de route_type: "3". Si un producteur souhaite qu’une alerte s’applique à route_id: "5" ainsi qu’à route_type: "3", il doit fournir deux EntitySelectors distincts, l’un faisant référence à route_id: "5" et l’autre faisant référence à route_type: "3""’.

Au moins un spécificateur doit être donné - tous les champs d’un EntitySelector ne peuvent pas être vides.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
agency_id	string	Requis sous condition	Un	L’id_agence du flux GTFS auquel ce sélecteur fait référence.
route_id	string	Requis sous condition	Un	Le route_id du GTFS auquel ce sélecteur fait référence. Si direction_id est fourni, route_id doit également être fourni.
route_type	int32	Requis sous condition	Un	Le route_type du GTFS auquel ce sélecteur fait référence.
direction_id	uint32	Requis sous condition	Un	Le direction_id du fichier trips.txt du flux GTFS, utilisé pour sélectionner tous les trajets dans une direction pour un itinéraire, spécifié par route_id. Si direction_id est fourni, route_id doit également être fourni. Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
trip	TripDescriptor	Requis sous condition	Un	Instance de voyage du GTFS à laquelle ce sélecteur fait référence. Ce TripDescriptor doit se résoudre à une seule instance de voyage dans les données GTFS (par exemple, un producteur ne peut pas fournir uniquement un trip_id pour exact_times=0 voyages). Si le champ ScheduleRelationship est renseigné dans ce TripDescriptor, il sera ignoré par les consommateurs lorsqu’ils tenteront d’identifier le voyage GTFS.
stop_id	string	Requis sous condition	Un	Le stop_id du flux GTFS auquel ce sélecteur fait référence.

message TranslatedString¶

Un message internationalisé contenant des versions par langue d’un extrait de texte ou d’une URL. L’une des chaînes d’un message sera récupérée. La résolution se déroule comme suit : Si la langue de l’interface utilisateur correspond au code de langue d’une traduction, la première traduction correspondante est sélectionnée. Si une langue par défaut de l’interface utilisateur (par exemple l’anglais) correspond au code de langue d’une traduction, la première traduction correspondante est sélectionnée. Si une traduction a un code de langue non spécifié, cette traduction est sélectionnée.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
translation	Traduction	Requis	Plusieurs	Au moins une traduction doit être fournie.

message Translation¶

Une string localisée mappée à une langue.

Nom du champ	Tapez	Requis	Cardinalité	Description
text	string	Requis	Un	Une string UTF-8 contenant le message.
language	string	Requis sous condition	Un	Code de langue BCP-47. Peut être omis si la langue est inconnue ou si aucune internationalisation n’est effectuée pour le flux. Au plus une traduction peut avoir une balise de langue non spécifiée- s’il y a plus d’une traduction, la langue doit être fournie.

message TranslatedImage¶

Un message internationalisé contenant des versions par langue d’une image. L’une des images d’un message sera récupérée. La résolution se déroule comme suit : Si la langue de l’interface utilisateur correspond au code de langue d’une traduction, la première traduction correspondante est sélectionnée. Si une langue par défaut de l’interface utilisateur (par exemple l’anglais) correspond au code de langue d’une traduction, la première traduction correspondante est sélectionnée. Si une traduction a un code de langue non spécifié, cette traduction est sélectionnée.

Attention : ce message est encore expérimental et sujet à changement. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
localized_image	LocalizedImage	Requis	Plusieurs	Au moins une image localisée doit être fournie.

message LocalizedImage¶

Une URL d’image localisée mappée à une langue.

Nom du champ	Tapez	Requis	Cardinalité	Description
url	string	Requis	Un	Chaîne contenant une URL renvoyant vers une image. L’image liée doit faire moins de 2 Mo. Si une image change de manière suffisamment significative pour qu’une mise à jour soit nécessaire du côté du application réutilisatrice, le producteur doit mettre à jour l’URL vers une nouvelle. L’URL doit être une URL complète incluant http://ou https://, et tous les caractères spéciaux de l’URL doivent être correctement échappés. Consultez le site http://www.w3.org/Addressing/URL/4_URI_Recommentations.html suivant pour une description de la façon de créer des valeurs d’URL complètes.
media_type	string	Requis	Un	Type de média IANA pour spécifier le type d’image à afficher. Le type doit commencer par "image/"
language	string	Requis sous condition	Un	Code de langue BCP-47. Peut être omis si la langue est inconnue ou si aucune internationalisation n’est effectuée pour le flux. Au plus une traduction peut avoir une balise de langue non spécifiée- s’il y a plus d’une traduction, la langue doit être fournie.

message Shape¶

Décrit le chemin physique qu’emprunte un véhicule lorsque la forme ne fait pas partie du GTFS (CSV), comme pour un détour ad hoc. Les Tracé des lignes appartiennent à trajets et consistent en une polyligne codée pour une transmission plus efficace. Les Tracé des lignes n’ont pas besoin d’intercepter exactement l’emplacement des arrêts, mais tous les arrêts d’un trajet doivent se trouver à une petite distance de la forme pour ce trajet, c’est-à-dire à proximité des segments de ligne droite reliant les points de la forme.

Attention : ce message est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
shape_id	string	Requis	Un	Identificateur de la forme. Doit être différent de tout « `shape_id` » défini dans le GTFS (CSV). Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.
encoded_polyline	string	Requis	Un	Représentation polyligne codée de la forme. Cette polyligne doit contenir au moins deux points. Pour plus d’informations sur les polylignes codées, consultez https://developers.google.com/maps/documentation/utilities/polylinealgorithm Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

message Stop¶

Représente un nouveau Stop ajouté dynamiquement au flux. Tous les champs sont tels que décrits dans la spécification (CSV) GTFS. Le type d’emplacement du nouvel arrêt est « 0 » (arrêt routable).

Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
stop_id	string	Requis	Un	Identifiant de l’arrêt. Doit être différent de tout « `stop_id` » défini dans le GTFS (CSV).
stop_code	TranslatedString	Optionnel	Un	Voir la définition de stops.stop_code dans (CSV) GTFS.
stop_name	TranslatedString	Requis	Un	Voir la définition de stops.stop_name dans (CSV) GTFS.
tts_stop_name	TranslatedString	Optionnel	Un	Voir la définition de stops.tts_stop_name dans (CSV) GTFS.
stop_desc	TranslatedString	Optionnel	Un	Voir la définition de stops.stop_desc dans (CSV) GTFS.
stop_lat	float	Requis	Un	Voir la définition de stops.stop_lat dans (CSV) GTFS.
stop_lon	float	Requis	Un	Voir la définition de stops.stop_lon dans (CSV) GTFS.
zone_id	string	Optionnel	Un	Voir la définition de stops.zone_id dans (CSV) GTFS.
stop_url	TranslatedString	Optionnel	Un	Voir la définition de stops.stop_url dans (CSV) GTFS.
parent_station	string	Optionnel	Un	Voir la définition de stops.parent_station dans (CSV) GTFS.
stop_timezone	string	Optionnel	Un	Voir la définition de stops.stop_timezone dans (CSV) GTFS.
wheelchair_boarding	WheelchairBoarding	Optionnel	Un	Voir la définition de stops.wheelchair_boarding dans (CSV) GTFS.
level_id	string	Optionnel	Un	Voir la définition de stops.level_id dans (CSV) GTFS.
platform_code	TranslatedString	Optionnel	Un	Voir la définition de stops.platform_code dans (CSV) GTFS.

enum WheelchairBoarding¶

Valeurs

Valeur	Commentaire
UNKNOWN	Aucune information d’accessibilité pour l’arrêt.
AVAILABLE	Certains véhicules à cet arrêt peuvent être embarqués par un passager en fauteuil roulant.
NOT_AVAILABLE	L’embarquement en fauteuil roulant n’est pas possible à cet arrêt.

message TripModifications¶

Un message TripModifications identifie une liste de trajets similaires qui sont tous concernés par des modifications particulières, comme un détour.

Attention : ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

En savoir plus sur les modifications de voyage...

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
selected_trips	SelectedTrips	Requis	Plusieurs	Une liste des voyages sélectionnés affectés par ce TripModifications. Doit contenir au moins un «SelectedTrips». Si la valeur `start_times` est définie, un maximum d’un `SelectedTrips` avec un trip_id peut être répertorié.
start_times	string	Optionnel	Plusieurs	Une liste des heures de début dans le descripteur de trajet en temps réel pour le trip_id défini dans trip_ids. Utile pour cibler plusieurs départs d’un trip_id dans un voyage basé sur la fréquence.
service_dates	string	Requis	Plusieurs	Dates auxquelles intervient la modification, au format AAAAMMJJ. Un trip_id ne sera modifié que s’il fonctionne à une date de service donnée ; le voyage N’EST PAS tenu d’avoir lieu à toutes les dates de service. Les producteurs DEVRAIT transmettre uniquement les détours ayant lieu au cours de la semaine suivante. Les dates fournies ne doivent pas être utilisées comme informations destinées à l’utilisateur. Si une date de début et de fin destinée à l’utilisateur doit être fournie, elles peuvent être fournies dans l’alerte de service liée avec `service_alert_id`
modifications	Modification	Requis	Plusieurs	Une liste des modifications à appliquer aux voyages concernés.

message Modification¶

Un message Modification décrit les modifications apportées à chaque trajet affecté à partir de start_stop_selector.

Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Un exemple montrant l’effet d’une modification sur un voyage particulier. Cette modification pourra également s’appliquer à plusieurs autres déplacements.

Les délais de détour propagés affectent tous les arrêts suivant la fin d’une modification. Si un trajet comporte plusieurs modifications, les retards se cumulent.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
start_stop_selector	StopSelector	Requis	Un	Le sélecteur d’arrêt du premier arrêt du trajet d’origine qui doit être affecté par cette modification. Utilisé en conjonction avec `end_stop_selector`. `start_stop_selector` est requis et est utilisé pour définir l’arrêt de référence utilisé avec `travel_time_to_stop`. Voir `travel_time_to_stop` pour plus de détails
end_stop_selector	StopSelector	Requis sous condition	Un	Le sélecteur d’arrêt du dernier arrêt du trajet d’origine qui doit être affecté par cette modification. La sélection est inclusive, donc si un seul stop_time est remplacé par cette modification, `start_stop_selector` et `end_stop_selector` doivent être équivalents. Si aucun stop_time n’est remplacé, `end_stop_selector` ne doit pas être fourni. C’est par ailleurs obligatoire.
propagated_modification_delay	int32	Optionnel	Un	Le nombre de secondes de retard à ajouter à toutes les heures de départ et d’arrivée postérieures au dernier arrêt inséré par une modification. Si une modification affecte uniquement la forme (c’est-à-dire que ni `end_stop_selector` ni `replacement_stops` ne sont fournis), alors la propagation du retard commence à l’arrêt suivant après `start_stop_selector`. Peut être un nombre positif ou négatif. Si plusieurs modifications s’appliquent à un même voyage, les retards s’accumulent au fur et à mesure que le voyage avance. Si la valeur n’est pas fournie, les consommateurs PEUT interpoler ou déduire le « propagated_modification_delay » sur la base d’autres données.
replacement_stops	ReplacementStop	Optionnel	Plusieurs	Une liste d’arrêts de remplacement, remplaçant ceux du voyage d’origine. La durée des nouveaux horaires d’arrêts peut être inférieure, identique ou supérieure au nombre de horaires d’arrêts remplacés.
service_alert_id	string	Optionnel	Un	Une valeur « `id` » du message « `FeedEntity` » qui contient l ’« `Alert` » décrivant cette Modification pour la communication destinée à l’utilisateur.
last_modified_time	uint64	Optionnel	Un	Cet horodatage identifie le moment où la modification a été modifiée pour la dernière fois. En temps POSIX (c’est-à-dire nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC).

message StopSelector¶

Sélecteur d’un arrêt. Soit par stop_id ou stop_sequence. Au moins une des deux valeurs doit être fournie.

Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
stop_sequence	uint32	Requis sous condition	Un	Doit être le même que dans stop_times.txt dans le flux GTFS correspondant. Soit `stop_sequence` ou `stop_id` doivent être fournis dans un `StopSelector` - les deux champs ne peuvent pas être vides. `stop_sequence` est requis pour les trajets qui visitent le même stop_id plus d’une fois (par exemple, une boucle) pour lever l’ambiguïté à quel arrêt la prédiction est destinée.
stop_id	string	Requis sous condition	Un	Doit être le même que dans le fichier stops.txt du flux GTFS correspondant. Soit `stop_sequence` ou `stop_id` doivent être fournis dans un `StopSelector` - les deux champs ne peuvent pas être vides.

message SelectedTrips¶

Liste des trajets sélectionnés avec une forme associée.

Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
trip_ids	uint32	Plusieurs	Un	Une liste des trip_id du GTFS d’origine (CSV) qui sont affectés par le remplacement contenant. Doit contenir au moins un trip_id.
shape_id	string	Requis	Un	ID de la nouvelle forme pour les trajets modifiés dans ce SelectedTrips. Peut faire référence à une nouvelle forme ajoutée à l’aide d’un message GTFS-RT Shape ou à une forme existante définie dans le fichier shapes.txt du flux GTFS-Static.

message ReplacementStop¶

Chaque message ReplacementStop définit un arrêt qui sera désormais visité par le voyage, et spécifie éventuellement le temps de trajet estimé jusqu’à l’arrêt.

Attention :ce champ est encore expérimental et est susceptible de changer. Il pourrait être formellement adopté à l’avenir.

Si une modification affecte le premier arrêt du trajet, cet arrêt sert également d’arrêt de référence de la modification.

Champs

Nom du champ	Tapez	Requis	Cardinalité	Description
stop_id	string	Requis	Un	L’identifiant de l’arrêt de remplacement qui sera désormais visité par le voyage. Peut faire référence à un nouvel arrêt ajouté à l’aide d’un message`Stop` GTFS-RT, ou à un arrêt existant défini dans le `stops.txt` du flux GTFS (CSV). L’arrêt DOIT avoir `location_type=0` (arrêts routables).
travel_time_to_stop	int32	Optionnel	Un	La différence en secondes entre l’heure d’arrivée à cet arrêt et l’heure d’arrivée à l’arrêt de référence. L’arrêt de référence est l’arrêt précédant `start_stop_selector`. Si la modification commence au premier arrêt du trajet, alors le premier arrêt du trajet est l’arrêt de référence. Cette valeur DOIT être croissante de manière monotone et ne peut être qu’un nombre négatif si le premier arrêt du trajet d’origine est l’arrêt de référence. Si la valeur n’est pas fournie, les consommateurs PEUT interpoler ou déduire le « travel_time_to_stop » sur la base d’autres données.