Google Transports en commun (principes de base)

Modélisation GTFS : utiliser des flux statiques avec des flux en temps réel

Pour garantir un service continu et l'affichage de données précises auprès des utilisateurs de Google Transports en commun, une modélisation GTFS (General Transit Feed Specification) est nécessaire. La modélisation GTFS consiste à concevoir des flux statiques et en temps réel (RT) afin que, conjointement, ils reflètent la réalité sur le réseau.

Principes de base de la modélisation GTFS

  • Flux GTFS statiques : une fois envoyés à Google, ils sont traités dans un délai compris entre 24 et 48 heures. L'opération peut toutefois être plus longue si Google détecte des problèmes dans le flux.
    Les flux GTFS statiques concernent les horaires et les autres informations préétablis du réseau de transports en commun. Vous devez envoyer votre flux statique à Google au moins deux jours à l'avance. Toutefois, l'idéal est de l'envoyer une semaine à l'avance au cas où Google détecterait des conflits ou des problèmes potentiels dans votre flux nécessitant un examen manuel.
  • Flux GTFS-realtime : les mises à jour transmises à Google sont immédiatement prises en compte.
    Les flux GTFS-realtime sont conçus pour renseigner l'état en temps réel des données statiques. Ils communiquent les retards prévus d'après la position des véhicules, ainsi que les mises à jour apportées aux trajets ou aux arrêts prédéfinis dans le flux statique. Ils fournissent aussi des alertes de service (retards et interruptions de trafic) aux utilisateurs. 
  • Même s'il existe des solutions pour activer et désactiver les trajets dans un flux GTFS, cette possibilité est limitée dans le sens où vous ne pouvez pas ajouter de services non définis (tracé, ordre et horaires des arrêts, et itinéraire) en moins de deux jours (c'est-à-dire en temps réel). L'ajout de services nécessite entre deux et sept jours au minimum (un examen manuel est effectué pour détecter les modifications contradictoires ou "suspectes").
  • Dans votre flux statique, vous pouvez utiliser le fichier feed_info.txt pour déterminer au préalable (au moins deux à sept jours à l'avance) la date de mise en ligne des modifications statiques, en vous assurant de respecter vos flux en temps réel. Utilisez les champs feed_start_date et feed_end_date pour spécifier les dates auxquelles votre flux statique doit être actif. Si la date de début du flux (feed_start_date) est postérieure à la date à laquelle nous commençons à le traiter, nous le traitons malgré tout, mais conservons la version actuelle et la version "future". 
  • Les flux statiques contiennent les données de base sur les itinéraires, les arrêts et les horaires. Toutefois, comme indiqué ci-dessus, toute modification des flux statiques nécessite entre deux et sept jours (au minimum). Vous trouverez ci-dessous les bonnes pratiques à suivre pour modifier les horaires.

Bonnes pratiques pour mettre à jour vos flux statiques et en temps réel

Différents changements peuvent se produire dans les services de transports terrestres, concernant par exemple la durée des trajets, les niveaux d'urgence et le type d'entité. De manière générale, toute modification apportée aux données de base (par exemple, si vous devez ajouter, modifier ou supprimer des arrêts, des itinéraires ou des trajets) doit être effectuée dans le flux statique. Dans certains cas toutefois, notamment pour les changements temporaires qui demandent réactivité et rapidité, il est possible d'apporter des modifications dans le flux en temps réel. Découvrez dans les tableaux suivants les bonnes pratiques à suivre pour mettre à jour les données de votre flux.

Global : 

  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter des données de flux La plupart des changements sont possibles et simples. Cela n'est généralement pas possible, sauf pour ajouter une fréquence existante avec schedule_relationship.
Supprimer des données de flux Les suppressions importantes sont signalées comme suspectes et peuvent faire l'objet d'un examen plus long. RT n'est pas adapté aux suppressions statiques, mais les alertes sont recommandées pour les suppressions temporaires.
Modifier des données du flux La plupart des changements sont possibles et simples. Action non acceptée ni encouragée.
Formes
  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter Ajoutez shape_id à un trajet existant à partir de trips.txt si vous le souhaitez. Impossible (shape_id doit exister)
Supprimer Supprimez shape_id des trajets existants à partir de trips.txt si vous le souhaitez. Des tracés inutilisés peuvent être inclus. N/A
Modifier Modifiez le tracé si vous le souhaitez. Les changements s'appliquent sous deux jours. N/A
Arrêts
  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter

Oui. (des modifications appropriées peuvent être requises pour stop_times et trips).

Conseil : Les nouveaux noms d'arrêt sont soumis à un examen, ce qui entraîne un délai d'au moins deux jours avant qu'ils ne s'affichent dans Google Maps.
N/A
Supprimer Possible. Assurez-vous qu'aucun élément stop_times ne continue de faire référence à des arrêts non définis.

Effet NO_SERVICE sur l'alerte de service :

L'arrêt est ignoré dans chaque trajet dont il fait partie.

Sinon, l'élément schedule_relationship d'un StopTimeUpdate peut être IGNORÉ.

Modifier L'examen des arrêts peut prendre plus de deux jours compte tenu de l'ampleur du processus. Non. Seule la suppression est possible.
Heures d'arrêt
  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter Ajouter un élément stop_time équivaut à insérer un arrêt existant avec un trajet défini. Prévoyez deux jours avant la mise en ligne des modifications. Impossible.
Supprimer Supprimez les éléments stop_times des trajets de votre choix (pour supprimer les arrêts correspondants des trajets). Prévoyez deux jours avant la mise en ligne des modifications. L'élément schedule_relationship d'un StopTimeUpdate peut être IGNORÉ.
Modifier Modifiez le fichier stop_times si vous le souhaitez. Les changements s'appliquent sous deux jours.

En fait, la position du véhicule (VP) et la mise à jour du trajet (TU) correspondent à des heures d'arrêt modifiées dans le flux RT.

Les alertes de service dont les valeurs du champ effect correspondent à

SIGNIFICANT_DELAY et 

MODIFIED_SERVICE peuvent aussi indiquer cette situation.

Trajets
  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter

Pour activer ou désactiver explicitement le service par date, utilisez le fichier calendar_dates.txt.

Utilisez le fichier calendar_dates.txt conjointement avec le fichier calendar.txt pour créer des exceptions aux formats de service par défaut définis dans calendar.txt. Cette approche est adaptée si votre service est généralement régulier et comporte quelques modifications à des dates précises (pour des services de ramassage scolaire ou assurés lors d'événements spéciaux, par exemple). Le délai avant sa mise en ligne est de deux jours, mais il n'est pas nécessaire de modifier le flux GTFS en profondeur. Une modification sur une seule ligne est requise si le service existe déjà dans les trajets. Le service et le trajet peuvent être effectués avec une précision minimale pour disposer d'une cartographie 1:1.

Utilisez des valeurs schedule_relationship

pour indiquer les trajets non prévus dans le flux RT.

Le tracé et stop_time doivent être prédéfinis par rapport à un trajet existant.

La valeur ADDED copie les trajets prévus avec un nouvel élément start_time à condition que le trajet parent ne comporte pas de correspondances groupées. Pour faire la distinction entre les trajets, les éléments start_time doivent impérativement être cohérents.

Dans les alertes de service, ADDITIONAL_SERVICE permet de décrire les bus supplémentaires déployés sur des lignes existantes.

Supprimer

Supprimez le trajet et assurez-vous que toutes les références sont supprimées (frequencies, stop_times, trips). Le délai de mise en ligne est de deux jours.

Une autre méthode consiste à supprimer les entrées correspondantes de calendar.txt ou à ajouter des exceptions à calendar_dates.txt.

Ce résultat est obtenu avec une mise à jour du trajet associée à la valeur SKIPPED dans le champ schedule_relationship.

Une alerte avec l'effet NO_SERVICE ou REDUCED_SERVICE indique également cette situation à l'utilisateur. Utilisez un texte descriptif.

Modifier

Vous pouvez modifier des trajets si besoin.

Une autre méthode consiste à ajouter les entrées correspondantes à calendar.txt ou des exceptions à calendar_dates.txt.

La modification des arrêts d'un trajet n'est pas autorisée, mais les retards et les arrivées en avance sont indiqués via TU ou VP.

Vous pouvez bloquer des arrêts et des parties d'un trajet en temps réel (voir ci-dessus) grâce à des alertes de service.

 

Itinéraires
  Statique (deux à sept jours ou plus) Temps réel (environ une minute)
Ajouter Pour ajouter un itinéraire, ajoutez une seule ligne au fichier routes.txt. Toutefois, pour que cette modification soit visible, les trajets doivent être créés et affectés à l'itinéraire concerné dans trips.txt. Action non acceptée ni encouragée.
Supprimer Supprimez l'itinéraire et assurez-vous que les trajets correspondants sont soit supprimés, soit affectés à un autre itinéraire. Le délai de mise en ligne est de deux jours.

NO_SERVICE entraîne l'arrêt de tous les trajets associés à cet itinéraire. Les arrêts sur cet itinéraire demeurent non attribués lorsqu'ils sont partagés avec d'autres itinéraires/trajets.

Conseil : La suppression réelle d'un itinéraire reste un concept statique.
Modifier

Vous pouvez modifier des trajets si nécessaire.

Conseil : Les utilisateurs identifient les itinéraires en utilisant une couleur ou des noms. Nous vous déconseillons d'effectuer des changements fréquents.
Action non acceptée ni encouragée.

 

Informations complémentaires sur les flux en temps réel

Important : La modification en temps réel des formes ou des trajets et des éléments principaux des flux statiques n'est actuellement pas acceptée, ni encouragée.

Il est possible d'ajouter et de supprimer des éléments en temps réel : pour cela, le flux statique doit comporter un aperçu du trajet, stop_sequence et stop_time (un trajet à modéliser).

Nous vous conseillons d'utiliser les formats calendar.txt et calendar_dates.txt de façon créative. Par exemple, pour les jours de neige, spécifiez des trajets qui peuvent ne pas être "en service", mais seront activés dans une telle éventualité. En d'autres termes, définissez les trajets à l'avance. Cela vous permet d'activer/de désactiver rapidement les trajets "par défaut" dans le flux en temps réel selon la situation.

Questions fréquentes

Q : Un petit accident s'est produit à l'arrêt X. Je souhaite l'éviter pour aller directement à l'arrêt Y dès que possible. Est-ce possible ?
R : Nous pouvons supprimer l'arrêt X (alertes de service). Les trajets vont alors ignorer cet arrêt. Il n'est pas possible d'ajouter Y aux horaires, mais l'alerte ci-dessus permet d'indiquer qu'un autre arrêt intermédiaire peut être utilisé.
Q : Le festival Y a lieu ici. X nouvelles lignes ont été mises en place et quelques modifications importantes ont été apportées au réseau. Que peut-on faire ?

R : Tout dépend du temps qu'il reste avant le début du festival.

Si le festival a lieu dans plus de deux jours :

Utilisez calendar_dates.txt pour mettre hors service tous les trajets modifiés existants pendant la durée du festival. Vous pouvez également ajouter de nouveaux trajets pour la durée de l'événement. Ajouter de nouveaux arrêts est délicat. Il est donc recommandé de prévoir ce type d'opération à l'avance (au moins une semaine est nécessaire). Vous pouvez utiliser des arrêts existants. Pour modifier des arrêts, procédez comme suit :

  1. Créez un calendrier et des entrées calendar_date (nouveau service_id) pour les trajets existants concernés contenant le calendrier habituel et les éléments calendar_dates à exclure.
  2. Pointez les trajets concernés vers ce nouveau calendrier (service_id).
  3. Créez des entrées calendar_dates avec un nouveau service_id pour les dates de l'événement à utiliser avec les nouveaux itinéraires spéciaux et les versions modifiées des trajets concernés.
  4. Créez des trajets (et des tracés) pour les versions modifiées des trajets concernés. Créez également des itinéraires, des trajets et des tracés pour les lignes spéciales. Tous ces éléments doivent pointer vers le service_id créé lors de l'étape 3.
  5. Une fois l'événement terminé, rétablissez le format de flux précédent.

Si le festival a lieu dans moins de deux jours :

Nous pouvons annuler des trajets existants, et l'effet MODIFIED_SERVICE est parfaitement adapté pour communiquer à ce sujet. Nous n'avons pas le temps d'intégrer de nouveaux éléments stops ou stop_times aux horaires des itinéraires. Toutefois, nous pouvons ajouter des véhicules à des lignes existantes (planifiées ou basées sur la fréquence) pour répondre à une augmentation du service.


 
Q : Je souhaite ajouter un nouvel itinéraire immédiatement.
R : Désolé, ce n'est pas possible.
Q : Je souhaite ajouter un nouveau trajet immédiatement.

R : Le flux statique comporte-t-il déjà un trajet avec les mêmes valeurs stop_sequences que votre nouveau trajet ? Si ce n'est pas le cas, il n'est pas possible d'intégrer ce trajet dans l'index en moins de deux jours. 

Toutefois, vous pouvez définir une modification du trajet (TU, trip update) ou une position du véhicule (VP, vehicle position) par rapport à un trajet comportant des heures de départ différentes avec une valeur ADDED dans le champ schedule_relationship. Cet horaire supplémentaire utilisera les arrêts du trip_id fourni, mais commencera un trajet en fonction du nouvel élément start_time indiqué.

Important : Les valeurs start_time, direction, start_date et trip_id doivent rester identiques pour conserver la référence au trajet une fois qu'il est ajouté. Cette action n'est pas autorisée dans des trajets comportant des correspondances groupées. Les flux TU et VP peuvent se présenter comme suit :

Cet extrait n'est pas un code en temps réel (RT) valide. Il n'est fourni qu'à titre indicatif.  

# informations d'en-tête

header {

  # version de la spécification de vitesse. Actuellement "2.0"

  gtfs_realtime_version: "2.0"

  # détermine si l'ensemble de données est incrémental ou complet

  incrementality: FULL_DATASET

  # le moment où cet ensemble de données a été généré sur le serveur

  timestamp: 1284457468

}

# plusieurs entitées peuvent être incluses dans le flux

entity {

  # identifiant unique pour l'entité

  id: "add-a-trip"

  # "type" de l'entité

  trip_update {

    trip {

      # sélectionne l'entité GTFS (trajet) qui sera affectée

      Schedule_relationship: ADDED

      trip_id: "tripid_of_trip_to_copy" #défini dans le flux statique

      route_id: "routeid_of_trip_to_copy" # défini dans le flux statique

                                          # Ne doit PAS contenir de correspondances groupées.

      start_time: "10:00:00" #l'heure locale à laquelle ce trajet ponctuel débute

      start_date: "20180201" #la date locale à laquelle ce trajet ponctuel débute

    }

    ...

  }

}

Ces informations vous-ont elles été utiles ?
Comment pouvons-nous l'améliorer ?

Vous avez encore besoin d'aide ?

Essayez les solutions ci-dessous :

Is there something we can help you with?

Chat with a member of Transit team

Recherche
Effacer la recherche
Fermer le champ de recherche
Applications Google
Menu principal
Rechercher dans le centre d'aide
true
82656
false