FlxPo
commented
2 weeks ago gtfsrouter permet de calculer des itinéraires détaillés avec gtfs_route. Par contre les calculs seront beaucoup plus lents qu'avec gtfs_traveltimes, puisqu'il faudra faire une double boucle par origine et par destination.
J'avais déjà exploré la piste r5py, qui s'était avéré une impasse pour récupérer les distances parcourues.
L'échantillonnage de points au sein des zones de transport me semble être la bonne méthode, c'est ce que l'on fait pour les autres modes. Actuellement la densité de points du réseau viaire sert de proxy à la probabilité des origines et destinations (plus de points en centre ville qu'en dehors des zones artificialisées), mais on pourrait aussi mettre en place un calcul de densité de "points d'interet" basé sur les données OSM ?
Autre approche possible, plus simple : le modèle MODUS en Ile de France utilise l'emprise des bâtiments pour calculer une distance d'accès moyenne au centroide de zones, donc le problème est réduit à un calcul N zones x N zones.
Je pense qu'il faudrait commencer à travailler sur du routing intermodal point à point pour répondre à ces problématiques correctement. Une manière de faire cela serait de transformer les données GTFS en réseau virtuel puis de formet un "supernetwork", avec :
- Des noeuds d'accès au réseau viaire (les gares / stations / arrets).
- Des temps d'accès au réseau dépendant des fréquences de passage des différents services.
- Des temps de parcours entre gares dépendant des temps de trajet du GTFS.
On pourrait alors utiliser cppRouting pour faire des requêtes intermodales : marche + TC, vélo + TC, voiture + TC...
Je lie dans cette issue trois problématiques différentes, mais je pense que c'est mieux de les traiter ensemble :
Actuellement, le code utilise gtfs_traveltimes pour calculer les temps de trajet de tous les arrêts du GTFS à tous les arrêts du GTFS, ce qui demande donc un certain temps. Pour calculer le temps entre deux zones de transport, on prenait la médiane de tous ces trajets. Cela donnait des résultats médiocres sur Genève, à mon avis parce que cela correspond à beaucoup d'itinéraires suboptimaux qui ne sont en pratiques pas empruntés par les utilisateurs (aller d'un arrêt peu fréquenté à un autre arrêt peu fréquenté n'est pas représentatif, et le réseau TC n'est pas optimisé pour cela). Je l'ai remplacé par l'utilisation du minimum, qui marche beaucoup mieux, mais qui n'est pas exempt de problèmes (c'est l'itinéraire entre les deux arrêts les plus proches, donc forcément sous-estimé pour les communes proches entre elles... ce que le forfait-temps d'accès au réseau ne compense pas).
Néanmoins, cette approche de tous les arrêts à tous les arrêts me paraît un peu overkill dans la mesure où nous ne réfléchissons de toute façon qu'à l'échelle communale pour l'instant (et même à l'échelle des IRIS, ça me paraît beaucoup). Enfin, il me semble que ça ne permet pas de savoir quels ont été les gares/stations empruntées, car ça ne fait pas partie des sorties de gtfs_traveltimes.
Je me demande si l'approche suivante pourrait marcher :
Est-ce que gtfsrouter est le plus approprié pour cette approche ? Vu la réduction du nombre de requêtes, peut-être que R5R marcherait également, dans la perspective où l'on veut également s'adapter aux déplacements en rabattement, où R5R pourrait peut-être être utile ?