Référence GTFS Realtime¶
Un flux GTFS Realtime permet aux organismes de transport en commun de fournir aux consommateurs des informations en temps réel sur les perturbations de leur service (stations fermées, lignes non exploitées, retards importants, etc.), la localisation de leurs véhicules et les heures d'arrival prévues.
La version 2.0 de la spécification des flux est discutée et documentée sur ce site. Les versions valides sont "2.0", "1.0".
Définitions des termes¶
Obligatoire¶
Dans GTFS v2.0 et plus, la colonne Required décrit les champs qui doivent être fournis par un producteur pour que les données de transit soient valides et aient un sens pour une application consommatrice.
Les valeurs suivantes sont utilisées dans le champ " Required":
- Requis: Ce champ doit être fourni par un producteur de flux GTFS.
- Conditionnellement requis: Ce champ est requis sous certaines conditions, qui sont décrites dans la description du champ. En dehors de ces conditions, le champ est facultatif.
- Facultatif: Ce champ est facultatif et n'a pas à être mis en œuvre par les producteurs. Toutefois, si les données sont disponibles dans les systèmes sous-jacents de localisation automatique des vehicle (par exemple, l'
timestamp
VehiclePosition ), 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, et donc les flux avec gtfs_realtime_version
de 1
peuvent ne pas répondre à ces exigences (voir la proposition pour les exigences sémantiques pour plus de détails).
Cardinalité¶
Lacardinalité représente le nombre d'éléments qui peuvent être fournis pour un champ particulier, avec les valeurs suivantes :
- One - Un seul élément one peut être fourni pour ce champ. Cela correspond aux cardinalités obligatoires et facultatives de Protocol Buffer.
- Many - De nombreux éléments (0, 1 ou plus) peuvent être fournis pour ce champ. Cela correspond à la cardinalité répétée du Protocol Buffer repeated cardinality.
Référez-vous toujours aux champs Required et Description pour savoir si un champ est obligatoire, obligatoire sous condition ou facultatif. Veuillez vous référer à gtfs-realtime.proto
pour la cardinalité du tampon de protocole.
Types de données de tampon de protocole¶
Les types de données de tampon de protocole suivants sont utilisés pour décrire les éléments de flux :
- message: Type complexe
- enum: Liste de valeurs fixes
Champs expérimentaux¶
Les champs étiquetés comme expérimentaux sont sujets à des modifications et n'ont pas encore été formellement adoptés dans la spécification. Un champ expérimental peut être formellement adopté à l'avenir.
Index des éléments¶
Éléments¶
message FeedMessage¶
Le contenu d'un message flux. Chaque message du flux est obtenu en tant que 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'entity sont résolus par rapport au flux GTFS.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
header | FeedHeader | Obligatoire | Un | Métadonnées concernant ce flux et ce message flux. |
entity | FeedEntity | Conditionnellement requis | Plusieurs | Contenu du flux. Si des informations entime sont disponibles pour le système de transport en commun, ce champ doit être fourni. Si ce champ est EMPTY, les consommateurs doivent supposer qu'aucune informationtime n'est disponible pour le système. |
message FeedHeader¶
Métadonnées sur un flux, incluses dans les messages de flux.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
gtfs_realtime_version | string | Obligatoire | Un | Version de la spécification du flux. La version actuelle est 2.0. |
Incrementality | Incrementality | Obligatoire | Un | |
timestamp | uint64 | Obligatoire | Un | Ce timestamp identifie le moment où le contenu de ce flux a été créé (en time serveur). En time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). Pour éviter les décalages time entre les systèmes produisant et consommant des informations en temps réel, il est fortement conseillé de dériver l'timestamp d'un serveur de time. Il est tout à fait acceptable d'utiliser des serveurs de strate 3 ou même de strate inférieure puisque des différences de time allant jusqu'à quelques secondes sont tolérables. |
enum Incrementality¶
Détermine si l'extraction actuelle est incrémentale.
- FULL_DATASET: cette mise à jour du flux écrasera toutes les informations en temps réel précédentes pour le flux. Cette mise à jour est donc censée fournir un instantané FULL de toutes les informations en temps réel connues.
- DIFFERENTIAL: actuellement, ce mode n'est pas supporté et le comportement n'est pas spécifié pour les flux qui utilisent ce mode. Des discussions sont en cours sur la GTFS Realtime mailing list Realtime concernant la spécification complète du comportement du mode DIFFERENTIAL et la documentation sera mise à jour lorsque ces discussions seront finalisées.
Valeurs
Valeur |
---|
FULL_DATASET |
DIFFERENTIAL |
message FeedEntity¶
Définition (ou mise à jour) d'une entity dans le flux de transit. Si l'entity n'est pas supprimée, un seul des champstrip_update",vehicle",Alert" etShape" doit être renseigné.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
id | string | Obligatoire | Un | Identifiant unique de flux pour cette entity. Les identifiants sont utilisés uniquement pour fournir un support d'Incrementality. 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'INFO). |
is_deleted | bool | Optionnelle | Un | Indique si cette entity doit être supprimée. Ne devrait être fourni que pour les flux avec une Incrementality de DIFFERENTIAL - ce champ ne devrait PAS être fourni pour les flux avec une Incrementality de FULL_DATASET. |
trip_update | TripUpdate | Conditionnellement requis | Un | Données sur les délais de departure en temps réel d'un trip. Au moins un des champs trip_update, vehicle, Alert, or Shape doit être fourni - tous ces champs ne peuvent pas être EMPTY. |
vehicle | VehiclePosition | Conditionnellement requis | Un | Données sur la Position en temps réel d'un vehicle. Au moins un des champs trip_update, vehicle, Alert, or Shape doit être fourni - tous ces champs ne peuvent pas être EMPTY. |
Alert | Alert | Conditionnellement requis | Un | Données relatives à l'Alert en temps réel. Au moins un des champs trip_update, vehicle, Alert, or Shape doit être fourni - tous ces champs ne peuvent pas être EMPTY. |
Shape | Shape | Conditionnellement requis | Un | Données relatives aux formes ADDED en temps réel, par exemple pour un DETOUR. Au moins un des champs trip_update, vehicle, Alert, or Shape doit être fourni - tous ces champs ne peuvent pas être EMPTY. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message TripUpdate¶
Mise à jour en temps réel de la progression d'un vehicle au cours d'un trip. Veuillez également vous reporter à la discussion générale sur les trip updates entities.
En fonction de la valeur de ScheduleRelationship, un TripUpdate peut spécifier :
- Un trip qui se déroule selon le programme.
- Un trip qui se déroule le long d'un itinéraire mais qui n'a pas d'horaire fixe.
- Un trip qui a été ADDED ou supprimé par rapport à l'horaire.
- Un nouveau trip qui est une copie d'un trip existant dans le GTFS statique. Il sera exécuté à la date et à l'time service spécifiées dans TripProperties.
Les mises à jour peuvent concerner des événements d'arrival futurs, prévus, ou des événements passés qui se sont déjà produits. Dans la plupart des cas, les informations sur les événements passés sont des valeurs mesurées, il est donc recommandé que la valeur de uncertainty 'uncertainty soit égale à 0. Si l'uncertainty 'une mise à jour est différente de 0, soit la mise à jour est une prédiction approximative pour un trip qui n'est pas terminé, soit la mesure n'est pas précise, soit la mise à jour était une prédiction pour le passé qui n'a pas été vérifiée après l'événement.
Si un vehicle dessert 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 un TripUpdate pour le trip actuellement desservi par le vehicle. Les producteurs sont encouragés à inclure des TripUpdate pour un ou plusieurs trajets après le trip actuel dans le bloc de ce vehicle si le producteur est confiant dans la qualité des prédictions pour ce(s) futur(s) trip(s). L'inclusion de plusieurs TripUpdates pour le même vehicle permet d'éviter que les usagers ne soient confrontés à des prédictions " pop-in " lorsque le vehicle passe d'un trip à l'autre et permet également aux usagers d'être informés à l'avance des retards qui ont un impact sur les trajets en aval (par exemple, lorsque le delay connu dépasse les temps de repos prévus entre les trajets).
- les entités TripUpdate respectives ne sont pas tenues d'être ADDED au flux dans l'ordre où elles sont SCHEDULED dans le bloc. Par exemple, s'il y a des trajets avec des
trip_ids
1, 2 et 3 qui appartiennent tous à un bloc, et que le vehicle effectue le trip 1, puis le trip 2, puis le trip 3, les entitéstrip_update
peuvent apparaître dans n'importe quel ordre - par exemple, l'ajout du trip 2, puis du trip 1, puis du trip 3 est autorisé.
Il est à noter que la mise à jour peut décrire un trip qui s'est déjà terminé, il suffit de fournir une mise à jour pour le dernier arrêt du trip. Si l'time 'arrival au dernier arrêt est dans le passé, le client en conclura que tout le trip est dans le passé (il est possible, bien que sans importance, de fournir également des mises à jour pour les arrêts précédents). Cette option est la plus pertinente dans le cas d'un trip qui s'est terminé plus tôt que prévu, mais trip, d'après le programme, se poursuit à l'time actuelle. En supprimant les mises à jour pour ce trip, le client pourrait croire que le trip se poursuit. Notez que le fournisseur de flux est autorisé, mais pas obligé, de purger les mises à jour passées - c'est un cas où cela serait utile en pratique.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
trip | TripDescriptor | Obligatoire | Un | Le trip auquel ce message s'applique. Il peut y avoir au maximum une entity TripUpdate pour chaque instance de trip réelle. S'il n'y en a pas, cela signifie qu'il n'y a pas d'informations de prédiction disponibles. Cela signifie pas Cela signifie que le trip se déroule conformément au programme. |
vehicle | VehicleDescriptor | Optionnelle | Un | Informations supplémentaires sur le vehicle qui dessert ce trip. |
stop_time_update | StopTimeUpdate | Conditionnellement requis | Plusieurs | Mises à jour des StopTimes pour le trip (à la fois futures, c'est-à-dire des prédictions, 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 trip jusqu'au prochain stop_time_update spécifié. Au moins une stop_time_update doit être fournie pour le trip, sauf si laschedule_relationship trip.schedule_relationship est CANCELED ou DUPLICATED - si le trip est CANCELED, aucune mise à jour stop_time_update ne doit être fournie. Si le trip est DUPLICATED, des mises à jour de stop_time_updates peuvent être fournies pour indiquer des informationstime pour le nouveau trip. |
timestamp | uint64 | Optionnelle | Un | Le moment le plus récent auquel la progressiontime du vehicle a été mesurée pour estimer les StopTimes dans le futur. Lorsque des Heures d'arrêt dans le passé sont fournies, les heures d'arrival peuvent être antérieures à cette valeur. En time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). |
delay | int32 | Optionnelle | Un | L'écart d'horaire actuel pour le trip. delay ne doit être spécifié que lorsque la prédiction est donnée par rapport à un horaire existant dans GTFS. Ledelay (en secondes) peut être positif (signifiant que le vehicle est en retard) ou négatif (signifiant que le vehicle est en avance sur l'horaire). Un delay de 0 signifie que le vehicle est exactement à l'time. Les informations dedelay dans les StopTimeUpdates prennent le pas sur les informations de delay trip, de sorte que le delay trip n'est propagé que jusqu'au prochain arrêt du trip pour lequel une valeur de delay StopTimeUpdate est spécifiée. Les fournisseurs de flux sont fortement encouragés à fournir une valeur d'timestamp TripUpdate. indiquant la date de la dernière mise à jour de la valeur du delay, afin d'évaluer la fraîcheur des données. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
trip_properties | TripProperties | Optionnelle | Un | Fournit les propriétés mises à jour pour le trip. Attention : ce message est toujours expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message StopTimeEvent¶
Informations de chronométrage pour un événement unique prévu (soit l'arrival, soit le departure). Les informations temporelles comprennent le delay et/ou l'time estimée, ainsi que l'uncertainty.
- Ledelay doit être utilisé lorsque la prédiction est donnée par rapport à un horaire existant dans GTFS.
- L'time doit être indiquée, qu'il y ait ou non un horaire prédit. Si le time et le delay sont tous deux spécifiés, le time sera prioritaire (bien que normalement, le time, s'il est donné pour un trip SCHEDULED, devrait être égal au time SCHEDULED dans GTFS + delay).
L'uncertainty s'applique aussi bien au time qu'au delay. L'uncertainty spécifie approximativement l'erreur attendue dans le delay réel (mais attention, nous n'avons pas encore défini sa signification statistique précise). Il est possible que l'uncertainty soit nulle, par exemple pour les trains qui sont conduits sous le contrôle d'un ordinateur.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
delay | int32 | Conditionnellement requis | Un | Ledelay (en secondes) peut être positif (ce qui signifie que le vehicle est en retard) ou négatif (ce qui signifie que le vehicle est en avance sur son horaire). Un delay de 0 signifie que le vehicle est exactement à l'time. Le delay ou l'time doivent être fournis dans un StopTimeEvent - les deux champs ne peuvent pas être EMPTY. |
time | int64 | Conditionnellement requis | Un | Événement en time absolu. En time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). Le delay ou l'time doit être fourni dans un StopTimeEvent - les deux champs ne peuvent pas être EMPTY. |
uncertainty | int32 | Optionnelle | Un | Si l'uncertainty est omise, elle est interprétée comme inconnue. Pour spécifier une prédiction totalement certaine, donnez la valeur 0 à son uncertainty. |
message StopTimeUpdate¶
Mise à jour en temps réel des événements d'arrival et/ou de departure pour un arrêt donné sur un trip. Veuillez également vous référer à la discussion générale sur les mises à jour des arrêts time la documentation des TripDescriptor et trip updates entities.
Des mises à jour peuvent être fournies pour les événements passés et futurs. Le producteur est autorisé, mais pas obligé, d'abandonner les événements passés.
La mise à jour est liée à un arrêt spécifique par le biais de stop_sequence ou de stop_id, de sorte que l'un de ces champs doit nécessairement être défini. Si le même stop_id est visité plus d'une fois dans un trip, alors stop_sequence doit être fourni dans tous les StopTimeUpdates pour ce stop_id sur ce trip.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
stop_sequence | uint32 | Conditionnellement requis | Un | Doit être le même que dans stop_times.txt dans le flux GTFS correspondant. Soit stop_sequence soit stop_id doit être fourni dans un StopTimeUpdate - les deux champs ne peuvent pas être EMPTY. stop_sequence est nécessaire pour les trajets qui visitent le même stop_id plus d'une fois (par exemple, une boucle) afin de désambiguïser l'arrêt pour lequel la prédiction est faite. Si StopTimeProperties.assigned_stop_id est renseigné, alors stop_sequence doit être renseigné. |
stop_id | string | Conditionnellement requis | Un | Doit être le même que dans stops.txt dans le flux GTFS correspondant. Soit stop_sequence soit stop_id doit être fourni dans un StopTimeUpdate - les deux champs ne peuvent pas être EMPTY. Si StopTimeProperties.assigned_stop_id est renseigné, il est préférable d'omettre le champ stop_id et d'utiliser uniquement stop_sequence . Si StopTimeProperties.assigned_stop_id et stop_id sont remplis, stop_id doit correspondre à assigned_stop_id . |
arrival | StopTimeEvent | Conditionnellement requis | Un | Si schedule_relationship est EMPTY ou SCHEDULED, l'arrival ou le departure doit être fourni dans un StopTimeUpdate - les deux champs ne peuvent pas être EMPTY. L'arrival et le departure peuvent tous deux être EMPTY lorsque schedule_relationship est SKIPPED. Si schedule_relationship est NO_DATA, l'arrival et le departure doivent être EMPTY. |
departure | StopTimeEvent | Conditionnellement requis | Un | Si schedule_relationship est EMPTY ou SCHEDULED, l'arrival ou le departure doit être fourni dans un StopTimeUpdate - les deux champs ne peuvent pas être EMPTY. L'arrival et le departure peuvent tous deux être EMPTY lorsque schedule_relationship est SKIPPED. Si schedule_relationship est NO_DATA, l'arrival et le departure doivent être EMPTY. |
departure_occupancy_status | OccupancyStatus | Optionnelle | Un | État prévu de l'occupation des passagers pour le vehicle immédiatement après le departure de l'arrêt donné. Si elle est fournie, la stop_sequence doit être fournie. Pour fournir le champ departure_occupancy_status sans fournir de prédictions d'arrival ou de departuretime, renseignez ce champ et définissez StopTimeUpdate.schedule_relationship = NO_DATA. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
schedule_relationship | ScheduleRelationship | Optionnelle | Un | La relation par défaut est SCHEDULED. |
stop_time_properties | StopTimeProperties | Optionnelle | 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 d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
enum ScheduleRelationship¶
La relation entre cette heure d'arrêt et l'horaire statique.
Valeurs
Valeur | Commentaire |
---|---|
SCHEDULED | Le vehicle se déplace conformément à son horaire statique d'arrêts, mais pas nécessairement selon les heures de l'horaire. Il s'agit de la défaut comportement. Au moins l'une des valeurs d'arrival et de departure doit être fournie. Les trajets basés sur la fréquenceGTFS frequencies.txt avec exact_times = 0) ne doivent pas avoir de valeur SCHEDULED et doivent utiliser UNSCHEDULED à la place. |
SKIPPED | L'arrêt est SKIPPED, c'est-à-dire que le vehicle ne s'arrêtera pas à cet arrêt. L'arrival et le departure sont facultatifs. Lorsque la valeur SKIPPED n'est pas propagé aux arrêts suivants du même trip (c'est-à-dire que le vehicle s'arrêtera aux arrêts suivants du trip, à moins que ces arrêts n'aient également un retard d'arrivée). stop_time_update avec schedule_relationship: SKIPPED ). le delay par rapport à un arrêt précédent du trip le site se propage sur l'arrêt SKIPPED arrêt. En d'autres termes, si un stop_time_update avec une arrival ou departure n'est pas définie 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 l'arrêt SKIPPED et aux arrêts suivants du trip jusqu'à ce qu'une prédiction stop_time_update pour un arrêt ultérieur soit fournie. |
NO_DATA | Aucune donnée n'est fournie pour cet arrêt. Il indique qu'il n'y a pas d'information de temps réel disponible. Lorsqu'il est défini, NO_DATA se propage aux arrêts suivants. Il s'agit donc de la manière recommandée de spécifier à partir de quel arrêt vous ne disposez pas d'informations sur le temps réel. Lorsque NO_DATA est défini, ni l'arrival ni le departure ne doivent être fournis. |
UNSCHEDULED | Le vehicle effectue un trip 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 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 d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message StopTimeProperties¶
Mise à jour en temps réel pour certaines propriétés définies dans GTFS stop_times.txt.
Attention : ce message est encore expérimental , et susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
assigned_stop_id | string | Optionnelle | Un | Prend en charge les affectations d'arrêttime. Se réfère à un stop_id défini dans le GTFS stops.txt . La nouvelle assigned_stop_id ne devrait pas entraîner une expérience de trip sensiblement différente pour l'utilisateur end par rapport à l'itinéraire de l'arrêt. stop_id définis dans GTFS stop_times.txt . En d'autres termes, l'utilisateur end ne devrait pas considérer ce nouveau . stop_id comme un "changement inhabituel" si le nouvel arrêt a été présenté dans une application sans contexte supplémentaire. Par exemple, ce champ est destiné à être utilisé pour les affectations de plates-formes en utilisant un paramètre de stop_id qui appartient à la même station que l'arrêt défini à l'origine dans GTFS stop_times.txt . Pour affecter un arrêt sans fournir de prévisions d'arrival ou de departuretime, renseignez ce champ et définissez le paramètre 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êts doivent également être reflétées dans d'autres champs GTFS(par ex, VehiclePosition.stop_id ). Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message TripProperties¶
Définit les propriétés mises à jour du trip
Attention : ce message est encore expérimental et est susceptible d'être modifié. Il pourrait être formellement adopté à l'avenir.
.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
trip_id | string | Conditionnellement requis | Un | Définit l'identifiant d'un nouveau trip qui est une copie d'un trip existant défini dans (CSV) GTFS trips.txt mais qui start à une date et/ou une time 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 Dans le cas contraire, ce champ ne doit pas être renseigné et sera ignoré par les consommateurs. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
start_date | string | Conditionnellement requis | Un | Date de service à laquelle le trip DUPLICATED sera exécuté. Doit être fournie au format AAAAMMJJ. Ce champ est obligatoire si schedule_relationship est DUPLICATED Sinon, ce champ ne doit pas être rempli et sera ignoré par les consommateurs. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
start_time | string | Conditionnellement requis | Un | Définit l'time departure start trip lorsqu'il est DUPLICATED. Voir la définition de stop_times.departure_time dans les GTFS (CSV). Les heures d'arrival et de departure SCHEDULED pour le trip DUPLICATED sont calculées en fonction du décalage entre le trip original departure_time et ce champ. Par exemple, si un trip GTFS comporte un arrêt A avec un departure_time de 10:00:00 et un arrêt B avec departure_time de 10:01:00 et que ce champ est renseigné avec la valeur de 10:30:00 l'arrêt B du trip DUPLICATED aura une valeur SCHEDULED departure_time de 10:31:00 . Prévision en temps réel delay sont appliquées à cette time horaire calculée pour déterminer l'time prévue. Par exemple, si un departure delay de 30 est fourni pour l'arrêt B, alors l'time departure prévue est 10:31:30 . Les valeurs de prédiction en temps réel time Les valeurs de prédiction en temps réel n'ont pas de décalage appliqué et indiquent l'time prévue telle qu'elle est fournie. Par exemple, si un departure time représentant 10:31:30 est fourni pour l'arrêt B, l'time de departure prévue est alors 10:31:30 Ce champ est obligatoire si schedule_relationship est DUPLICATED Dans le cas contraire, ce champ ne doit pas être rempli et sera ignoré par les consommateurs. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
shape_id | string | Optionnelle | Un | Indique la Shape du trajet du vehicle pour ce trip lorsqu'elle diffère de l'original. Se réfère à une Shape définie dans le GTFS (CSV) ou à une nouvelle entity Shape dans un fluxtime. Voir la définition du trips.shape_id dans (CSV) GTFS. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message VehiclePosition¶
Informations sur le positionnement en temps réel d'un vehicle donné.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
trip | TripDescriptor | Optionnelle | Un | Le trip que ce vehicle dessert. Peut être EMPTY ou partiel si le vehicle ne peut pas être identifié avec une instance de trip donnée. |
vehicle | VehicleDescriptor | Optionnelle | Un | Informations supplémentaires sur le vehicle qui dessert ce trip. Chaque entrée doit avoir un unique id vehicle. |
Position | Position | Optionnelle | Un | Position actuelle de ce vehicle. |
current_stop_sequence | uint32 | Optionnelle | Un | Indice de la séquence d'arrêt de l'arrêt actuel. La signification de current_stop_sequence (c'est-à-dire l'arrêt auquel il fait référence) est déterminée par current_status. Si current_status est absent, on suppose que IN_TRANSIT_TO est utilisé. |
stop_id | string | Optionnelle | Un | Identifie l'arrêt actuel. La valeur doit être la même que dans stops.txt dans le flux GTFS correspondant. Si StopTimeProperties.assigned_stop_id est utilisé pour attribuer un stop_id ce champ doit également refléter le changement de stop_id . |
current_status | VehicleStopStatus | Optionnelle | Un | Le statut exact du vehicle par rapport à l'arrêt actuel. Ignoré si current_stop_sequence est manquant. |
timestamp | uint64 | Optionnelle | Un | Moment où la Position du vehicle a été mesurée. En time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). |
congestion_level | CongestionLevel | Optionnelle | Un | |
occupancy_status | OccupancyStatus | Optionnelle | Un | État de l'occupation des passagers pour le vehicle ou le chariot. Si le champ multi_carriage_details est renseigné avec l'OccupancyStatus par voiture, ce champ doit décrire l'ensemble du vehicle en tenant compte de toutes les voitures acceptant des passagers. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
occupancy_percentage | uint32 | Optionnelle | Un | Valeur en pourcentage indiquant le degré d'occupation des passagers dans le vehicle. La valeur 100 doit représenter l'occupation maximale totale pour laquelle le vehicle a été conçu, y compris la capacité en places assises et debout, et que les règlements d'exploitation actuels autorisent. La valeur peut dépasser 100 si le nombre de passagers est supérieur à la capacité maximale prévue. La précision du occupancy_percentage doit être suffisamment faible pour qu'il soit impossible de suivre les passagers individuels qui montent ou descendent du vehicle. Si le champ multi_carriage_details est renseigné avec le occupancy_percentage par voiture, ce champ doit décrire l'ensemble du vehicle en tenant compte de toutes les voitures acceptant des passagers. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
multi_carriage_details | CarriageDetails | Optionnelle | Plusieurs | Détails des voitures multiples de ce vehicle donné. La première occurrence représente la première voiture du vehicle, compte tenu de la direction actuelle du déplacement. Le nombre d'occurrences du champ multi_carriage_details représente le nombre de wagons du vehicle. Il inclut également les wagons non embarquables, comme les moteurs, les wagons d'MAINTENANCE, etc., car ils fournissent des informations précieuses aux passagers sur l'endroit où ils doivent se tenir sur un quai. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
enum VehicleStopStatus¶
Valeurs
Valeur | Commentaire |
---|---|
INCOMING_AT | Le vehicle est sur le point d'arriver à l'arrêt (sur un affichage d'arrêt, le symbole du vehicle clignote généralement). |
STOPPED_AT | Le vehicle est arrêté à l'arrêt. |
IN_TRANSIT_TO | Le vehicle a quitté l'arrêt précédent et est en transit. |
enum CongestionLevel¶
Niveau deCONGESTION qui affecte ce vehicle.
Valeurs
Valeur |
---|
UNKNOWN_CONGESTION_LEVEL |
RUNNING_SMOOTHLY |
STOP_AND_GO |
CONGESTION |
SEVERE_CONGESTION |
enum OccupancyStatus¶
État de l'occupation des passagers pour le vehicle ou le chariot.
Les producteurs individuels peuvent ne pas publier toutes les valeurs de 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 voulu par le producteur. De même, les producteurs doivent utiliser les valeurs OccupancyStatus qui correspondent aux états réels d'occupation des vehicle.
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 susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir.
Valeurs
Valeur | Commentaire |
---|---|
EMPTY | Le vehicle est considéré comme EMPTY par la plupart des mesures, et a peu ou pas de passagers à bord, mais accepte toujours des passagers. |
MANY_SEATS_AVAILABLE | Le vehicle ou la voiture a un grand nombre de sièges disponibles. Le nombre de sièges libres par rapport au nombre total de sièges 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 vehicle ou la voiture a un petit nombre de sièges disponibles. Le nombre de sièges libres par rapport au nombre total de sièges 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 vehicle ou la voiture ne peut actuellement accueillir que des passagers debout. |
CRUSHED_STANDING_ROOM_ONLY | Le vehicle ou la voiture ne peut actuellement accueillir que des passagers debout et dispose d'un espace limité pour eux. |
FULL | Le vehicle est considéré comme FULL par la plupart des mesures, mais peut encore permettre à des passagers de monter à bord. |
NOT_ACCEPTING_PASSENGERS | Le vehicle ou la voiture n'accepte pas de passagers. Le vehicle ou la voiture accepte généralement les passagers pour l'embarquement. |
NO_DATA_AVAILABLE | Le vehicle ou la voiture n'a pas de données d'occupation disponibles à ce time. |
NOT_BOARDABLE | Le vehicle ou la voiture n'est pas embarquable et n'accepte jamais de passagers. Utile pour les véhicules ou les wagons spéciaux (moteur, wagon de MAINTENANCE, etc...). |
message CarriageDetails¶
Détails spécifiques au chariot, utilisés pour les véhicules composés de plusieurs chariots.
Attention : ce message est encore expérimental , et susceptible d'être modifié. Il pourra être adopté formellement dans le futur.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
id | string | Optionnelle | Un | Identification de la voiture. Doit être unique par vehicle. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
label | string | Optionnelle | Un | label visible par l'utilisateur qui peut être montrée au passager pour l'aider à identifier la voiture. Exemple : "7712", "Voiture ABC-32", etc... Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
occupancy_status | OccupancyStatus | Optionnelle | Un | Statut d'occupation pour ce chariot donné, dans ce vehicle. La valeur par défaut est NO_DATA_AVAILABLE .Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
occupancy_percentage | int32 | Optionnelle | Un | Pourcentage d'occupation pour cette voiture donnée, dans ce vehicle. Suit les mêmes règles que "VehiclePosition.occupancy_percentage". Utilisez -1 si les données ne sont pas disponibles pour ce véhicule. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
carriage_sequence | uint32 | Obligatoire | Un | Identifie l'ordre de ce chariot par rapport aux autres chariots dans la liste des CarriageStatus du vehicle. Le premier chariot dans le sens de la marche doit avoir la valeur 1. La deuxième valeur correspond au deuxième chariot dans le sens de la marche et doit avoir la valeur 2, et ainsi de suite. Par exemple, le premier chariot dans le sens de la marche a la valeur 1. Si le deuxième chariot dans le sens de la marche a la valeur 3, les consommateurs rejetteront les données de tous les chariots (c'est-à-dire le champ multi_carriage_details ). Les wagons sans données doivent être représentés par un numéro de carriage_sequence valide et les champs sans données doivent être omis (on peut aussi inclure ces champs et leur attribuer les valeurs "sans données"). Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
message Alert¶
Une Alert, indiquant une sorte d'incident dans le réseau de transport public.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
active_period | TimeRange | Optionnelle | Plusieurs | time pendant laquelle l'Alert doit être affichée à l'utilisateur. Si elle est absente, l'Alert sera affichée tant qu'elle apparaîtra dans le flux. Si plusieurs périodes sont indiquées, l'Alert sera affichée pendant toutes ces périodes. |
informed_entity | EntitySelector | Obligatoire | Plusieurs | Entités dont nous devons informer les utilisateurs de cette Alert. Au moins une informed_entity doit être fournie. |
Cause | Cause | Optionnelle | Un | |
Effect | Effect | Optionnelle | Un | |
url | TranslatedString | Optionnelle | Un | L'url qui fournit des informations supplémentaires sur l'Alert. |
header_text | TranslatedString | Obligatoire | Un | L'header de l'Alert. Cette string en clair sera mise en évidence, par exemple en caractères gras. |
description_text | TranslatedString | Obligatoire | Un | Description de l'Alert. Cette string en clair sera formatée comme le corps de l'Alert (ou affichée lors d'une demande explicite de "développement" par l'utilisateur). Les informations de la description doivent compléter les informations de l'header. |
tts_header_text | TranslatedString | Optionnelle | Un | text contenant l'header de l'Alert, à utiliser pour les applications de text. Ce champ est la version text de header_text. Il doit contenir les mêmes informations que le header_text, mais formaté de manière à pouvoir être lu par la text(par exemple, abréviations supprimées, chiffres en toutes lettres, etc.) |
tts_description_text | TranslatedString | Optionnelle | Un | text contenant une description du Alert à utiliser pour les applications de text. Ce champ est la version "synthèse text de description_text. Il doit contenir les mêmes informations que description_text mais formatées de manière à pouvoir être lues par la text(par exemple, abréviations supprimées, chiffres en toutes lettres, etc.) |
severity_level | SeverityLevel | Optionnelle | Un | Gravité de l'Alert. |
image | TranslatedImage | Optionnelle | Un | TranslatedImage à afficher avec le text l'Alert. Utilisée pour expliquer visuellement l'Effect Alert d'un DETOUR, de la fermeture d'une station, etc. L'image doit améliorer la compréhension de l'Alert et ne doit pas être le seul emplacement des informations essentielles. Les types d'images suivants sont déconseillés : les image contenant principalement du text, les images de marketing ou de marque qui n'apportent aucune information supplémentaire. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
image_alternative_text | TranslatedString | Optionnelle | Un | text décrivant l'apparence de l'image liée dans le image (par exemple, au 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 la spécification HTML pour le text image alt. Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
enum Cause¶
LaCause de cette Alert.
Valeurs
Valeur |
---|
UNKNOWN_CAUSE |
OTHER_CAUSE |
TECHNICAL_PROBLEM |
STRIKE |
DEMONSTRATION |
ACCIDENT |
HOLIDAY |
WEATHER |
MAINTENANCE |
CONSTRUCTION |
POLICE_ACTIVITY |
MEDICAL_EMERGENCY |
enum Effect¶
L'Effect de ce problème sur l'entity 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'Alert.
Attention : ce champ est encore expérimental et susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir.
Valeurs
Valeur |
---|
UNKNOWN_SEVERITY |
INFO |
WARNING |
SEVERE |
message TimeRange¶
Un intervalle de time. L'intervalle est considéré comme actif à l'time t
si celui-ci
est supérieur ou égal à l'time start et inférieur à l'time end.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
start | uint64 | Conditionnellement requis | Un | timestart, en time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). S'il est absent, l'intervalle commence à moins l'infini. Si un TimeRange est fourni, le start ou la end doivent être indiqués - les deux champs ne peuvent pas être EMPTY. |
end | uint64 | Conditionnellement requis | Un | timeend, en time POSIX (c'est-à-dire le nombre de secondes depuis le 1er janvier 1970 00:00:00 UTC). S'il est absent, l'intervalle se termine à plus l'infini. Si un TimeRange est fourni, le start ou la end doivent être indiqués - les deux champs ne peuvent pas être EMPTY. |
Position_message_¶
Position géographique d'un vehicle.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
latitude | float | Obligatoire | Un | Degrés nord, dans le système de coordonnées WGS-84. |
longitude | float | Obligatoire | Un | Degrés Est, dans le système de coordonnées WGS-84. |
bearing | float | Optionnelle | Un | bearing, en degrés, dans le sens des aiguilles d'une montre à partir du Nord véritable, c'est-à-dire que 0 correspond au Nord et 90 à l'Est. Il peut s'agir de l'bearing la boussole, ou de la direction vers le prochain arrêt ou le lieu intermédiaire. Elle ne doit pas être déduite de la séquence des positions précédentes, que les clients peuvent calculer à partir des données précédentes. |
odometer | double | Optionnelle | Un | Valeur de l'odometer, en mètres. |
speed | float | Optionnelle | Un | speed momentanée mesurée par le vehicle, en mètres par seconde. |
message TripDescriptor¶
Un descripteur qui identifie une instance unique d'un trip GTFS.
Pour spécifier une instance unique de trip, dans de nombreux cas, un trip_id
seul est suffisant. Toutefois, dans les cas suivants, des informations supplémentaires sont nécessaires pour déterminer une instance unique de trip:
- Pour les voyages définis dans frequencies.txt,
start_date
etstart_time
sont nécessaires en plus detrip_id
. - Si le trip dure plus de 24 heures ou est retardé de telle sorte qu'il entre en collision avec un trip SCHEDULED le jour suivant, la
start_date
est requise en plus de l'trip_id
. - Si le champ
trip_id
ne peut pas être fourni, les champsroute_id
,direction_id
,start_date
etstart_time
doivent tous être fournis.
Dans tous les cas, si le champ route_id
est fourni en plus du trip_id
, alors le route_id
doit être le même que route_id
attribué au trip donné dans le fichier 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 trip. 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 déterminer un seul trip commençant à une time spécifique de la journée. Si le TripDescriptor ne se résout pas à un seul exemple de trip (c'est-à-dire qu'il se résout à zéro ou plusieurs exemples de trip ), il est considéré comme une erreur et l'entity contenant le TripDescriptor erroné peut être rejetée par les consommateurs.
Notez que si le trip_id n'est pas connu, les ids de séquence de station dans TripUpdate ne sont pas suffisants, et les stop_ids doivent également être fournis. En outre, les heures absolues d'arrival doivent être fournies.
TripDescriptor.route_id ne peut pas être utilisé dans un EntitySelector Alert pour spécifier une Alert à 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 | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
trip_id | string | Conditionnellement requis | Un | Le trip_id du flux GTFS auquel ce sélecteur fait référence. Pour les trajets non basés sur la fréquence (trajets non définis dans GTFS frequencies.txt), ce champ est suffisant pour identifier le trip de manière unique. 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 SCHEDULEDtrajets non définis dans GTFS frequencies.txt), trip_id ne peut être omis que si le trip 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 trip du GTFS statique à DUPLICATED. Lorsque schedule_relationship est DUPLICATED dans un VehiclePosition, le trip_id identifie le nouveau trip dupliqué et doit contenir la valeur du TripUpdate correspondant.TripProperties.trip_id. |
route_id | string | Conditionnellement requis | 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 schedule_relationship=SCHEDULED doivent tous être définis pour identifier une instance de trip. TripDescriptor.route_id ne doit pas être utilisé dans un EntitySelector Alert pour spécifier une Alert à l'échelle de l'itinéraire qui affecte tous les trajets d'un itinéraire - utilisez plutôt EntitySelector.route_id. |
direction_id | uint32 | Conditionnellement requis | Un | Le direction_id du fichier trips.txt du flux GTFS, indiquant la direction du voyage pour les voyages 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 d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
start_time | string | Conditionnellement requis | Un | L'time start initialement SCHEDULED de cette instance de trip. Lorsque le trip_id correspond à un trip 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 trip 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 trip et les positions des vehicle. Si le trip correspond à un enregistrement GTFS exact_times=1, alors start_time doit être un multiple (y compris zéro) de headway_secs plus tard que frequencies.txt start_time pour la time correspondante. Si le trip correspond à exact_times=0, l'start_time peut être arbitraire et il est initialement prévu que ce soit le premier departure du trip. Une fois établie, l'start_time de ce trip basé sur la fréquence exact_times=0 doit être considérée comme immuable, même si l'time premier departure change -- ce changement d'time peut être reflété dans un StopTimeUpdate. Si trip_id est omis, start_time doit être fourni. Le format et la sémantique de ce champ sont les mêmes que ceux de GTFS frequencies.txt, par exemple 11:15:35 ou 25:15:35. |
start_date | string | Conditionnellement requis | Un | La date de start de cette instance de trip au format AAAAMMJJ. Pour les trajets SCHEDULED trajets non définis dans le frequencies.txt GTFS frequencies.txt), ce champ doit être fourni pour éviter toute ambiguïté concernant les trajets dont le retard est tel qu'ils entrent en collision avec un trip SCHEDULED le jour suivant. Par exemple, pour un train qui part tous les jours à 8h00 et à 20h00, et qui a 12 heures de retard, il y aurait deux trajets distincts à la même time. 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 sur la base de l'horaire où un vehicle qui a une heure de retard n'est plus considéré comme 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 | Optionnelle | Un | La relation entre ce trip et l'horaire statique. Si TripDescriptor est fourni dans une Alert EntitySelector le schedule_relationship est ignoré par les consommateurs lors de l'identification de l'instance de trip correspondante. |
enum ScheduleRelationship¶
La relation entre ce trip et le programme statique. Si un trip est effectué conformément à un horaire temporaire, non reflété dans GTFS, il ne doit pas être marqué comme SCHEDULED, mais comme ADDED.
Valeurs
Valeur | Commentaire |
---|---|
SCHEDULED | trip qui se déroule conformément à son GTFS Schedule, ou qui est suffisamment proche du trip SCHEDULED pour être associé à celui-ci. |
ADDED | Un trip supplémentaire qui a été ADDED en plus d'un horaire en cours, par exemple, pour remplacer un vehicle en panne ou pour répondre à une charge soudaine 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 GitHub de GTFS (1) (2) (3) autour de la spécification complète ou de la dépréciation des voyages ADDED et la documentation sera mise à jour lorsque ces discussions seront finalisées. |
UNSCHEDULED | Un trip en cours d'exécution sans horaire associé - cette valeur est utilisée pour identifier les trajets définis dans GTFS frequencies.txt avec exact_times = 0. Elle ne doit pas être utilisée pour décrire des trajets non définis dans GTFS frequencies.txt, ou des trajets dans GTFS frequencies.txt avec exact_times = 1. Les trajets avec schedule_relationship: UNSCHEDULED doivent également définir tous les StopTimeUpdates schedule_relationship: UNSCHEDULED |
CANCELED | Un trip qui existait dans l'horaire mais qui a été supprimé. |
DUPLICATED | Un nouveau trip qui est identique à un trip SCHEDULED existant, à l'exception de la date et de l'time start service. Utilisé avec TripUpdate.TripProperties.trip_id , TripUpdate.TripProperties.start_date et TripUpdate.TripProperties.start_time pour copier un trip existant à partir d'un GTFS statique, mais avec une date et/ou une time de start service différente. La duplication d'un trip est autorisée si le service lié au trip original dans (CSV) GTFS (dans calendar.txt ou calendar_dates.txt ) est disponible dans les 30 prochains jours. Le trip à DUPLICATED est identifié via TripUpdate.TripDescriptor.trip_id . Cette énumération ne modifie pas le trip existant référencé par TripUpdate.TripDescriptor.trip_id - si un producteur souhaite annuler le trip original, il doit publier un message distinct TripUpdate avec la valeur CANCELED. Voyages définis dans GTFS frequencies.txt avec exact_times qui est EMPTY ou égal à 0 ne peuvent pas être DUPLICATED. Le site VehiclePosition.TripDescriptor.trip_id pour le nouveau trip doit contenir la valeur correspondante de TripUpdate.TripProperties.trip_id et VehiclePosition.TripDescriptor.ScheduleRelationship doit également avoir la valeur DUPLICATED . Les producteurs et consommateurs existants qui utilisaient l'énumération ADDED pour représenter les voyages DUPLICATED doivent suivre le guide de migration pour passer à l'énumération DUPLICATED. |
message VehicleDescriptor¶
Informations d'identification du vehicle effectuant le trip.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
id | string | Optionnelle | Un | Identification du système interne du vehicle. Doit être unique par vehicle, et est utilisé pour le suivi du vehicle au fur et à mesure qu'il avance dans le système. Cet id ne doit pas être visible pour l'end; à cette fin, utilisez l'étiquette label champ |
label | string | Optionnelle | Un | label visible par l'utilisateur, c'est-à-dire quelque chose qui doit être montré au passager pour l'aider à identifier le bon vehicle. |
license_plate | string | Optionnelle | Un | La plaque d'immatriculation du vehicle. |
message EntitySelector¶
Un sélecteur pour une entity dans un flux GTFS. Les valeurs des champs doivent correspondre aux champs appropriés du flux GTFS. Au moins un spécificateur doit être donné. Si plusieurs sont donnés, ils doivent être interprétés comme étant joints par l'opérateur logique AND
. En outre, la combinaison des spécificateurs doit correspondre aux informations correspondantes dans le flux GTFS. En d'autres termes, pour qu'une Alert s'applique à une entity dans GTFS, elle doit correspondre à tous les champs EntitySelector fournis. Par exemple, un EntitySelector qui comprend les champs route_id
: "5" et route_type
: "3" s'applique uniquement au bus route_id
: "5" - il ne s'applique pas aux autres itinéraires de route_type
: "3". Si un producteur souhaite qu'une Alert s'applique à la route_id
: "5" ainsi qu'au route_type
: "3", il doit fournir deux EntitySelectors distincts, l'un faisant référence à route_id
: "5" et un autre référençant route_type
: "3".
Au moins un spécificateur doit être donné - tous les champs d'un EntitySelector ne peuvent pas être EMPTY.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
agency_id | string | Conditionnellement requis | Un | Le agency_id du flux GTFS auquel ce sélecteur fait référence. |
route_id | string | Conditionnellement requis | Un | route_id du flux GTFS auquel ce sélecteur fait référence. Si direction_id est fourni, route_id doit également être fourni. |
route_type | int32 | Conditionnellement requis | Un | Le route_type du GTFS auquel ce sélecteur fait référence. |
direction_id | uint32 | Conditionnellement requis | Un | Le direction_id du fichier GTFS feed trips.txt, 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 d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
trip | TripDescriptor | Conditionnellement requis | Un | L'instance de trip du GTFS à laquelle ce sélecteur fait référence. Ce TripDescriptor doit correspondre à une seule instance de trip dans les données GTFS (par exemple, un producteur ne peut pas fournir uniquement un trip_id pour les voyages exact_times=0). Si le champ ScheduleRelationship est renseigné dans ce TripDescriptor, il sera ignoré par les consommateurs lorsqu'ils tenteront d'identifier le trip GTFS. |
stop_id | string | Conditionnellement requis | Un | Le stop_id du flux GTFS auquel ce sélecteur fait référence. |
message TranslatedString¶
Un message internationalisé contenant les versions linguistiques d'un extrait de text 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 language l'interface utilisateur correspond au code de language d'une Translation, la première Translation correspondante est sélectionnée. Si une language par défaut de l'interface utilisateur (par exemple, l'anglais) correspond au code de language d'une Translation, la première Translation correspondante est sélectionnée. Si une Translation a un code de language non spécifié, cette Translation est sélectionnée.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
Translation | Translation | Obligatoire | Plusieurs | Au moins une Translation doit être fournie. |
Translation_message_¶
Une string localisée correspondant à une language.
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
text | string | Obligatoire | Un | Une string UTF-8 contenant le message. |
language | string | Conditionnellement requis | Un | Code de language BCP-47. Peut être omis si la language est inconnue ou si aucune internationalisation n'est effectuée pour le flux. Une Translation au maximum est autorisée à avoir une balise de language non spécifiée - s'il y a plus d'une Translation, la language doit être fournie. |
message TranslatedImage¶
Un message internationalisé contenant les versions d'une image pour chaque langue. L'une des images d'un message sera récupérée. La résolution se déroule comme suit : Si la language l'interface utilisateur correspond au code de language d'une Translation, la première Translation correspondante est choisie. Si une language par défaut de l'interface utilisateur (par exemple, l'anglais) correspond au code de language d'une Translation, la première Translation correspondante est sélectionnée. Si une Translation a un code de language non spécifié, cette Translation est sélectionnée.
Attention : ce message est encore expérimental et susceptible d'être modifié. Il est possible qu'il soit formellement adopté à l'avenir.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
localized_image | LocalizedImage | Obligatoire | Plusieurs | Au moins une image localisée doit être fournie. |
message LocalizedImage¶
Une image localisée dont l'url est associée à une language.
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
url | string | Obligatoire | Un | string contenant un lien url vers une image. L'image liée doit être inférieure à 2 Mo. Si une image est modifiée de manière suffisamment importante pour qu'une mise à jour soit nécessaire du côté du consommateur, le producteur doit mettre à jour l'url. L'url doit être une url entièrement qualifiée qui comprend http:// ou https://, et tout caractère spécial dans l'url doit être correctement échappé. Voir ce qui suit url pour une description de la manière de créer des valeurs d'url entièrement qualifiées. |
media_type | string | Obligatoire | Un | Type de média IANA pour spécifier le type d'image à afficher. Le type doit start par "image/". |
language | string | Conditionnellement requis | Un | Code de language BCP-47. Peut être omis si la language est inconnue ou si aucune internationalisation n'est effectuée pour le flux. Une Translation au maximum est autorisée à avoir une balise de language non spécifiée - s'il y a plus d'une Translation, la language doit être fournie. |
message Shape¶
Décrit le chemin physique qu'emprunte un vehicle lorsque la Shape ne fait pas partie du GTFS (CSV), comme dans le cas d'un DETOUR ad hoc. Les formes appartiennent aux Trips et consistent en une polyligne codée pour une transmission plus efficace. Les formes n'ont pas besoin d'intercepter exactement l'emplacement des arrêts, mais tous les arrêts d'un trip doivent se trouver à une faible distance de la Shape ce trip, c'est-à-dire à proximité de segments de ligne droite reliant les points de la Shape.
Attention : ce message est encore expérimental et est susceptible d'être modifié. Il pourrait être formellement adopté à l'avenir.
.
Champs
Nom du champ | Type | Obligatoire | Cardinalité | Description |
---|---|---|---|---|
shape_id | string | Obligatoire | Un | Identifiant de la Shape. Doit être différent de celui shape_id défini dans le GTFS (CSV). Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |
encoded_polyline | string | Obligatoire | Un | Représentation polyligne codée de la Shape. Cette polyligne doit contenir au moins deux points. Pour plus d'informations sur les polylignes codées, voir https://developers.google.com/maps/documentation/utilities/polylinealgorithm Attention : ce champ est encore expérimental et est susceptible d'être modifié. Il est possible qu'il soit officiellement adopté à l'avenir. |