Relire les notebooks

Les notebooks sont la façade de relecture du pipeline et sont rangés à la racine du dépôt dans Notebooks/. Ils doivent rester exécutables de haut en bas, mais la logique métier réutilisable reste dans src/parking_search_prediction/.

Chaque notebook commence par une cellule parameters. C'est la cellule à modifier pour changer de configuration, passer du sample au run complet, tester une source, changer une règle spatiale ou ajuster une taille d'échantillon cartographique. Les chemins sont exprimés depuis la racine du projet.

Sources d'entrée

La convention de rangement des données est la suivante :

Source	Dossier	Rôle
anonymous	Data/GPS/anonymous/	jeu GPS anonymisé historique ou de test
declic	Data/GPS/declic/	source principale actuelle pour appliquer les deux temps de méthode
pl23	Data/GPS/pl23/	Panel Lémanique 2023 et dump Situee pour le temps géométrique

La configuration par défaut utilise :

Data/GPS/declic/waypoints-sample/
Data/GPS/declic/cleaned-base/parquet/

Pour passer du run borné au run complet, utiliser CONFIG_NAME = "full_waypoints.yaml" ou mettre RUN_FULL = True dans les notebooks concernés.

Séquence recommandée

Étape	Notebook	Rôle
01	01_prepare_inputs_declic.ipynb	préparer les waypoints Déclic, joindre les legs, produire waypoints_caronly
21	21_spatial_eda_declic.ipynb	explorer les indicateurs géométriques, les seuils et les cartes de contrôle
22	22_spatial_detection_declic.ipynb	appliquer le temps géométrique Déclic et exporter les candidates
23	23_spatial_detection_pl23.ipynb	appliquer le temps géométrique sur PL23, sans routage externe
24	24_geometric_complements.ipynb	produire courbes cumulées, cartes H3, graphiques survey et analyse communale optionnelle
25	25_routing_dist_excess.ipynb	préparer les paires de routage et, optionnellement, appliquer dist_excess_m
31	31_temporal_eda_declic.ipynb	explorer les waypoints voiture et la sensibilité de segmentation
32	32_temporal_detection_relut_declic.ipynb	lancer le modèle ReLUT et produire les sorties temporelles
41	41_results_by_approach.ipynb	relire séparément les résultats par temps de méthode
42	42_compare_spatial_temporal_declic.ipynb	consolider par leg_id, produire les portions et la carte de relecture
43	43_routed_network_relut.ipynb	relire les probabilités ReLUT sur legs complètes et produire l'agrégation réseau
44	44_territorial_indicators.ipynb	produire les indicateurs opérationnels de restitution territoriale

Les anciens notebooks 00-03 sont archivés dans Notebooks/archive_legacy_00_03/. Ils ne sont plus la séquence de reprise recommandée.

01_prepare_inputs_declic.ipynb

Ce notebook contrôle :

• la découverte des fichiers de waypoints ;
• le chargement des CSV bruts ;
• le nettoyage ;
• la lecture de legs.parquet ;
• la jointure temporelle user_id + intervalle de leg ;
• le filtre des modes voiture ;
• la production de waypoints_caronly.parquet.

Il ne lance ni le temps géométrique ni le modèle. Il sert à vérifier que la base de points voiture est correctement construite avant toute inférence.

21_spatial_eda_declic.ipynb

Ce notebook explore les indicateurs géométriques sur Déclic. Il produit :

• un profil des legs évaluées spatialement ;
• une analyse de sensibilité distance/tortuosité ;
• une agrégation cartographique sur grille métrique EPSG:2056 ;
• des figures de distribution ;
• des cartes HTML d'exemples.

La grille métrique sert à localiser les zones où les indicateurs de cruising se concentrent. Les cartes H3 thématiques sont produites par le notebook 24. H3 reste aussi utilisé dans la détection pour réactiver l'exclusion des destinations situées dans les cellules associées aux tunnels.

22_spatial_detection_declic.ipynb

Ce notebook applique la règle géométrique configurée et écrit spatial_declic_candidates.parquet.

Deux variantes sont toujours exportées :

• spatial_candidate_broad : règle large de repérage ;
• spatial_candidate_conservative : règle plus stricte.

La colonne spatial_candidate reprend la variante choisie par SPATIAL_CANDIDATE_RULE.

Point ouvert : ce notebook n'applique pas encore de spatial join canton Genève explicite côté Déclic. Il utilise les legs disponibles dans legs.parquet après les filtres configurés. Si le périmètre d'étude doit être strictement genevois, ajouter un filtre géographique auditable avant interprétation globale.

23_spatial_detection_pl23.ipynb

Ce notebook intègre la source PL23 dans le pipeline actuel pour appliquer le temps géométrique sur une seconde source de legs géométrisées.

Il lit par défaut la couche layer_GE du GPKG PL23 et produit :

• pl23_spatial_candidates.parquet ;
• pl23_spatial_candidates.csv ;
• pl23_spatial_deliverable_table.csv ;
• pl23_spatial_variable_dictionary.csv ;
• des figures de distributions et de volumes détectés ;
• une carte HTML d'exemples.

Le notebook ne requête pas Google Maps et ne lance pas OSRM. La variable routée dist_excess n'est donc pas produite. La colonne pl23_base3_proxy_without_routing est un proxy géométrique conservateur, utile pour relire les ordres de grandeur mais insuffisant pour produire une distance additionnelle stricte.

24_geometric_complements.ipynb

Ce notebook part des sorties des étapes 22 et 23. Il ne recalcule pas les détections. Il produit :

