Comparatif documenté · 3 périmètres
Horaires, temps réel et vélos partagés : quel flux pour quel usage ?
Un horaire prévu, une perturbation et la disponibilité d’un vélo répondent à des questions différentes. Choisissez le flux selon la décision du voyageur, puis vérifiez sa couverture locale.
Documents consultés le . Les faits ci-dessous sont attribués à leurs sources ; les scénarios et conseils sont éditoriaux. Le périmètre commercial, les prix et les droits de votre compte restent à confirmer.
Références documentaires et points à vérifier
Les lignes comparent des rôles et des conditions d’accès. Un point non documenté reste une question à poser, sans lui attribuer une note négative. Sur téléphone, chaque périmètre se lit dans une carte.
| Périmètre et rôle | Documenté | Limite | À demander |
|---|---|---|---|
GTFS Schedule Décrire un réseau et son service prévu | Le format décrit notamment agences, arrêts, lignes, courses, heures aux arrêts et calendriers de service. GTFS : référence Schedule ↗ | Un horaire planifié ne prouve pas la position actuelle d’un véhicule ni la disponibilité d’un billet. | Le calendrier couvre-t-il la date recherchée et les exceptions locales ? |
GTFS Realtime Compléter le service avec des mises à jour | Le format prévoit des mises à jour de courses, des positions de véhicules et des alertes de service, reliées au réseau décrit. GTFS : référence Realtime ↗ | Un flux peut ne couvrir qu’une partie de ces objets. L’existence du standard ne garantit pas leur présence chez l’opérateur. | Quels objets sont publiés et comment détecter une information devenue trop ancienne ? |
GBFS Décrire la mobilité partagée disponible | GBFS organise des informations publiques en lecture sur les services de mobilité partagée, leurs stations et leur disponibilité. GBFS : documentation officielle ↗ | Lire une disponibilité n’attribue pas un véhicule et ne réalise pas sa réservation. | Le service couvre-t-il stations, véhicules et zones utiles au trajet étudié ? |
Commencer par la question du voyageur
Pour organiser un trajet à une date future, le service prévu constitue une base. Pour accompagner un départ immédiat, une mise à jour peut apporter une information différente. Pour rejoindre une station de vélos, la présence d’une station ne suffit pas : l’utilisateur doit comprendre l’état pertinent et le moment où il a été observé.
Évitez de choisir un flux pour sa popularité. Décrivez d’abord la tâche, la date et le territoire, puis examinez les objets nécessaires. Une couverture partielle doit rester visible dans le parcours.
Rapprocher les identités et les dates
Conservez les identifiants utilisés par chaque source et documentez les correspondances. Un nom d’arrêt peut désigner plusieurs accès ou plusieurs objets. Le rapprochement doit éviter de rattacher une alerte ou une disponibilité au mauvais lieu.
Affichez le rôle de l’heure : prévu, mis à jour ou observé. Prévoyez un état lorsque la donnée récente manque, afin que l’interface ne présente pas une ancienne observation comme une garantie actuelle.
Séparer information et transaction
Une suggestion de trajet doit expliquer ses limites avant d’orienter le voyageur vers une réservation ou un déverrouillage. Le service transactionnel possède ses propres droits, conditions et résultats. Ne déduisez pas leur existence du seul accès à un flux public.
La recette doit couvrir une journée sans service, une perturbation et un flux indisponible. Les réponses servent à décider ce que l’interface peut annoncer et quel contact ou alternative elle peut proposer.
Quatre cas pour rendre la comparaison vérifiable
Utilisez un environnement et des données de test autorisés. Conservez les réponses, les opérations manuelles et les points qui restent inconnus.
| Situation | Contrôle | Preuve utile |
|---|---|---|
| Date hors calendrier | Ne pas annoncer un service sans couverture documentée. | Date recherchée, plage du calendrier et résultat affiché. |
| Arrêt homonyme | Rattacher la mise à jour à l’objet et au lieu corrects. | Identifiants source et correspondance vérifiée. |
| Flux ancien | Afficher la limite de fraîcheur retenue par le projet. | Date de dernière observation et état présenté au voyageur. |
| Vélo annoncé puis absent | Expliquer que la lecture du flux ne constitue pas une attribution. | Parcours d’information et résultat du service opérationnel, testés séparément. |
Télécharger le registre de comparaison et préparer le contrôle d’accès API.
Questions fréquentes
GTFS permet-il d’acheter un billet ?
Ces flux décrivent le service et ses mises à jour. L’achat demande un service transactionnel et ses conditions propres.
Faut-il combiner les trois formats ?
Seulement si le parcours utilise leurs objets respectifs. Une intégration plus large sans usage défini ajoute des correspondances à maintenir.
Un standard garantit-il la couverture d’une ville ?
Non. Vérifiez l’émetteur, le périmètre, les objets publiés et les dates réellement disponibles.