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 être plus longue si Google détecte des problèmes dans le flux.
    Les données statiques GTFS 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 également des alertes de service (retards, 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 des services non définis (tracé, ordre des arrêts, horaires des arrêts, 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 la cohérence avec 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.

TOUT DÉVELOPPER TOUT RÉDUIRE

Tracés

 

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

L'ajout d'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

Le fichier calendar_dates.txt vous permet d'activer ou de désactiver explicitement le service par date.

 

Utilisez calendar_dates.txt avec calendar.txt pour définir des exceptions aux formats de service par défaut définis dans le fichier 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, vous devez ajouter une ligne à 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 besoin. 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

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/désactiver rapidement les trajets "par défaut" dans le flux en temps réel selon la situation.

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

Questions fréquentes

TOUT DÉVELOPPER TOUT RÉDUIRE

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. Puis-je le faire ?

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 nous pouvons utiliser l'alerte ci-dessus pour indiquer qu'un autre arrêt intermédiaire peut être emprunté.

Q : Le festival Y a lieu dans la ville. X nouvelles lignes ont été mises en place et quelques modifications importantes ont été apportées au réseau. Que 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). N'hésitez pas à 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.  

# header information
header {
  # version of speed specification. Currently "2.0"
  gtfs_realtime_version: "2.0"
  # determines whether dataset is incremental or full
  incrementality: FULL_DATASET
  # the moment where this dataset was generated on server
  timestamp: 1284457468
}

# multiple entities can be included in the feed
entity {
  # unique identifier for the entity
  id: "add-a-trip"

  # "type" of the entity
  trip_update {
    trip {
      # selects which GTFS entity (trip) will be affected
      Schedule_relationship: ADDED
      trip_id: "tripid_of_trip_to_copy" #defined in Static
      route_id: “routeid_of_trip_to_copy” # defined in Static. 
                                          # Must NOT contain block transfers.
      start_time: “10:00:00” #the local time when this ad hoc trip starts
      start_date: “20180201” #the local date when this ad hoc trip starts
    }
    ...
  }
}

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 la recherche
Applications Google
Menu principal
Rechercher dans le centre d'aide
true
82656
false