Aller au contenu

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