mobility-team / mobility Goto Github PK

Bonjour,

Je ne parviens pas à lire le fichier des catégories d'unités urbaines des villes, téléchargé dans mobility/parsers/urban_units.py (branche stage-2-model).
Les données sont utilisées dans transport_zones.py :

urban_units = pd.read_excel(data_folder_path / "UU2020_au_01-01-2023.xlsx", 
                      sheet_name = "Composition_communale", skiprows = 5)

Cela renvoie une erreur qui semble concerner le codage des couleurs :

ValueError: Colors must be aRGB hex values

C'est une erreur qui a l'air d'être récurrence sur certains fichiers de l'INSEE : https://foss.heptapod.net/openpyxl/openpyxl/-/issues/1699.

Je n'arrive pas à contourner l'erreur, à part en retirant à la main sur Excel les couleurs utilisées.
Tu arrives à lire le fichier sans encombre @FlxPo ?

Versions : pandas 2.1.4, openpyxl 3.0.10

..plutôt que d'embarquer toute la base carbone

Contexte dans #31

Lors de la première exécution, mobility récupère pour le moment la liste des arrêts GTFS compilée par transport.data.gouv.fr (et que l'on stocke sur data.gouv.fr), puis pour chaque "dataset" concerné récupère l'url du zip GTFS.

Cette deuxième étape est longue (~ 5 min), et pourrait être évitée en faisant le rapprochement une seule fois puis en l'intégrant directement à la liste des arrêts GTFS. Cela nécessiterait de créer des scripts de préparation de ce type de ressources statiques, qui devront se terminer par un upload de la ressource sur l'espace data.gouv.fr de mobility.

Les fonctions prepare_facilities et prepare_job_active_population téléchargent des fichiers zip directement depuis le site de l'INSEE. Problème, les url INSEE sont instables, donc les fonctions ne sont plus à jour assez rapidement.

Nous pouvons faire comme les données des enquêtes mobilité, et stocker les données nous même sur data.gouv.fr (https://www.data.gouv.fr/fr/organizations/mobility/) ? Sauf si on trouve une API stable quelque part ?

Les deux fonctions concernées sont ici :

• mobility/mobility/parsers/job_active_population.py

  Line 27 in cae504c

  url="https://www.insee.fr/fr/statistiques/fichier/5395838/base-ccc-emploi-pop-active-2018.zip",

• mobility/mobility/parsers/permanent_db_facilities.py

  Line 45 in cae504c

  url="https://www.insee.fr/fr/statistiques/fichier/3568629/bpe20_ensemble_csv.zip",

La branche nv_meth_echantillonnage met en place dans la classe TripSampler2 une nouvelle logique d'échantillonnage pour mieux rendre compte de la mobilité des individus. Elle se base en partie sur les nouvelles bases crées dans la branche entd_emd

Schéma

Voyages

1. On calcule un nombre de voyages par an selon la CSP à partir de long_dist_travel_number.parquet
2. On échantillonne autant de voyages dans la base travels.parquet (en fonction de la CSP, de la catégorie d'unité urbaine de résidence et de la motorisation)
3. On récupère les longs déplacements associés à ces voyages dans long_dist_trips.parquet
4. On calcule le nombre de jours passés en voyage, pour le travail (n1) et pour raisons personnelles (n2) à partir de la variable nb_nights de travels.parquet
5. On échantillonne n1 jours de semaine et n2 jours de week-end dans la base des jours type de déplacements courts days_trip.parquet (en fonction de la CSP, de la catégorie d'unité urbaine de résidence et de la motorisation) pour simuler les déplacements locaux durant le voyage
6. On récupère les déplacements courts associés à ces jours dans short_dist_trips.parquet

Mobilité quotidienne

7. On calcule le nombre de jours d'immobilité par an en semaine m1 et le week-end m2 selon la CSP à partir de immobility_probability.parquet
8. On échantillonne 365 jours de déplacements - n1 - n2 - m1 - m2 dans la base des jours type de déplacements quotidiens days_trip.parquet (en fonction du jour de la semaine (semaine ou week-end), la CSP, de la catégorie d'unité urbaine de résidence et de la motorisation)
9. On récupère les déplacements courts associés à ces jours dans short_dist_trips.parquet

Avantages

• Raisonner en termes de jour pour la mobilité locale et en termes de voyages pour la mobilité longue distance permet d'obtenir des chaînes de déplacements au lieu d'une liste de déplacements qui n'ont rien à voir entre eux. Ainsi les déplacements parmi la même chaîne de déplacements sont cohérents entre eux (le motif d'origine du déplacement n°2 est le motif de destination du déplacement n°1), ce qui pourra être éventuellement utilisé dans le modèle d'opportunités
• On évite d'avoir à calculer un nombre de déplacements courts par an (dans la 1ère version du code, deux personnes avec la même CSP avaient le même nombre de déplacements par an). Tout le reste des résultats dépendait beaucoup de ce nombre de déplacements par an. Cette nouvelle façon de faire me paraît plus robuste de ce point de vue là.
• On gère mieux la superposition entre la mobilité locale et la mobilité longue distance : les jours de voyage sont retirés de la mobilité locale
• Les probabilités d'être immobile un jour de la semaine ou du week-end selon la CSP sont des résultats intéressants en soi.

Une façon de tester la pertinence de cette logique d'échantillonnage sera calculer les distances moyennes parcourues avec un échantillon et de comparer ces résultats avec les totaux publiés sur le site du SDES.

Il serait possible d'optimiser les valeurs alpha et beta du modèle de radiation pour améliorer la capacité de la modélisation à reproduire les estimations de flux fournies par l'INSEE.

• Extraire la création des modèles de radiation de la classe LocalizedTrips dans une classe RadiationModel générique.
• Donner la possibilité de fournir des données de flux de référence.
• Créer une fonction permettant de calibrer les paramètres alpha / beta en fonction des données de référence.

La classe LocalizedTrips applique plusieurs étapes de modélisation pour "'localiser" des échantillons de déplacements issus de l'enquête nationale de mobilité des personnes. Les indicateurs issus des déplacements en sortie de modélisation devraient donc se rapprocher de ceux des sources locales : flux domicile - travail INSEE, EMD locale.

• Calculer un échantillon de déplacements non localisés / localisés pour un ensemble d'agglomérations françaises.
• Calculer les indicateurs agrégés : distance moyenne par jour et par personne, part modale, flux domicile - travail entre zones de transport.
• Comparer les indicateurs calculés avec les indicateurs de référence pour vérifier que la modélisation améliore bien l'estimation des caractéristiques des déplacements locaux.

Le travail sur #19 m'a fait repenser au besoin d'avoir de meilleurs noms pour les variables que l'on utilise, et notamment les noms de colonnes des dataframes : mode_id, ef, ef_name...

• Préfixe "mobility_", "ademe_", "sdes_"... pour expliciter la source ?
• Acronymes autorisés ou noms complets systématiquement ?

Preneur de vos idées @Mind-the-Cap @louisegontier

Les docstrings décrivent le fonctionnement de chaque fonction, ses entrées et sorties, et peuvent éventuellement intégrer des doctests

Il faut que l'on décide d'une stratégie d'utilisation de fichiers externes dans notre code:

• Inclure systématiquement les fichiers nécessaires pour faire tourner les fonctions et les exemples ?
• Définir des jeux de données "de base" et d'autres qu'on laisse l'utilisateur gérer ?
• Intégrer ou non la mise à jour des jeux de données (millésimes du recensement INSEE par exemple) ?

@FlxPo dans #22

Personnellement, je suis en faveur d'inclure systématiquement les fichiers nécessaires :

• plutôt directement dans Github pour les fichiers légers
• en utilisant data.gouv.fr pour les fichiers lourds de l'INSEE

Je ne vois pas de cas pour l'instant où il serait intéressant que l'utilisateur ait des données à gérer.
Je suis en faveur d'avoir les différentes versions, grâce à un dictionnaire qui enregistrerait les différents liens. Mais dans l'immédiat, on peut rester sur les dernières données, on n'a pas de gros cas d'usage pour ça (dans le futur je vois la reproductibilité notamment, ou la comparaison entre années).

Pour le moment les fichiers téléchargés sont stockés directement dans le package, à cause de l'utilisation de paths relatifs au fichiers du package (avec data_folder_path).

Le mieux serait d'utiliser un dossier temporaire stocké autre part. Le package r5py crée par exemple un dossier dans "C:\Users\username\AppData\Local\r5py" (path adapté en fonction de l'OS, car s'appuie sur les variables d'environnement HOME et LOCALAPPDATA). On pourrait récupérer leur méthode : https://github.com/r5py/r5py/blob/main/src/r5py/util/config.py#L60.

Lors de l'échantillonnage, il peut arriver que les bases de l'enquête ne contiennent pas de déplacements pour la CSP, la catégorie urbaine et le type de jour choisi. Auquel cas, le code renvoie une erreur. Il faut décider comment on souhaite gérer ces erreurs. De même, si la taille de l'échantillon considéré est très faible les résultats obtenus auront plus de chance d'être biaisés

Remarque : Il est à noter que les tailles d'échantillon sont en général plus faibles pour l'EMP 2019 que pour l'ENTD 2008

Une solution serait de relaxer une des contraintes (CSP, catégorie urbaine ou type de jour) -> a priori, on relaxerait en priorité la catégorie urbaine et le type de jour puisque la CSP est en général la variable la plus discriminante en terme de mobilité

N'hésitez pas à partager vos idées sur le sujet!

La branche bases_demande_opportunite permet de construire des bases d'emplois, d'actifs et d'équipements à l'échelle de la commune à partir de données INSEE. Ces bases doivent permettre de déterminer un volume de demande et d'opportunités par commune pour différents motifs.

Emplois et Actifs

Les données INSEE utilisées pour ces bases sont dispos ici :
Sommaire : https://www.insee.fr/fr/statistiques/5395838?sommaire=5395900
Téléchargement : https://www.insee.fr/fr/statistiques/fichier/5395838/base-ccc-emploi-pop-active-2018.zip

On les utilise pour obtenir le nombre d'emplois et d'actifs par commune et par CSP.
Ces bases seront utilisées pour les déplacements Motif Travail avec le nombre d'emplois comme volume d'opportunité et le nombre d'actifs comme volume de demande/

Équipements

La Base Permanente des équipements est utilisée pour déterminer la quantité d'équipements par commune. Elle est dispo ici :
Sommaire : https://www.insee.fr/fr/statistiques/3568638?sommaire=3568656
Liste des équipements : https://www.insee.fr/fr/metadonnees/source/fichier/BPE20_Liste_equipements_insee-fr.pdf
Téléchargement : https://www.insee.fr/fr/statistiques/fichier/3568629/bpe20_ensemble_csv.zip

On l'utilise pour attribuer un poids à chaque commune pour différents type d'équipement. Les types d'équipement que l'on veut considérer vont dépendre du type de motif que l'on essaie de modéliser. Ces équipements permettront de modéliser un volume d'opportunités pour le motif correspondant.
Voici un extrait du tableau des correspondances Motif du déplacement // Type d'équipements considéré pour l'instant

On attribue ensuite un poids à chaque équipement en fonction de la quantité de flux qu'il est susceptible de générer. Ces poids sont très arbitraires pour l'instant et un travail supplémentaire pourrait être fait dans le futur pour affiner ces poids (quelles données on aurait pour estimer la fréquentation de chaque type d'équipement ?), notamment en considérant d'autres métriques (par exemple, le chiffre d'affaires du commerce)
Voici un extrait du tableau du poids associé à chaque type d'équipement pour l'instant

Note : C'est surtout le poids relatif qui compte et pas la valeur absolue
Un travail similaire a été fait pour les motifs Etudier, Démarche administrative, Faire du sport, Soins, Voir un spectacle, Visiter un monument, Manger à l'extérieur du domicile.

Mobility doit pouvoir servir pour évaluer des scénarios de mobilité sur le moyen terme. Or, de nombreux éléments sont amenés à changer, souvent rapidement :

• Population par territoire (données : approche régionale 2014 INSEE )
• Emplois par territoire
• Évolution des pratiques de mobilité (possibilité d'utiliser les comportements de Transition(s) 2050 dans ses 4 scénarios.
• Évolution de l'empreinte carbone des mobilités (idem, Transition(s) 2050 comporte des données selon les scénarios).

Deux points importants concernant l'évaluation d'un projet sur un territoire donné :

• Des évolutions de population beaucoup plus locales peuvent être prévues, il faudra donc être en mesure d'utiliser ces données
• Le projet dépend d'évolutions de mobilité extérieure mais va aussi permettre ou pas ces évolutions (exemple : augmentation de l'offre TC qui va permettre un report modal), il faut donc être en mesure de séparer ces deux effets.

• Mutualiser les fichiers de description des modes et motifs si besoin
• MAJ avec la future fonction carbone et supprimer ef_mode.xlsx
• Ajouter l'article correspondant écrit par Arthur ou faire le lien avec le futur site

Dans le Todo de get_data_for_model :
* improve the get_insee_data function for work-home data, coordinates and superficies, to not have to deal with local data
* compute the internal distance within the code instead of using a CSV

• Est-il possible d’avoir l’adresse URL du fichier (.zip ou autre) qui a été utilisé pour créer le fichier “donneesCommunesFrance.csv” ?
• Les coordonnées (x , y), est-ce que c’est des (abscisses,ordonnées) ou (longitudes,latitudes) ?

Voici le fichier (https://www.data.gouv.fr/fr/datasets/r/dbe8a621-a9c4-4bc3-9cae-be1699c5ff25) qu'on a utilisé pour éviter de travailler avec des données locales, mais on n'a pas eu les mêmes résultats qu'avant.

Contributeur : personne et organisation qui contribue au projet Mobility sous la forme de développements, idées, tests.
Utilisateur : personne et organisation qui utilise le package python.

• Créer un tableau simple au format markdown (https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables).
• Entrer AREP et Elioth.

• Optimiser les temps de test en utilisant le cache et des données précalculées ?
• Faire passer les tests actuels.
• Rédiger des tests pour les nouvelles classes et fonctions.

• Création d'un environnement conda (https://docs.conda.io/en/latest/miniconda.html).
• Installation du package mobility : pip install mobility-package.
• Utilisation de base : échantillonner un an de déplacements pour un profil socio-économique donné.
• Prévoir un paragraphe "que demander à ma DSI pour que cela fonctionne", pour les utilisateurs en entreprise ?

Bonjour,
Dans le code de l'exemple Millau,
To do: compute the internal distance within the code instead of using a CSV

• Après avoir passé en revue les calculs de la distance interne et le rayon dans le fichier Excel donnéescommunefrance, c'est plutôt R= sqrt(surface/pi) et non pas R= sqrt(surface)/pi. Étant donnée l'importance de ce paramètre notamment dans le calcul de la distance interne qui vont nous servir à la réalisation de la tache.

La fonction d'utilité est pour le moment intégrée aux calculs de la classe LocalizedTrips, et est une version très simplifiée (prise en compte uniquement du temps de transport).

• Isoler le calcul de l'utilité dans une fonction.
• Faire remonter les paramètres de la fonction d'utilité dans les propriétés de LocalizedTrips.
• Proposer des valeurs par défaut de coût du temps et de coût kilométrique.

Calcul de la mobilité domicile-travail avec le modèle d'opportunités et comparaison avec les données de l'INSEE

Le dossier examples/Millau utilise le modèle d'opportunités pour déterminer les flux domicile-travail, à partir de la répartition des actifs et des bassins d'emploi sur le territoire autour de Millau et les compare aux données mesurées par l'INSEE en 2017 (fluxDtMillau2017.xlsx dans le dossier).

1/ Le modèle d'opportunité

Données d'entrée :
La base emploi et population active par commune de 2018 (chargée par get_insee_data) est utilisée pour obtenir une quantité de demande (ici les actifs) par commune et une quantité d'opportunités (ici les emplois) par commune.
Le coût utilisé est la distance vol d'oiseau entre le centroïde de la commune de départ et celui de la commune de destination. Pour les flux intra-communes, le coût utilisé est la distance moyenne entre deux points aléatoires d'un cercle 128R/(45pi) où R est le rayon de la commune si l'on la modélise par un disque (R = sqrt(surface commune)/pi)

Périmètre :
Le périmètre choisi doit dans l'idéal contenir l'ensemble des lieux de travail possibles pour un habitant de Millau. Nous verrons par la suite que le choix de ce périmètre a une grosse influence sur les résultats. Deux périmètres sont testés :

1. L'Aveyron, la Lozère, l'Hérault, le Gard et le Tarn : 1,13M d'actifs // 0,95M d'emplois
2. L'Aveyron et la Lozère : 155K d'actifs // 143K emplois

Répartition des actifs sur le 1er périmètre

Résultats :
Le flux total calculé sur le 1er périmètre est 0,95M déplacements DT (tous les emplois ont été pourvus). Celui sur le 2ème périmètre est 143K déplacements DT (tous les emplois ont été pourvus)
Représentation graphique des flux DT calculées par le modèle (plus un point est gros, plus la mobilité intra-communale de cette commune est élevée)
1er périmètre

2ème périmètre

2/ Comparaison avec les données INSEE

On effectue la comparaison uniquement sur les OD en commun entre les flux générés par le modèle et les flux mesurés par l'INSEE :

1. Sur le 1er périmètre, 355 OD en commun.
   Sur ces 355 OD :
   Flux total mesurée par l'INSEE : 15 214 (dont 48% de flux intra-communal)
   Flux total du modèle : 13 201 (dont 45% de flux intra-communal)
   Flux commun (entre le modèle et l'INSEE) : 10 144 (soit 67% du flux INSEE)
   Le modèle sous-estime le flux total de 13% et sous-estime légèrement la part du flux intra-communal.
   Si on regarde uniquement la répartition entre les OD (on divise la quantité de flux pour chaque OD par la quantité de flux total) pour gommer la différence dû à la sous-estimation du flux total :
   La répartition mesurée par l'INSEE et celle générée par le modèle ont 75% en commun.

Représentation graphique du flux INSEE sur les OD en commun

Représentation graphique du flux calculée par le modèle sur les OD en commun

Au vu des représentations graphiques, il semble que le modèle favorise trop les OD lointaines (les Millau-Rodez, Millau-Montpellier)
au détriment des flux périurbain/banlieue -> ville centre et périurbain/banlieue->périurbain/banlieue

2. Sur le 2ème périmètre, 301 OD en commun.
   Sur ces 301 OD :
   Flux total mesurée par l'INSEE : 14 907 (dont 49% de flux intra-communal)
   Flux total du modèle : 13 424 (dont 46% de flux intra-communal)
   Flux commun (entre le modèle et l'INSEE) : 10 603 (soit 71% du flux INSEE)
   Le flux du modèle a augmenté de 4% p/r au 1er périmètre (l'importance relative de Millau dans ce périmètre restreint a augmenté).
   La répartition mesurée par l'INSEE et celle générée par le modèle ont 77% en commun.

3/ Autres tests

Il a aussi été testé de calculer les flux DT avec le modèle en distinguant selon la CSP. On distingue le nombre d'emploi et d'actifs par commune selon la CSP : un personne avec une certaine CSP choisira sa destination selon la répartition des emplois ayant cette même CSP. L'impact sur les résultats de cette méthode a été très faible.

D'autres valeurs de alpha et beta que alpha=0 et beta=1 ont été testées. Toutes se sont révélées moins pertinentes que le couple alpha, beta = (0,1) choisi initialement. Pour rappel, alpha représenterait le comportement exploratoire de l'individu (favorise les destinations lointaines avec beaucoup d'opportunités) et beta le comportement prudent (favorise les destinations les plus proches qui ont plus d'opportunités que les destinations intermédiaires).

Il a été testé une autre distance interne, en considérant la surface urbanisée de la commune (plus restreinte que la surface de la commune). La part du flux intra-communale a très légèrement augmenté (+1%).

4/ Conclusion

Le modèle a su prédire en partie la mobilité domicile-travail sur le territoire de Millau, même si le volume total a été sous-estimé. Ces résultats montrent aussi l'importance du périmètre que l'on donne au modèle, les résultats s'étant légèrement améliorés en considérant un territoire plus restreint.

J'ai calculé la somme des pondérations individus "pondki" en 2008 et 2019 pour vérifier qu'on retombait bien sur la population des 6 ans et plus française. C'est OK en 2008 (54 millions de personnes), mais pas en 2019 (94 millions de personnes).

Je ne sais pas trop d'où peut venir le problème ?

Voici le code :

import pandas as pd

df_2008 = pd.read_parquet("C:/Users/pouchaif/Documents/dev/mobility_oss/data/surveys/entd-2008/short_dist_trips.parquet")
df_2019 = pd.read_parquet("C:/Users/pouchaif/Documents/dev/mobility_oss/data/surveys/emp-2019/short_dist_trips.parquet")

ind_2008 = df_2008.groupby("individual_id").first()
ind_2019 = df_2019.groupby("individual_id").first()

print(ind_2008["pondki"].sum())
print(ind_2019["pondki"].sum())

Suite à des problèmes décrits dans #83 par @FlxPo, nous allons devoir utiliser R pour certaines fonctions (tout en limitant le code R au minimum).

Voici ce que cela entraîne :

• Mettre en place des tests de code pour R https://github.com/r-lib/actions
• Surveiller la couverture du code avec https://about.codecov.io/language/r/
• Vérifier que la documentation fonctionne et est à jour
• Ajouter des étapes de configuration de la librairie

Pour l'instant, Mobility intègre un modèle de radiation universel uniquement mis en application pour les déplacements domicile-travail .

L'exemple de Millau montre comment utiliser ce modèle pour ces déplacements (sources : domiciles, sinks : emplois). Les paramètres alpha et beta peuvent être optimisés dans ce code. L'indice de similarité (SSI) de l'article de recherche est ainsi utilisé.

Les déplacements domicile-travail sont très importants, mais pour être plus fiable (et parce qu'il n'y a pas que le travail dans la vie ;), Mobility devrait intégrer d'autres motifs de déplacement. C'est ce sur quoi va travailler l'équipe ENSG (@JoannaGosse @TonyT71 @BaptisteD35 et @martaducamp).

La liste ci-dessous indique les autres motifs de déplacement. Tous ne sont pas d'égale importance... Idéalement tous ceux de 1 à 7 (voire 9.2 à 9.5) devraient être étudiés, mais les achats, les études et les loisirs apparaissent comme prioritaires.

Liste de tâches (à mettre à jour par l'équipe) :

• Faire un état de l'art des études sur ces motifs de déplacement et des méthodes de comparaison existantes
• Faire l'état des lieux des données existantes et de comment elles peuvent être utilisées
• Prévoir l'architecture technique (classes, fonctions, examples et tests)
• Intégrer le modèle de radiation avec le calcul de CO2 et l’échantillonnage (@Mind-the-Cap / @FlxPo)
• Coder
• Documenter
• Faire un billet de blog explicatif sur mobility-team.github.io

mobility utilise un fork d'osmdata optimisé. Pour le moment la librairie était installée à partir de fichiers binaires compilés sur Windows, et donc incompatible avec d'autres architectures.

J'ai ajouté dans la branche #102 la possibilité d'installer la librairie depuis CRAN si la plateforme n'est pas Windows, et depuis les fichiers binaires sinon. Donc les utilisateurs hors Windows (dont les github actions) ne profitent pas de l'optimisation.

Il faudrait compiler des fichiers binaires pour différentes architectures, surement avec une github action dans le repo du fork d'osmdata.

L'INSEE vient de publier une estimation des émissions de la mobilité domicile - travail avec une approche relativement proche de la notre, en repartant de leur fichier de flux issu du recensement : https://www.data.gouv.fr/fr/datasets/estimation-des-emissions-individuelles-de-gaz-a-effet-de-serre-lors-des-deplacements-domicile-travail/

Une bon benchmark pour nos résultats !

• RScript
• PublicTransportTravelCosts
• Population
• Trips
• LocalizedTrips

Le package sera présenté avec un site web, qui contiendra une présentation synthétique, la documentation de cas d'utilisation et des posts de blog pour la communication sur les réseaux sociaux.

Je propose d'utiliser ce template Hugo : https://themes.gohugo.io/themes/doks/
Nous pourrons déployer le site avec un repo Github dédié (hébergement et déploiement gratuit pour les projets publics) : https://gohugo.io/hosting-and-deployment/hosting-on-github/

Premières étapes :

• Créer le repository mobility-team.
• Cloner le repository du thème doks.
• Tester un déploiement en l'état.

FAILED test/test_parsers.py::test_parser_entd_2008 - TypeError: datetime64 type does not support sum operations, exemple ici

ça vient de la ligne 552 de prepare_entd_2008 :
indiv_mob = indiv_mob.groupby("csp").sum()

En local ça fonctionne très bien et la colonne csp du data_frame contient bien des valeurs de csp ainsi que no_csp. Pas de piste pour l'instant.

Éclaircir les problèmes laissés dans #34 :

• Pourquoi UUCAT (anciennes unités urbaines) est utilisé et pas UU2010 (unités urbaines 2010) comme à d'autres endroits du code ?
• Pourquoi les trajets de plus de 80 km sont-ils enlevés des short_trips ? Est-ce une données en doublon dans la base INSEE ?

PublicTransportCosts retourne une distance et un temps de trajet nul pour une liaison en train Halsou <-> Halsou (code INSEE : 64255).
A corriger car cela se traduit ensuite par une forte probabilité de sélection de ce mode...

Je vais pour le moment ajouter un filtre pour éliminer les lignes de ce type dans le calcul des probabilités (dans la branche bidard-tests pour le moment).

Nécessité de générer les trips en fonction du modèle de radiation :

• Récupérer les préférences modales (à partir d'hypothèses de bases ?)
• Faire l'affectation par mode (comment ?)
• Générer les trips multi-modes avec r5py pour les fournir à carbon_computation #83

Ajouter les données suisses (ou au moins celles du canton de Vaud) :

• population par commune
• emploi par commune
• données de différences de revenus pour adapter le modèle aux cas transfrontaliers

Bonjour,

Dans le logiciel UrbanPrint (https://efficacity.com/quartiers-bas-carbone/nos-logiciels/urbanprint/#:~:text=UrbanPrint%20est%20un%20outil%20d,neuf%2C%20en%20r%C3%A9novation%20ou%20mixte.) nous utilisons une version antérieure du code de mobility pour faire le calcul de l'empreinte de la mobilité dans l'empreinte carbone des habitants d'un quartier.

Concrètement nous avons copié le code de mobility (disponible ici : https://gitlab.com/elioth/mobility) dans le code d'UrbanPrint.
A l'époque, Emilien avait repéré un bug et l'avait commité dans le dépot (https://gitlab.com/elioth/mobility/-/commit/f168d2e73a8303a6a3ead8d382f0ed06b81075c4) mais depuis je ne crois pas qu'on est pris en compte les multiples corrections et m-à-j qui ont suivies.
Dans l'idéal nous nous séparons de ce fonctionnement pour aller installer la version 0.1 de mobility. J'ai oublié si vous l'avez mentionné ou pas mais vous ne mettez pas à disposition d'API ?

Dans tout les cas, avant de déployer ce nouveau fonctionnement, nous allons avoir besoin de faire un test de non-régression pour mesurer l'impact de cette m-à-j sur les résultats de projets déjà simulés. Concrètement, je vous propose dans le code d'UrbanPrint on va créer une branche dédiée, importer mobility 0.1 et faire ce qu'il faut pour qu'on puisse s'en servir comme l'ancienne version et enfin comparer les résultats avant après sur une dizaine d'opérations étudiées avec UrbanPrint. On pourra ainsi se faire une idée de l'impact de ces mises-à-jour de modèles et de données.

On discute en interne CSTB/Efficacity pour voir qui peut prendre cette tâche. (idéalement on arrive a travailler aussi avec les équipes d'Elioth dans pas trop longtemps et c'est peut-être eux qui prendront le relai)

On vous tient informés.

Suggéré par @FlxPo dans #22

Ma proposition :

• Gestionnaire du projet :

  • Peut gérer l'équipe mobility sur GitHub
  • Peut gérer les données sur data.gouv.fr
  • Peut communiquer en externe sur le projet
  • A aussi les rôles revieweu·se et contributeur·ice

• Revieweur·se :

  • Peut reviewer les PR sur Github

• Contributeur·ice :

  • Peut proposer des PR (et les fusionner quand approuvées)
  • Peut ouvrir des issues et y contribuer

Il arrive que les serveurs qui hébergent les données GTFS ne répondent pas assez vite, ce qui crée une erreur du type :
ReadTimeout: HTTPConnectionPool(host='gtfs.gis.flix.tech', port=80): Read timed out. (read timeout=None)

Il faudrait essayer N fois, et potentiellement ne pas bloquer l’exécution mais simplement émettre un avertissement.

Mobility has been counceived for France, using French data. But it could be useful in different countries, using similar datasets. You can help the library by:

• finding these datasets in a country you know
• adapt the code to grab and analyse these datasets
• run studies comparing different countries using mobility

We welcome contributions for any country! As a start, you can use this issue to gather first insights about potential countries to add (with good open data). If you want to start to code, you can add your own issue.

Il faut que l'on ajoute des tests à notre code, pour bien encadrer les modifications du code existant. Cela deviendra d'autant plus nécessaire que le code gagne en complexité.

• @Mind-the-Cap, est ce que tu aurais des conseils pour mettre en place des tests pour le projet ?
• Est ce qu'on se donne un objectif de "coverage" ?
• Est ce qu'on met en place une github action automatisée via codecov (gratuit pour les projets open source) ?

Quelques éléments intéressants ici : https://about.codecov.io/blog/the-10-commandments-of-writing-good-software-tests/

J'ai écrit un premier test ici pour se lancer : https://github.com/mobility-team/mobility/blob/carbon/test/parsers/test_ademe_base_carbone_api.py

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

Nous allons repartir du repository existant hébergé sur Gitlab, dans un premier temps : https://gitlab.com/elioth/mobility/

Le premier objectif est d'arriver à le packager puis à le publier sur PyPI. Le nom Mobility est déjà pris, il faudra en trouver un autre !

On se concentre sur la fonctionnalité de base : échantillonner des déplacements pour un profil socio-économique donné, sur un type de territoire donné.

Les étapes sont les suivantes :

• Inclure tous les fichiers python nécessaires au fonctionnement du package dans le repository.
• Héberger les fichiers volumineux sur data.gouv.fr ? (https://doc.data.gouv.fr/a-propos/que-publier-et-comment-le-publier/)
• Restructurer les dossiers pour suivre la structure classique d'un package python (https://packaging.python.org/en/latest/tutorials/packaging-projects/).
• Publier la version 0.0.1 du package sur Github et PyPI (https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository).

ENTD : https://www.statistiques.developpement-durable.gouv.fr/resultats-detailles-de-lenquete-mobilite-des-personnes-de-2019?rubrique=60&dossier=1345

• #6
• Lien entre les noms de variable 2008 et 2018
• Mise à jour de la population par csp (INSEE - 2018)
• Mise à jour du script entd.py
• Ajout de nouvelles variables si possible ? (variable sur la part des vélos? catégorisation des villes?)

Bonjour,

Les conventions Python permettent d'avoir une meilleure lisibilité du code, ce qui est important car on lit plus souvent le code qu'on ne l'écrit (et ça me semble particulièrement vrai avec Mobility). Un code standard peut être réutilisé facilement pour des projets, est plus facile à améliorer, et évite les doublons.

Je vous propose de suivre les conventions PEP8 et PEP257 pour le projet. Vous trouverez un court descriptif de la première ici, mais voici les points essentiels :

• des lignes courtes (pas plus de 79 caractères),
• indentation avec 4 caractères,
• bon positionnement des espaces,
• commenter le code en anglais,
• utiliser les docstrings (vu la complexité du code, je dirais plutôt la version en plusieurs lignes, en précisant bien les types des données d'entrée pour les fonctions).

La plupart des éditeurs Python proposent de tester la conformité directement en écrivant du code. Pour ce qui est de l'existant, on peut utiliser des solutions comme black qui permettent de le transformer automatiquement (je peux m'en charger si vous le voulez).

N'hésitez pas si vous avez des commentaires ou des remarques !

Certains calculs d'origines destinations avec R (dodgr et gtfsrouter) retournent des NA.

• Identifier les cas qui génèrent des NA.
• Proposition de correctif.
• Rédaction d'un test qui vérifie qu'on ne produit pas de NA dans les cas problématiques.

Il faudrait vérifier qu'on retombe bien sur des chiffres proches des résultats officiels de l'ENTD 2008 et de l'EMP 2019. On pourrait pour cela échantillonner une population représentative française (avec les données détail du recensement), et calculer des nombres de déplacements, de voyages, et des parts modales.

J'ai créé une nouvelle branche pour travailler sur le modèle de mobilité (https://github.com/mobility-team/mobility/tree/radiation-model), avec un squelette de fonction radiation_model, et le pseudo-code de l'algorithme.

Cette version du modèle nécessite de calculer un équilibrage des flux à l'échelle d'un ensemble de zones de transport (communes, IRIS...) pour prendre en compte la "concurrence" entre origines, qui n'est pas du tout prise en compte dans le modèle de radiation base. Elle permet de garantir que le volume au niveau des destinations ne sera pas dépassé par les flux entrants : pas plus d'employés que d'emplois, par exemple.

Cette version est itérative : à chaque itération, les individus sont supposés se comporter selon le modèle de radiation classique, en fonction des opportunités disponibles aux différentes destinations et des coûts pour atteindre ces destinations. Si une destination sature, une partie des individus ne peut pas la sélectionner. Ils se reportent donc sur les destinations non saturées restantes, et ainsi de suite jusqu'à convergence.

On peut dans un premier temps rester sur un modèle unimodal, l'extension multimodale devrait être assez facile.

Bonjour,

Lors du tout premier téléchargement des données, celles de l'Esane (insee) manquent à l'appel lors de l'utilisation de la fonction get_insee_data(), ce qui renvoie une erreur.
Voilà l'enchaînement ce qui a généré l'erreur (juste après le pip install mobility-tools) :

from mobility.get_insee_data import get_insee_data
get_insee_data()
FileNotFoundError: [Errno 2] No such file or directory: 'C:\\Users\\bohnenkl\\.conda\\envs\\env3\\lib\\site-packages\\mobility\\data\\insee\\esane\\equipments_features.xlsx'