Indicateurs de performance du transport collectif basés sur l'estimation des destinations : intégration des données de paiement par cartes à puce et des données de comptage

RÉSUMÉ: Au cours de ces dernières années, les systèmes de collecte automatisée des tarifs par carte à puce (SCAFC) se sont imposés comme un outil incontournable dans les transports publics non seulement pour la gestion des recettes et le contrôle d’accès mais aussi pour l’analyse des comportements de déplacement des usagers et de l’efficacité du réseau. En collectant en continu des dizaines de milliers de transactions journalières ces systèmes génèrent une mine d’informations sur la demande en transport et l’usage des infrastructures. Toutefois, ces données brutes issues des transactions sont souvent incomplètes. En effet, de nombreux systèmes n’enregistrent que les lieux et heures d’embarquement (« tap-in ») sans capturer directement les lieux de débarquement (« tap-out »). De plus, en raison de dysfonctionnement du système ou d’oublis du conducteur lors des changements de direction certaines transactions se retrouvent non seulement associées à des informations erronées mais peuvent aussi perdre des données essentielles comme le trip_id. Ce manque d’information sur le lieu de destination limite l’analyse complète des itinéraires origine-destination et rend nécessaire l’élaboration de méthodes d’estimation de destination avancées. Pour pallier ces limites plusieurs algorithmes d'estimation des destinations ont été développés au fil des années. Ceux-ci reposent sur l’utilisation de critères basés sur les séquences d'arrêts, l’historique des transactions individuelles et des modèles probabilistes tels que l’estimation de la densité du noyau des probabilités spatio-temporelles visant à reconstituer les itinéraires. Ces améliorations ont permis d’accroître le nombre de destinations estimées. Toutefois, certains déplacements notamment les déplacements unitaires plus difficiles à analyser ne peuvent être entièrement résolus avec ces méthodes. Pour surmonter ce problème, une amélioration de l'algorithme d'estimation des destinations est proposée dans ce mémoire. Ce modèle intègre les critères traditionnels issus des travaux antérieurs combinés à de nouveaux critères. Il repose sur trois nouveaux critères basés sur les séquences d'arrêts avec une version révisée du critère historique ainsi que sur deux critères exploitant les données de comptage : le "Tirage Aléatoire Pondéré" (TAP) qui utilise les données historiques de toutes les transactions des passagers et l'"Événement Final" (F_Event) appliqué uniquement lorsque les autres critères ne permettent pas d'estimer une destination. L'amélioration continue du modèle permet de reconstituer les itinéraires individuels avec une plus grande précision. Ces reconstitutions offrent aux planificateurs une vision détaillée des trajets effectués et facilitent l'analyse des profils de charge des véhicules. L'exploitation de ces données permet d’élaborer des indicateurs de performance pour la gestion et à l'optimisation du réseau de transports en commun. Ces indicateurs incluent notamment l'offre de service (la ponctualité, la fréquence de passage, vitesse commerciale, etc.) et la demande (passagers-kilomètres, la charge maximale à bord, taux de charge, etc.). Ces indicateurs aident aussi à analyser les caractéristiques des usagers selon les titres de transport utilisés. Pour le développement de l'algorithme et l'analyse des résultats le projet s'appuie sur les données de transactions et de comptage de 79 054 cartes à puce enregistrées dans la ville de Besançon, en France. Ces données fournies par Keolis, un opérateur majeur de transport public franco-québécois, couvrent une période de deux semaines du 3 au 16 juin 2024 avec un total de 766 165 transactions recensées. L'algorithme amélioré se décompose en quatre étapes : 1. Prétraitement des données : Lecture des données GTFS (General Transit Feed Specification) pour créer de nouveaux fichiers consolidant les services proposés par Keolis et suppression des doublons. Une table des séquences d'arrêts desservies associée aux trips_id correspondants et indiquant la fréquence relative de chaque séquence pour une même ligne et direction est également construite. 2. Attribution des caractéristiques aux transactions : Identification du type de journée (jour ouvrable/fin de semaine), période de la journée (nuit, matin, après-midi et soir), ligne et direction et correction des incohérences dans les transactions (par exemple trip_id inexistant ou inadapté). Un regroupement des transactions par véhicule, date, ligne et trip_id est effectué afin d'affiner l'attribution des séquences d'arrêts. Enfin, chaque transaction est classifiée comme première, intermédiaire ou dernière de la journée. 3. Application des critères d'estimation des destinations : Les critères sont appliqués successivement dans un ordre précis jusqu'à ce qu'une destination puisse être estimée. Critère 1.1 : Séquence de déplacement (54,87%) : lorsqu'une transaction est suivie d'une autre. • Critère 1.2 : Retour à domicile (22,20%) : ce critère ne peut s’appliquer qu’à la dernière transaction de la journée et utilise comme référence pour l’estimation de la destination le premier arrêt d’embarquement de la journée. • Critère 1.3 : Déplacement du prochain jour (3,07%) : ce critère prend comme station de référence la station d’embarquement de la première transaction du lendemain. • Critère 1.4 : Déplacement du jour précédent (1,61%) : ce critère prend comme station de référence la station d’embarquement de la première transaction du jour précédent. •Critère 1.5 : Déplacement des jours ultérieurs (0,51%) : Si aucune destination ne peut être estimée avec les critères précédents un assouplissement de la référence temporelle est appliqué. Au lieu de se limiter à la première transaction du jour suivant l'analyse s'étend à la première transaction enregistrée entre le surlendemain et une semaine plus tard (J+2 à J+7). Cette approche suppose que l’usager suit un trajet habituel avec des interruptions possibles comme les week-ends, jours fériés ou déplacement de courte durée. Pour garantir la cohérence de l'estimation la station de référence retenue doit se situer sur la même ligne que celle du jour étudié mais dans la direction opposée. • Critère 1.6 : Déplacement des jours antérieurs (0,43%) : Comme pour le critère 1.5 mais avec une analyse de la dernière transaction des jours allant de J-2 à J-7. • Critère historique (H) (3,32%) : Exploitation de l’historique des transactions de la carte étudiée. Cette approche se base sur la recherche de transactions antérieures similaires en tenant compte de plusieurs critères comme le type de journée, la période de la journée ainsi que la ligne et la direction empruntées. Cette étape de l’algorithme permet ainsi d’estimer 86,01% des destinations.Utilisation des données de comptage et des critères supplémentaires : Pour les transactions restantes (13,99%), le critère TAP (Tirage Aléatoire Pondéré) est appliqué qui exploite les données de comptage et l’historique des transactions de toutes les cartes à puce pour attribuer une destination potentielle. La sélection s’effectue parmi les destinations historiques des transactions similaires en prenant en compte le type de journée, la période de la journée et la ligne-direction de la transaction en cours. Avant l’application du TAP, un prétraitement des données est nécessaire. Celui-ci inclut le regroupement des transactions associées à une même course et la mise en correspondance des descentes estimées avec les critères précédents et les données de comptage. Cette étape permet d’estimer le nombre de descentes restantes par station, par trip_id et par jour améliorant ainsi la précision de l’algorithme. L’application du TAP permet d’estimer la destination de 13,61 % des transactions totales laissant ainsi 0,38% de transactions non traitées. Enfin, ces transactions résiduelles sont soumises à un dernier critère : le critère (F_Event) "Événement Final". Celui-ci attribue une destination parmi les stations restantes à desservir indépendamment des caractéristiques de la transaction. Afin de limiter l’aspect probabiliste de cette approche les données de comptage sont également exploitées en ajoutant les descentes estimées par le critère TAP. En combinant ce dernier critère avec les autres critères l’ensemble des transactions a pu être traité avec une approche progressive et optimisée. Bien que l'absence de données "tap-out" empêche une vérification directe des résultats obtenus ceux-ci s'appuient sur une optimisation rigoureuse de l'algorithme garantissant leur cohérence et leur fiabilité. De plus, la loi des grands nombres assure que les écarts enregistrés localement sont compensés à plus grande échelle renforçant ainsi la pertinence des indicateurs de performance du transport collectif déduits. En conclusion, ce mémoire propose un algorithme amélioré d'estimation des destinations intégrant les données de comptage pour traiter les déplacements les plus complexes. Cet algorithme intègre également des méthodes de traitement des données GTFS et des données de transactions dans le but de les rendre plus facilement manipulable pour optimiser l’estimation des destinations pour chaque transaction. Le mémoire fournit également une présentation des résultats sous forme d’indicateurs de performances du transport collectif dans une perspective de pouvoir analyser plus finement les déplacements des usagers et l’évaluation de l’efficacité du réseau. Toutefois, des limites liées à l'absence de données "tap-out" empêche la validation avec exactitude des destinations estimées. De plus, même si les données de comptage sont intéressantes elles ne sont pas disponibles pour tous les transports collectifs et peuvent contenir des erreurs. Si à l'avenir des données "tap-out" fiables deviennent accessibles il serait alors possible d'affiner davantage la précision du modèle en validant directement les résultats obtenus. ABSTRACT: In recent years, Automated Fare Collection (AFC) Systems using smart cards has become an essential tool

Récupéré en direct depuis OpenAlex et désinversé. Les résumés ne sont pas conservés dans cette base de données : les index inversés représentent 8,6 Go des 9,3 Go de texte de la base, et le serveur dispose de 13 Go libres.