🚌 Générer les déplacements avec dodgr (anciennement r5py)

[Mind-the-Cap]

Premier exemple dans #69

Ce qu'il reste à déterminer :

• comment se fait le choix modal
• comment prendre en compte les pratiques différents des CSP
• comment modéliser les évolutions (nouvelle ligne de transport par ex)
• comment sont générés les trips en sortie

[FlxPo]

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).

[FlxPo]

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 ?

[Mind-the-Cap]

@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 ?

[FlxPo]

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)...

[Mind-the-Cap]

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.

[FlxPo]

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...

[Mind-the-Cap]

@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 !

[FlxPo]

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).

[FlxPo]

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