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 de 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 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, 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, par exemple pour les changements temporaires qui demandent réactivité et rapidité, vous pouvez modifier 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 (2 à 7 jours ou plus) | Temps réel (env. 1 minute) | |
|---|---|---|
| Ajouter des données au 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 dans le flux | Les suppressions importantes sont signalées comme suspectes et peuvent faire l'objet d'un examen plus long. | Le flux en temps réel n'est pas adapté aux suppressions statiques, mais les alertes sont recommandées pour les suppressions temporaires. |
| Modifier les données du flux | La plupart des changements sont possibles et simples. | Action non acceptée ni encouragée. |
| 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 |
| 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. |
| Statique (2 à 7 jours ou plus) | Temps réel (env. 1 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. |
Dans le flux en temps réel, la position du véhicule (VP) et la mise à jour du trajet (TU) correspondent à des heures d'arrêt modifiées. Les alertes de service dont les valeurs du champ "effect" correspondent à SIGNIFICANT_DELAY et MODIFIED_SERVICE peuvent aussi indiquer cette situation. |
| Statique (2 à 7 jours ou plus) | Temps réel (env. 1 minute) | |
| Ajouter |
Pour activer ou désactiver explicitement le service par date, utilisez le fichier calendar_dates.txt. 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 en temps réel. Le tracé (shape) et l'heure d'arrêt (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. |
| 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 : 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 :
- 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.
- Pointez les trajets concernés vers ce nouveau calendrier (service_id).
- 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.
- 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.
- 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.
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 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
}
...
}
}