🚌 Générer les déplacements avec dodgr (anciennement r5py) about mobility HOT 22 OPEN

L'ajout de ces fonctionnalités nécessite d'installer r5py et osmium.

• r5py est basé sur r5, qui est un outil java. Je pense qu'il faut installer openjdk pour éviter les problèmes de version et d'installation de java pour des utilisateurs sans droits admin.
• Osmium tool est distribué comme package linux ou conda.

C'est plus complexe pour l'utilisateur, mais il va falloir qu'on se mette à packager mobility avec conda.

La licence d'anaconda n'est pas très open source compatible, sauf si on se limite aux packages conda-forge ce qui est le cas de osmium et openjdk (https://community.anaconda.cloud/t/is-conda-cli-free-for-use/14303).

@Mind-the-Cap OK pour toi ?

from mobility.

Non, à ma connaissance il n'y a pas de couche ou de jeu de données existants. Il va falloir individualiser l'approche par pays (et même dans ce cas, pas évident de trouver la bonne année).

Pour la Suisse, parfait si on peut adopter cette stratégie.

from mobility.

Pour référence, le fonctionnement de l'aglorithme mutlimodal de R5 est expliqué ici : UrbanAnalyst/gtfsrouter#73.

from mobility.

Je n'ai jamais testé ça mais est ce qu'on pourrait utiliser un cache de l'environnement complet (python + R), pour accélérer les tests ? https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows

On pourrait aussi préparer et stocker les données à télécharger pour que le test se concentre sur l’exécution du code de préparation des données / modélisation ?

OK pour les deux points qui peuvent attendre, je les mentionnais surtout pour ne pas les oublier ensuite.

Pour les GTFS non alignés, sans avoir testé, je pense qu'il pourrait manquer des données (si je merge deux GTFS, un de 2023 et un de 2024 par exemple, dans un cas extrême).

Pas de raison pour gtfs_routes_types.xlsx, c'est juste plus facile à manipuler dans Excel vu que c'est un fichier créé manuellement (mais on pourrait le passer en csv).

from mobility.

Nouveau commit pour créer une classe Trips, qui permet d'échantillonner des déplacements sur la base d'une population. J'ai repris les fonctionnalités de la classe TripSampler, qu'on pourra supprimer.

Prochaine étape la localisation des déplacements à partir du modèle de radiation !

from mobility.

Le code d'exemple est ici : https://github.com/mobility-team/mobility/blob/stage-2-model/examples/trip_localizer/example.py

OK pour les remarques, je crée des issues séparées :

• #96
• #97
• #98
• #99
• #100
• #101

from mobility.

Je travaille sur ce sujet dans la branche "stage-2-model" : https://github.com/mobility-team/mobility/tree/stage-2-model.

Le modèle "étape 1" consiste à échantillonner simplement les déplacements issus des enquêtes. Le modèle "étape 2" consiste à préciser certains déplacements en appliquant un modèle de choix des destinations et des modes de transport. Plus d'infos dans la présentation de Mobility dans la PR en cours sur la documentation : https://github.com/mobility-team/mobility/blob/ab0a9da93df56d9ffb8480a8f31e91caf7f80575/docs/source/presentation.md

Les différentes étapes à implémenter sont les suivantes :

• Fonction get_transport_zones : crée une geodataframe de zones de transport autour d'une commune donnée, à partir des données IGN. https://github.com/mobility-team/mobility/blob/stage-2-model/mobility/transport_zones.py
• Fonction get_osm : récupère les données OSM à partir de la limite des zones de transport. https://github.com/mobility-team/mobility/blob/stage-2-model/mobility/parsers/get_osm.py
• Fonction get_travel_costs : calcul des temps et distances de transport entre les zones de transport, en fonction d'un mode de transport principal utilisé (voiture, vélo, marche, TC).
• Fonction get_utilities : calcul des utilités (opposé du coût généralisé de transport) entre les zones de transport, en fonction du mode et de coûts unitaires temps / distances / ...
• Test du RadiationModel avec les utilités calculées.
• Fonction get_od_probabilities : calcul de la probabilité de choisir une destination et un mode de transport en fonction d'une origine et d'un motif de déplacement.
• Fonction / classe TripLocalizer : modification des échantillons générés par le TripSampler en fonction des probabilités P(D, mode | O, motif).

from mobility.

@FlxPo OK pour moi pour openjsk et osmium, il faudra qu'on ait une belle doc dès le début ! Merci pour toutes les avancées surtout !

Pour les fonctions OSM et transport, elles semblent ne fonctionner que pour la France, or la première application sera franco-suisse, quel impact ça aurait sur le code ? On n'a pas encore décidé de norme pour ça, mais j'imagine qu'on pourrait avoir une fonction get_osm globale qui appelle par exemple get_french_osm ou get_swiss_osm selon les besoins ?

from mobility.

Il va falloir adapter le code.

La stratégie actuelle est la suivante:

• On part du code INSEE de la commune au centre de notre zone d'étude.
• On récupère les limites administratives des communes voisines (à partir des EPCI ou d'un rayon autour de la commune centrale).
• On intersecte ces limites administratives avec les régions françaises des extracts geofabrik.
• On télécharge les extracts geofabrik correspondants, puis on les filtre.

Donc on pourrait adopter la même stratégie pour la Suisse:

• Récupérer les limites administratives des communes.
• Récupérer et filtrer l'extract geofabrik de la Suisse.

On pourrait procéder de la même façon pour les autres pays limitrophes.

Est ce que tu sais s'il existe une couche SIG à jour des limites communales européennes ? Pas évident d'avoir quelque chose à jour ou au contraire un peu en retard pour avoir les bons identifiants (suite aux fusions / splits de communes)...

from mobility.

Le développement avec r5py ne se passe pas comme prévu:

• Le calcul des temps de parcours many-to-many est OK (en faisant quelques vérifications manuelles avec Google Maps), bien qu'assez lent.
• Le calcul des distances parcourues à partir d'itinéraires détaillés est beaucoup plus compliqué. Non seulement c'est très lent, mais en plus les itinéraires trouvés par l'algorithme sont parfois assez aberrants et doublent le temps de trajet (par rapport à la première requête "travel time only").

En fait ce ne sont pas les mêmes algos qui sont utilisés par R5 dans ces deux cas de figures, et le problème a l'air assez commun : voir par exemple conveyal/r5#863.

Les développeurs de R5 indiquent:

We haven't used the point-to-point routing server for many years and it is not actively maintained. [...] The point-to-point routing code paths do work somewhat differently than the one-to-many routing we use heavily for travel time mapping and accessibility calculations. We have not (yet) removed the point-to-point functionality in case anyone finds it useful, but realistically we probably won't spend time exploring issues with this part of the codebase.

Donc la piste r5py semble s'arrêter là, et je ne vois pas d'alternative en Python.

Je propose donc d'utiliser R et le package dodgr, qui est très rapide et permet de calculer les temps et distances des trajets directement. C'est ce que j'utilisais jusqu'à présent, donc j'ai déjà quelques scripts à réutiliser. A priori on peut utiliser conda pour gérer l'installation de R et des packages nécessaires.

Je peux limiter le code R au maximum, mais mobility deviendrait un projet multi-langage... OK pour toi @Mind-the-Cap ? Un avis @louisegontier ?

Autre alternative, utiliser des outils comme Valhalla, mais c'est encore plus compliqué, il faut Docker, lancer un serveur de calcul...

from mobility.

@FlxPo quel est l'impact de disposer uniquement du temps de parcours many-to-many ? Impossibilité de connaître les modes utilisés et donc les empreintes carbones ?

Si on est sur ce niveau d'impact, totalement ok pour moi de passer sur R et sur un projet multi-langages. Je préfère ça à Docker. Il faudra que je me renseigne un peu plus sur les stratégies de test et de couverture du code dans ce cas !

from mobility.

Si on ne connaît que le temps de parcours, on doit se contenter de la distance à vol d'oiseau pour estimer les distances parcourues, ce qui me semble une assez grosse approximation pour les déplacements courte / moyenne distance. La distance est une variable importante, pour le calcul de l'empreinte carbone, et potentiellement pour les modèles de choix destination / mode (si on intègre des coûts en €/km pour la consommation de carburant par exemple).

from mobility.

J'ai fait un commit avec mes modifications en cours : 27b2313.

La première étape de calcul des temps et distances de parcours avec dodgr est OK, avec la fonction prepare_dodgr_graph (qui appelle le script R du même nom) qui transforme les données OSM en graphe utilisable ensuite pour calculer des itinéraires.

J'ai commencé à mettre en place la stratégie de configuration via des variables d'environnement (voir https://github.com/mobility-team/mobility/blob/27b2313218d20a651c80856275885ee39d39daa2/examples/travel_costs/travel_costs.py pour un example).

Pour le moment le code appelle la version de R installée sur mon poste par ailleurs, mais ça ne marchera pas pour la plupart des utilisateurs : il faut mettre en place l'installation de R via conda / mamba dans un environnement dédié, avec les installations des librairies utilisées ensuite (sf, dodgr...).

from mobility.

J'ai fait un très gros commit avec pas mal de changements :

Process d'installation

• Remplacement du script setup.py par un fichier pyproject.toml, pour mettre à jour le process de création de package : https://packaging.python.org/en/latest/tutorials/packaging-projects/
• Création d'un fichier environment.yml pour gérer l'installation des dépendances non installables avec pip : R, osmium, geopandas.
• Pour le moment la dernière version n'est pas sur pypi, donc le process complet est le suivant :
  • Installer mamba avec miniforge.
  • Aller dans le dossier qui contient le code du repo : cd path/to/mobility-repo.
  • Créer un environnement pour mobility à partir du fichier environment.yml : mamba env create -n mobility -f environment.yml.
  • Activer l'environnement mobility : mamba activate mobility.
  • Installer mobility avec pip : pip install -e .
  • Utiliser mobility dans Python / Spyder / ... avec import mobility (script d'exemple ici).
  • Il faut appeler mobility.setup avant de pouvoir utiliser mobility : la fonction va fixer plusieurs variables d'environnement qui peuvent être nécessaires (où stocker les fichiers temporaires, info sur le proxy pour les requêtes http...) et installer si besoin les packages R.

Utilisation de dodgr

• La classe TravelCosts sert à calculer les coûts (distance / temps) de transport entre toutes les zones de transports, pour un mode donné.
• Les étapes sont les suivantes :
  • Récupérer, filtrer et fusionner les données OSM des régions françaises qui intersectent les zones de transport (geofabrik).
  • Générer un graphe dodgr du réseau de transport pour le mode choisi.
  • Générer des sous zones de transports en fonction des noeuds du réseau de transport (dès que la densité de noeuds dépasse 0.05 points/km²).
  • Calculer les distances / temps de transport entre ces sous zones de transport.
  • Calculer les distances / temps médians entre zones de transport.

Stratégie de cache des résultats

• Les différentes étapes de calcul prennent du temps et génèrent des fichiers de taille importantes (extracts OSM geofabrik, graphe dodgr...), donc il y a un intérêt à ne pas relancer toutes les étapes à chaque nouveau run de mobility.
• J'ai donc créé une classe Asset, qui permet de gérer un cache associé aux résultats de TransportZones, OSMData, TravelCosts.
• Chacune de ces classes hérite de la classe Asset, et implémentent des méthodes create_and_get_asset et get_cached_asset qui sont appelées lorsqu'on essaie d'accéder au résultat avec object.get().
• Ce pattern "créer et charger" lors de la première utilisation et de "charger" lors des utilisations suivantes se retrouve dans différents endroits de mobility (notamment toutes les fonctions qui téléchargent et traitent des données depuis data.gouv.fr), donc on pourrait harmoniser tout cela.

Fork du package R osmdata

• Le package osmdata permet de charger les données OSM dans un format utilisable par dodgr.
• L'implémentation actuelle est très lente pour les fichiers de taille un peu conséquente (à partir d'environ 100 communes).
• J'avais fait une PR sur le projet mais elle n'avait pas été intégrée, donc j'ai créé un fork puis une version binaire du package, à distribuer avec mobility (pour le moment uniquement windows).

from mobility.

Merci Félix !

Pour le processus d'installation, j'ai pu tester et ça marche ! Je rajouterai peut-être des détails sur l'utilisation de Spyder.
J'ai renommé setup.py en set_params.py pour éviter les confusions avec le setup.py habituel des librairires Python.

Pour l'utilisation de Dodgr, ça semble marcher aussi, même s'il n'y a pas encore de visualisation des résultats. Je vais réfléchir à une stratégie de tests qui ne soit pas trop lourde...

Le cache des résultats est une très très bonne chose. Il faudra qu'on adapte le code existant pour suivre la même logique en effet, mais ce n'est pas la première des priorités je pense.

Sur le fork d'osmdata, je ne suis pas hyper à l'aise avec l'idée de distribuer un package en parallèle de mobility, surtout si c'est limité à un seul OS, et que le seul impact en dehors de ça est une perte de performances (ça me paraît plus utile de développer nos stratégies de cache par exemple...)

J'en ai fait une PR pour pouvoir faire tourner les tests et évaluer le taux de couverture : #94

from mobility.

Pour le fork d'osmdata, c'est sûr que ce n'est pas idéal. Je vais essayer de refaire une PR sur le projet, mais à l'époque elle avait été rejetée sans que je comprenne bien pour quoi : la différence de temps de calcul est vraiment extrêmement importante.

Je persiste à penser que c'est nécessaire pour l'étude de territoires un petit peu conséquents. Mes tests sur la version originale d'osmdata n'aboutissaient parfois même pas après plusieurs heures...

from mobility.

Je viens de faire un commit avec les changements suivants :

• Création d'une classe GTFS qui s'occupe de :

  • Identifier quels sont les opérateurs qui passent par les zones de transport que l'on étudie, à partir de transport.data.gouv.fr.
  • Télécharger le dernier fichier GTFS de chaque opérateur.
  • Agréger les fichiers GTFS et créer un objet R gtfsrouter qui permet de faire le routing ensuite.

• Création d'une classe PublicTransportTravelCosts qui s'occupe de :

  • Calculer les temps et distances de transport médianes entre zones de transport.

Quelques points à noter et pistes d'amélioration :

• Les temps et distances de transport sont mesurées d'arret à arret, aucun temps de rabattement diffusion n'est prévu pour le moment. On pourrait prendre des valeurs forfaitaires en fonction de la taille des zones de transport pour commencer.
• Les zones de transport à l'échelle communale sont parfois très vastes, donc la médiane n'est pas toujours très représentative des temps de transport réels des usagers. Peut être faudrait il descendre au niveau IRIS, si OK niveau temps de calcul et disponibilité des données d'entrée ?
• gtfsrouter ne permet pas de savoir efficacement tous les modes utilisés lors d'un trajet (seulement le premier et le dernier). On ne sait pas non plus la proportion de chaque mode utilisé. Donc on fait une approximation lors du calcul des émissions par exemple. L'auteur de gtfsrouter devrait pouvoir développer ça : UrbanAnalyst/gtfsrouter#107.
• Aucune vérification n'est faite pour vérifier que les GTFS sont bien "alignés" du point de vue des dates.
• La correspondance entre zones de transport et url des GTFS est construite de manière très lente, lors de la première utilisation de Mobility. Les développeurs de transport.data.gouv.fr vont peut être permettre d'améliorer ça : etalab/transport-site#3746.
• On pourrait ajouter la possibilité d'utiliser des fichiers GTFS fournis manuellement, en plus ou en remplacement de ceux récupérés automatiquement (par exemple pour les modifier, en prospective).

from mobility.

Je viens de faire plusieurs commits sur la branche stage-2-model :

• Correction des tags de voies utilisés pour filtrer les données OSM (script R qui ne renvoyait pas tous les tags remplacé par une simple liste, à améliorer).
• Utilisation des données GTFS "community resources" de transport.data.gouv.fr, pour les territoires où l'AOM ne publie pas les données mais Google oui (Lyon par exemple). Cela peut mener à des doublons notamment en IdF, donc il faudra une stratégie de déduplication.
• Ajout de fonctions pour corriger et compléter les flux GTFS :
  • Tables calendar mal formatées (GTFS de RTM à Marseille par exemple).
  • Calcul des transferts pour "connecter" différents GTFS entre eux (SNCF avec opérateur local par exemple).
  • Correction des trips incorrects (vitesses de service > 300 km/h).
• Implémentation de la fonctionnalité pour générer une population locale, sur la base du travail de Lucas (#89) : https://github.com/mobility-team/mobility/blob/c3874b2206b76dcbc8e1a34e7953003dd293e3a9/examples/trip_localizer/example.py

from mobility.

Merci beaucoup @FlxPo !

J'ai commencé à implémenter un test, bon d'une part ça ne fonctionne pas, et de l'autre c'est déjà beaucoup trop long (25 minutes de test, en même temps ça va récupérer tous les fichiers et tout R, forcément c'est long). Je vois plusieurs approches possibles :

• Scinder les tests pour tester chaque fonction individuellement
• Utiliser des données mockées (un GTFS fictif très léger ?)

Pour le temps et la distance d'arrêt à arrêt, ça ne me paraît vraiment pas un point bloquant pour le moment, surtout en restant à l'échelle communale. Ce serait très bien de descendre au niveau IRIS, mais ça ne me paraît pas une priorité non plus.

Pour les GTFS non alignés, quel est le risque ?

Question supplémentaire : est-ce qu'il y a une raison à ce que gtfs_routes_types.xlsx ne soit pas un CSV ?

from mobility.

Nouveau commit qui devrait permettre de fermer (enfin) cette issue !

• Création d'une classe LocalizedTrips, qui prend en entrée les déplacements échantillonnés depuis les enquêtes nationales et assigne des origines et destinations pour certains motifs de déplacements.
• Les destinations sont échantillonnées selon les résultats de modèles de radiation (pour le moment uniquement pour le choix de lieu de travail).
• Les modes utilisés lorsqu'on connaît origine et destination sont ensuite échantillonnés en fonction d'un modèle très simple à choix discret, qui ne prend en compte que le temps de trajet et un coût du temps constant de 20 €/h.

J'ai fait un test sur une zone d'étude assez conséquente : environ 200 zones de transport autour de Lyon, avec 10 000 habitants et 11 millions de déplacements échantillonnés. Le temps de calcul est de l'ordre de 30 minutes (avec un cache froid, s'il faut tout télécharger et calculer, sinon c'est plus rapide). Certaines étapes sont très parallélisables, donc on pourrait améliorer ça.

La "localisation" fonctionne bien. L'échantillonnage de base ne différencie les comportements de mobilité qu'en fonction de caractéristiques socio-économiques et de la catégorie d'unité urbaine du lieu de résidence. Donc pas de différence à caractéristiques constantes entre un habitant de Lyon 7e ou d'une commune périurbaine de l'unité urbaine de Lyon.

Après localisation (encore une fois uniquement pour le domicile travail pour le moment), la distance parcourue diminue en moyenne pour les habitants du centre de l'agglomération et augmente plus on s'éloigne du centre.

Le ratio après / avant :

Il y a plusieurs améliorations et vérifications à faire:

• Le calcul des temps et distances de parcours a des petits bugs (valeurs NA qui ressortent).
• La fonction d'utilité utilisée pour le modèle de radiation et le choix des modes devrait être précisée.
• Le modèle de radiation utilisé est la version basique (alpha = 1, beta = 0), il serait possible de faire un calibrage.
• Les résultats obtenus (distances et parts modales) devraient être validés en comparant avec les données du recensement INSEE et de l'EMD locale.

from mobility.

@Mind-the-Cap à ton avis quelles sont les dernières étapes sont nécessaires pour fermer cette issue, faire un merge avec la branche main puis publier une nouvelle version du package ?

from mobility.

Salut @FlxPo merci beaucoup ! Est-ce que tu as mis le code permettant de générer cette carte quelque part ? Je ne l'ai pas trouvé. Je suis aussi intéressée par celui que tu as utilisé pour l'accessibilité des quartiers des grandes gares.

Voici ce qui à mon sens est nécessaire pour fermer l'issue et merger :

• Avoir une bonne couverture en tests (pour l'instant il y en a un qui ne passe pas)
• Mettre à jour la documentation (bien avancé grâce aux docstrings)
• Les améliorations que tu évoques juste au-dessus (j'y ajoute un calibrage à partir des données de fréquentation des gares dispos en open data)

Pour atteindre la version 0.2, je nous verrais bien fournir un peu plus d'efforts sur les représentations graphiques, ainsi qu'un ou deux articles de blog à publier sur https://mobility-team.github.io/ . Mais on n'est plus très loin !

from mobility.