Points ouverts méthodologiques¶

Cette page liste les choix volontairement différés. Ils ne bloquent pas la relecture du pipeline actuel, mais ils doivent être traités avant de présenter les résultats comme un indicateur opérationnel validé.

TODO-METH-01 — Produire `dist_excess` avec un routeur local¶

Statut : partiellement implémenté.

Objectif : reproduire l'indicateur historique dist_excess, c'est-à-dire l'écart entre la distance réellement parcourue dans la zone de destination et le plus court chemin routé entre l'entrée dans cette zone et le stationnement supposé.

Raison : les distances actuellement produites par le temps géométrique décrivent la portion finale affectée dans le buffer. Elles ne sont pas nécessairement des distances additionnelles. Pour quantifier un excès de circulation imputable à la recherche de stationnement, il faut comparer la trace observée à un itinéraire routé de référence.

Implémentation déjà ajoutée :

scripts/25_prepare_routing_candidates.py prépare les couples origine / destination à router ;
scripts/26_route_dist_excess_xyt.py appelle une API locale xyt_routing si elle est démarrée ;
scripts/27_apply_routing_dist_excess.py fusionne les distances routées et calcule dist_excess_m ;
docs/methodologie/routage-dist-excess.md documente le contrat, les sorties et la différence entre routage local et usage éventuel de Google.

Reste à faire après le run routé sur ch_extended_200km :

contrôler l'unique erreur moteur résiduelle du cache complet ;
auditer les cas extrêmes de dist_excess_m, notamment les valeurs fortement négatives ;
vérifier les cas no_route, out_of_bounds et échecs de snapping ;
décider si un audit Google ponctuel est utile comme comparaison, sans en faire la dépendance principale du pipeline ;
documenter la version du graphe routier utilisé dans les rapports finaux.

Critère d'acceptation : les sorties PL23 et Déclic contiennent un dist_excess_m calculé avec une méthode reproductible, une version de graphe renseignée et les échecs résiduels explicitement documentés. Côté PL23, la Base_3 historique peut alors être comparée à une Base_3 PL23 recalculée dans le nouveau pipeline. Cette comparaison ne concerne pas les volumes PL23 et Déclic entre eux.

TODO-METH-02 — Ajouter un filtre géographique explicite Genève pour Déclic¶

Statut : ouvert.

Objectif : vérifier si le temps géométrique Déclic doit être limité explicitement au canton de Genève, comme le traitement PL23 sur layer_GE.

Raison : PL23 applique un périmètre Genève via les champs de destination disponibles et la couche layer_GE. Côté Déclic, le pipeline actuel repose sur les legs nettoyées disponibles et sur l'activité de destination, mais n'applique pas encore de spatial join explicite avec une frontière cantonale ou un périmètre OCT. Si la source Déclic contient des destinations hors périmètre, les volumes spatiaux Déclic peuvent être plus larges que le périmètre institutionnel visé.

Décision à prendre :

périmètre exact : canton de Genève, agglomération, périmètre OCT, autre ;
source géographique officielle : couche cantonale, swisstopo, fichier client, ou géométrie validée en projet ;
règle d'inclusion : destination de leg, activité finale, portion affectée, origine-destination, ou combinaison.

Implémentation attendue :

ajouter un paramètre de configuration, par exemple spatial_detection.destination_boundary_file ;
calculer un flag spatial_destination_in_study_area ;
conserver un champ spatial_study_area_filter_reason pour les exclusions ;
exposer les compteurs avant/après filtre dans les JSON de résumé ;
produire une analyse de sensibilité avec et sans filtre géographique.

Critère d'acceptation : le rapport peut indiquer explicitement si les résultats Déclic spatiaux portent sur tout le fichier legs.parquet disponible ou sur un périmètre Genève validé, avec les deux dénominateurs audités.

TODO-METH-03 — Définir une stratégie de pondération et d'extrapolation PL23¶

Statut : ouvert.

Objectif : décider si les résultats PL23 doivent rester des résultats observés sur traces GPS disponibles ou être extrapolés statistiquement.

Raison : les premières analyses PL23 utilisaient les poids wgt_agg_trim_gps / Weight et le nombre total de jours GPS observés (nb_jours_obs) pour produire des ordres de grandeur par personne, par jour, puis à l'échelle de l'arc lémanique. Le nouveau pipeline conserve les variables utiles quand elles sont présentes, mais ne pondère pas les agrégations livrables par défaut.

Décision à prendre :

population cible : échantillon GPS observé, population enquêtée, population pondérée, arc lémanique, canton de Genève, autre ;
unité d'extrapolation : leg, trip, personne-jour, personne-année ;
poids à utiliser et traitement des valeurs manquantes ;
acceptabilité méthodologique d'une extrapolation à partir de cas détectés par proxy spatial.

Implémentation attendue :

produire des résultats observés et pondérés côte à côte ;
exporter les dénominateurs utilisés : personnes, jours GPS, trips, legs, legs éligibles ;
documenter explicitement les formules d'extrapolation ;
conserver une option de désactivation de la pondération.

Critère d'acceptation : le rapport distingue clairement les volumes observés, les volumes pondérés et les volumes extrapolés, sans mélanger ces niveaux de preuve.

TODO-METH-04 — Finaliser les sorties graphiques complémentaires¶

Statut : partiellement fait.

Objectif : conserver les visuels utiles dans le pipeline actuel, sans dépendre d'une exécution manuelle d'anciens notebooks.

Raison : certaines visualisations ne sont pas nécessaires au calcul, mais sont utiles pour relire les ordres de grandeur et produire des supports de rapport : courbes cumulées, cartes H3 thématiques, variables de stationnement déclaré et éventuellement analyse communale.

Déjà actif dans l'étape 24 et dans la restitution consolidée :

geometric_cumplots_indicators.png ;
geometric_h3_thematic_stats.csv ;
territorial_h3_hotspots.html ;
geometric_survey_parking_graphs.png.

Reste à faire :

fournir une couche communale validée ;
renseigner geometric_complements.commune_boundaries_file et geometric_complements.commune_name_col ;
relancer 24_geometric_complements.py ;
décider si une version statique des cartes HTML doit être exportée pour le rapport DOCX/PDF.

Critère d'acceptation : l'analyse communale est générée par le script 24 avec une couche versionnée et des dénominateurs explicites.

TODO-METH-05 — Réévaluer l'intérêt d'un matching qualité local¶

Statut : ouvert, priorité basse.

Objectif : décider si un map-matching local doit être utilisé comme filtre qualité, indépendamment du routeur nécessaire à dist_excess.

Raison : l'archive contenait un export vers un autre repo de map-matching et des commentaires sur des seuils de confiance, mais indiquait aussi que ce filtre n'avait finalement pas été appliqué. Le nouveau pipeline ne doit donc pas réintroduire ce bloc sans justification.

Implémentation attendue si ce point est retenu :

versionner le graphe routier et l'outil de matching ;
produire des champs matching_status, matching_confidence, matched_length_m, raw_to_matched_length_ratio ;
comparer les résultats avec et sans filtre de matching ;
documenter l'effet sur les dénominateurs.

Critère d'acceptation : le matching améliore réellement la qualité des legs gardées sans exclure massivement des cas valides de recherche de stationnement.