• geometric_cumplots_indicators.png : courbes cumulées des distances et durées ;
• geometric_h3_thematic_stats.csv : statistiques H3 thématiques. La carte H3 active de restitution est territorial_h3_hotspots.html ;
• geometric_survey_parking_graphs.png : graphiques simples sur les variables de stationnement déclaré, lorsqu'elles existent ;
• geometric_commune_summary.csv : analyse communale si geometric_complements.commune_boundaries_file est configuré.

25_routing_dist_excess.ipynb

Ce notebook prépare le calcul routé de dist_excess_m.

Il lit les sorties spatiales 22 et 23 lorsqu'elles existent, puis écrit :

• routing_candidates.parquet ;
• routing_candidates.csv ;
• routing_candidates_xyt_payload.jsonl ;
• routing_candidates_summary.json.

Par défaut, RUN_XYT_ROUTING = False, FORCE_REROUTE = False et APPLY_ROUTED_RESULTS = False. Si RUN_XYT_ROUTING est activé et qu'un cache routing_results.parquet complet existe déjà, le notebook le recharge au lieu de renvoyer les requêtes au routeur. FORCE_REROUTE = True force un nouveau calcul.

La méthode route le tronçon entre spatial_entry_point_wkb_2056 et destination_wkb_2056. Elle ne route pas la leg complète.

Si le routeur local a produit routing_results.parquet, l'application des résultats écrit ensuite spatial_declic_candidates_routed.parquet et pl23_spatial_candidates_routed.parquet, ainsi que routing_geometry_correspondence.parquet et routing_geometry_comparison.html pour comparer géométrie GPS observée et route OSRM distance.

31_temporal_eda_declic.ipynb

Ce notebook part de waypoints_caronly.parquet. Il ne lance pas encore le modèle. Il sert à vérifier :

• les distributions de précision GPS, vitesses et intervalles temporels ;
• la sensibilité du nombre de segments au seuil gap_minutes ;
• les segments qui seront transmis au modèle.

32_temporal_detection_relut_declic.ipynb

Ce notebook lance la chaîne temporelle :

• segmentation intra-leg_id ;
• conversion au contrat ReLUT ;
• validation des segments ;
• prédiction point par point ;
• export de relut_predictions.parquet ;
• figures et carte de relecture temporelle.

Le dernier point de chaque segment reste interprété comme stationnement supposé. C'est l'hypothèse la plus sensible du temps temporel.

41_results_by_approach.ipynb

Ce notebook ne consolide pas encore les deux temps. Il produit une lecture séparée des résultats géométriques et temporels à source commune, et une relecture séparée de PL23 si l'étape 23 a été exécutée :

• nombre de legs ou segments détectés ;
• parts détectées ;
• distances et durées moyennes ou médianes ;
• figure de comparaison des distributions distance/durée pour Déclic.

Il sert à vérifier si un temps de méthode produit un niveau de détection manifestement incohérent avant la consolidation finale. Les lignes PL23 ne doivent pas être interprétées comme une comparaison avec Déclic.

42_compare_spatial_temporal_declic.ipynb

Ce notebook fusionne les résultats par leg_id et produit :

• combined_spatial_temporal_by_leg.parquet ;
• cruising_detected_legs.parquet ;
• cruising_detected_portions.parquet ;
• spatial_temporal_comparison_examples.html, utilisé comme carte de relecture comparative : leg complète, rayon spatial, portion spatiale et portion temporelle ReLUT.

Dans le run livrable actuel, le temps temporel couvre les fichiers de waypoints présents dans le glob configuré. Les résultats géométriques couvrent un périmètre plus large de legs Déclic nettoyées ; toute interprétation globale doit donc préciser la couverture effective des waypoints.

Ce notebook est aussi l'endroit où préparer une future règle hybride géométrique/temporelle, après validation : union pour le repérage sensible, intersection pour une borne stricte, ou règle hiérarchique combinant début temporel et plausibilité géométrique.

43_routed_network_relut.ipynb

Ce notebook part des probabilités ReLUT de l'étape 32 et, lorsque disponible, des géométries routées de l'étape 27.

La carte prioritaire de relecture est :

Output/maps/relut_full_leg_probability_sample.html

Elle affiche un échantillon de legs complètes observées, colorées segment par segment selon la probabilité ReLUT. Elle sert à vérifier visuellement si le signal temporel est localisé dans la bonne partie du trajet.

Le notebook peut aussi produire une couche réseau agrégée, où chaque segment de route porte une probabilité moyenne de recherche de stationnement. Cette sortie sert à spatialiser finement les probabilités temporelles sans superposer toutes les traces individuelles.

44_territorial_indicators.ipynb

Ce notebook part des sorties déjà générées et prépare les tableaux et figures orientés restitution client :

• scénarios de quantification : borne basse, scénario central routé, borne haute, profil temporel ReLUT ;
• typologie descriptive des signaux : boucles, tortuosité, excès de distance, passage près de l'activité, marche après stationnement ;
• hotspots H3 ;
• profil horaire ;
• profil par motif de destination ;
• hotspots réseau ReLUT.

Ce notebook ne remplace pas les étapes 41 et 42. Il change le point de vue : les étapes 41-42 servent au contrôle des méthodes, l'étape 44 sert à raconter ce que représente le cruising sur le territoire observé.

Règle de maintenance

Un notebook peut contenir des paramètres, du markdown de méthode, des appels de fonctions et des affichages. Il ne doit pas contenir une nouvelle logique métier complexe. Toute logique réutilisable doit être ajoutée dans un module Python documenté, puis appelée depuis le notebook et depuis un script.