GTFS-Flex¶

GTFS Flex est un projet d’extension du GTFS Schedule qui vise à faciliter la découvrabilité des services de transport à la demande.

Pour l’essentiel, il a été adopté dans GTFS en mars 2024. Quelques exemples peuvent être trouvés sur cette page montrant ce qui peut être modélisé en utilisant la partie officiellement adoptée de GTFS Flex.

🤔 Les services comme Dial-a-Ride sont souvent ignorés par les passagers, qui n’ont parfois même aucune idée de leur existence. Ce manque d’accessibilité est un problème pour les agences de transport en commun, les planificateurs d’itinéraire et les usagers. Imaginez un groupe de touristes arrivant à votre aéroport local et souhaitant rejoindre une zone rurale qui n’offre qu’un service de bus à la demande. Les touristes consultent leur application de planification d'itinéraires préférée et ne trouvent pas d’option de transport public viable. Ils finissent par louer une voiture. En tant que touristes, ils manquent tous vos dépliants papier affichés dans le couloir annonçant le service à la demande. Non seulement votre service est sous-utilisé, mais il ne dispose pas non plus de la visibilité nécessaire pour répondre à la demande actuelle et future des passagers. C’est là qu’intervient GTFS-Flex. GTFS-Flex aide les passagers à découvrir votre service, afin qu’ils profitent des services que vous avez travaillé dur pour promouvoir.

Parcours utilisateur GTFS-Flex

🔮 MobilityData s’attend à ce que GTFS-Flex ouvre la porte à une standardisation plus approfondie du transport réactif à la demande, y compris une expansion dans les composants transactionnels et en temps réel utilisant GTFS-OnDemand. Nous préparons une proposition de stratégie pour gérer au mieux le nombre croissant de modes de transport et la complexité des concepts dans ce domaine.

Voir la proposition complète

Dernière pull request¶

L’extension décrit les services qui fonctionnent selon un horaire, mais incluent également une ou plusieurs fonctionnalités flexibles, telles que :

Service Dial-a-Ride : le véhicule dessert une zone où les prises en charge et les retours sont autorisés pendant certaines heures de service.
Service de déviation d’itinéraire : le véhicule dessert un itinéraire fixe et un ensemble d’arrêts ordonnés, et peut faire un détour pour prendre ou déposer un passager entre les arrêts.
Service point à zone : le passager peut embarquer à un arrêt fixe comme une gare, puis descendre n’importe où dans une zone, ou vice versa. Les départs de certains endroits sont programmés ou synchronisés avec d’autres services.
Point de déviation ou service de point de contrôle : le passager peut embarquer à un arrêt fixe, puis descendre n’importe où parmi une liste d’arrêts non ordonnée, ou l’inverse. Le chauffeur dessert uniquement les arrêts pour lesquels une demande est faite.

Pour plus d’informations, veuillez consulter proposition originale et issue#382(fermé depuis que nous avons modifié la portée).

Lors de la réunion de travail du 28 juin, il y a eu un accord au sein de la communauté du groupe pour poursuivre une itération qui couvre tous les domaines actuellement produits et consommés. Par conséquent, tous les champs qui apparaissent comme « en discussion » dans le traqueur d’adoption sont inclus dans cette pull request.

Les changements dans cette pull request sont :

Modifier le fichier :
- Modifier stop_areas.txt pour permettre le regroupement d’emplacements et/ou d’arrêts GeoJSON qui permettent de spécifier des groupes prédéterminés de ces fonctionnalités sur lignes individuelles de stop_times.txt.
- Modifier stop_times.txt pour clarifier les éléments de la spécification actuelle nécessaires pour informer les consommateurs de données sur la façon d’interpréter les fichiers et champs ajoutés et étendus
Étendre le fichier :
- Étendre stop_times.txt avec start_pickup_drop_off_window et end_pickup_drop_off_window pour définir l’heure à laquelle le service de transport à la demande devient disponible/se termine dans un emplacement GeoJSON, une zone d’arrêt ou un arrêt.
- Étendre stop_times.txt avec pickup_booking_rule_id et drop_off_booking_rule_id pour définir des liens vers les règles de réservation
Ajouter un nouveau fichier :
- locations.geojson, pour définir des zones (Polygon ou Multipolygon) où les passagers peuvent demander une prise en charge ou un retour.
- booking_rules.txt, pour définir les règles de réservation qui fournissent aux passagers des informations sur la manière de demander un service.

Voici un exemple de données pour RufBus à Angermünde et Gartzer, Allemagne. L’image ci-dessous est un exemple illustrant la façon dont les données pourraient être présentées dans un planificateur de voyage :

Visitez la page Pull Request pour lire la description complète et contribuer à la conversation.

Voir la Pull Request

Rejoindre #gtfs-flex sur Slack

Premières mises en œuvre¶

Voici quelques exemples de premières implémentations de GTFS-Flex. Pour trouver les implémentations actuelles, veuillez consulter la Mobility Database.

Contactez-nous pour ajouter votre implémentation GTFS-Flex à cette page

Contactez-nous

Suivi des adoptions¶

Actuel¶

Demandez une modification Ajoutez votre organisation (consommateurs) Ajoutez votre organisation (producteurs)

Historique¶

2013 : Proposition originale écrite par Brian Ferris (Google)
2016 : Début des discussions GTFS-Flex GitHub
2017 : Programme sandbox Mobility on Demand (MOD) (FTA, Vermont DOT, OTP)
2018 : MobilityData devient steward GTFS-Flex et propose GTFS-Flex v2
Novembre 2020 : Répertoire de la version à jour de GTFS-Flex et OTP2 ingère les données GTFS-Flex v2
Mai 2022 : Début du pilote MnDoT (Cambridge Systematics, MNDoT, Token Transit, Transit, Trillium (OptiBus)).
Mai 2023 : Travaux sur GTFS-Flex : Début de la découverte du service
Juin 2023 : Réunion de travail conceptuelle sur GTFS-Flex
Juillet 2023 : Publication de la Pull Request#388
Août et septembre 2023 : Discussions « GeoJSON dans GTFS ? »
Mars 2024 : GTFS Flex a été officiellement adopté