Données de transport planifiées
GTFS : calendrier de service et exceptions
Le jour de voyage dépend du calendrier du service et de ses exceptions. Ce dossier aide à expliquer un trajet affiché un jour régulier mais retiré lors d’un jour particulier.
Références consultées aux dates indiquées dans chaque source · Mis à jour le · Méthode éditoriale de Performance Voyage
Quel rôle dans votre organisation ?
Reliez course, service_id, date de service et collecte du flux. Examinez calendrier régulier et exceptions ensemble, ou le modèle qui décrit chaque date lorsque le flux l’utilise. Un changement de date civile autour de minuit demande aussi de conserver le jour de service. La publication doit préciser la nature planifiée de l’information et la source de toute alerte temps réel ajoutée.
GTFS — données de transport figure dans la famille Mobilité et transports. Les prix, pays couverts, niveaux de service et droits du compte ne sont pas certifiés par ce dossier. Faites-les préciser dans une proposition datée.
Source officielle de l’entrée ↗ · Retrouver la fiche du répertoire
Ce que les sources documentent
GTFS Schedule : calendar et calendar_dates
calendar_dates active ou retire un service pour une date ; ses exceptions modifient le calendrier régulier correspondant.
Spécification de données planifiées ; un calendrier GTFS ne confirme ni circulation réelle, ni billet réservé, ni disponibilité d’un véhicule privé.
Consultée le
Consulter la source 1 ↗La suite propose nos contrôles de sélection : elle ne décrit pas des tests exécutés sur un compte fournisseur. Une documentation peut évoluer ; relisez la version applicable avant de développer ou de signer.
Quatre ensembles de données à rapprocher
| Ensemble | À collecter | Contrôle proposé |
|---|---|---|
| Flux | Producteur, version et collecte. | Retrouver la source utilisée. |
| Service | Course et service_id. | Relier la course au calendrier. |
| Calendrier | Période et jours réguliers. | Vérifier la date de service. |
| Exception | Date et ajout ou retrait. | Appliquer l’exception pertinente. |
Conservez identifiant, source, date et résultat dans le registre de comparaison. Travaillez avec des données anonymisées et les accès de test autorisés.
Un scénario à faire rejouer pendant le pilote
Scénario fictif : une navette touristique circule en semaine mais est retirée un jour férié. Préparez la date habituelle et la date d’exception avec le même service_id. Examinez aussi un trajet après minuit, puis un flux actualisé qui modifie l’exception. L’utilisateur doit retrouver la période et la date d’information ; il ne doit pas lire une planification comme une confirmation de passage en temps réel.
Le trajet affiché s’explique par service, calendrier et exception. Les limites de fraîcheur et les éventuelles informations temps réel sont indiquées séparément.
Préparez les mêmes exemples pour les autres acteurs de la catégorie Mobilité et transports. Comparez les responsabilités et les preuves sur votre tâche, avec la grille d’évaluation et le coût complet.
Définir les responsabilités et les conditions de fonctionnement
Préparer les acteurs de ce parcours avant la démonstration.
Donnée
Intervenants à associer : Producteur et intégration
Relier course et calendrier.
Affichage
Intervenants à associer : Produit et information voyageurs
Expliquer planification et limite.
Reprise
Intervenants à associer : Exploitation et éditeur
Traiter le flux corrigé.
Comparer le coût du parcours réellement exploité
Incluez collecte, validation, traitement des exceptions et mise à jour des pages. Un flux ouvert demande encore une exploitation et une maintenance.
Préparer la continuité des dossiers ouverts
Conservez producteur, version et règles de service. En cas de remplacement du flux, documentez les correspondances et les parcours devenus incomparables.
Erreurs à éviter dans la comparaison
- Ignorer calendar_dates lors d’un jour exceptionnel.
- Confondre date civile et jour de service.
- Présenter le flux planifié comme un passage confirmé.
Marquez un point non démontré comme « à confirmer ». Il reste distinct d’un échec observé et d’une fonction annoncée. Une décision fiable peut retenir un périmètre plus restreint si les responsabilités et la reprise sont maîtrisées.
Conserver les résultats du pilote
Utiliser la fiche de contrôle de ce parcours et le registre de recette associé. Garder les résultats observés distincts des points à confirmer et attribuer les suites aux intervenants concernés.
Questions fréquentes
calendar_dates peut-il retirer un service ?
La référence décrit ajout et retrait pour une date. Appliquez l’exception au service concerné.
Un trajet GTFS constitue-t-il une réservation ?
Non. Le flux décrit des données de transport ; la réservation et les titres relèvent d’un autre engagement.
Pourquoi conserver la version du flux ?
Elle permet de relire les calendriers et exceptions qui ont produit l’affichage.
Quelles preuves conserver à la fin du pilote ?
Conservez producteur, version et règles de service. En cas de remplacement du flux, documentez les correspondances et les parcours devenus incomparables.