documentations/kpi_health_check_map_v2_plan.md

KPI Health Check – Map v2 (Mode exploitation + recherche)

Objectif

Améliorer l’onglet Map pour l’exploitation quotidienne (≈ 0–3000 sites) avec:

• Vue géographique lisible immédiatement (zoom/centrage automatique)
• Encodage visuel orienté actions (status + criticité)
• Recherche rapide (site_code / City) + navigation vers le drill-down
• Performance stable (pas de lag, pas de sur-affichage de labels)

Non-objectifs

• RCA hints / tags automatiques (Sprint 5)
• Clustering avancé “maison” (geohash/grid) si non indispensable
• Historique temporel sur la map

UX / Fonctionnel

A. Encodage visuel

• Taille: criticité (déjà en place)
• Couleur: status dominant du site (ex: PERSISTENT_DEGRADED, DEGRADED, RESOLVED, NO_DATA)
• Label: site_code (déjà en place) limité à un Top-N configurable

B. Fit bounds (centrage auto)

• Bouton (ou comportement automatique) “Fit to points”
• À chaque refresh map, centrer/zoomer sur l’ensemble des points affichés (après filtres)

C. Filtres Map (mode exploitation)

Widgets simples dans l’onglet Map:

• Top N sites (par score) + option “All”
• Only complaint sites (reprend le bool déjà existant dans le sidebar)
• RAT impacted (2G/3G/LTE/Any) basé sur impacted_rats
• Option: “Only persistent” (status)

D. Recherche (rapide)

• Champ Search (texte):
  • accepte site_code (entier) ou City (substring)
  • résultat:
    • si site_code trouvé: centre la map sur le site + sélectionne le site (drill-down)
    • si City: filtre/centre sur les sites de la ville + propose une petite liste (Top 20) cliquable

E. Interaction

• Click point => drill-down (déjà en place)
• Option: bouton “Open Drill-down” à côté des infos (si on ajoute un mini panneau résumé)

Données / Hypothèses

• Les coords sont présentes via Latitude/Longitude (venant du physical_db)
• current_multirat_raw contient:
  • site_code
  • scores (criticality_score_weighted ou criticality_score)
  • impacted_rats
  • compteurs persistent/degraded/resolved
• Les status par RAT existent dans current_status_df (par site_code, RAT, status)

Plan d’implémentation (Map v2)

1) Calcul du status dominant

• À partir de current_status_df, agréger par site_code:
  • règle: PERSISTENT_DEGRADED > DEGRADED > RESOLVED > OK > NO_DATA
  • produire une colonne dominant_status
• Merge dans le DF map

2) Color mapping

• Définir une palette stable:
  • PERSISTENT_DEGRADED -> rouge foncé
  • DEGRADED -> rouge/orange
  • RESOLVED -> vert
  • OK -> bleu
  • NO_DATA -> gris
• Appliquer via px.scatter_mapbox(..., color='dominant_status') + category_orders

3) Fit bounds

• Calculer lat_min/max, lon_min/max sur les points affichés
• Utiliser fig.update_layout(mapbox=dict(bounds=...)) ou center/zoom estimé
• Ajouter un bouton “Fit to points” si on veut éviter un recentrage automatique trop agressif

4) Recherche

• Widget AutocompleteInput ou TextInput + bouton Go
• Si nombre:
  • set site_select + centre map
• Si texte:
  • filtrer sur City et afficher une liste cliquable (Tabulator ou Select)

5) Filtres Map

• Implémenter filtres (TopN / complaint / RAT impacted / status) avant rendu
• Ajouter widgets correspondants dans l’onglet Map

6) Tests / Critères de réussite

• 3000 sites: refresh map < 2s (hors 1er chargement)
• Search par site_code: centre + drill-down correct
• Search par City: restreint l’affichage et fit bounds
• Les labels restent limités (Top-N)

Risques / Points d’attention

• Trop de texte (labels) => perf (mitigation: Top-N déjà fait)
• Fit bounds automatique peut “bouger” la map trop souvent (mitigation: bouton / toggle)
• dominant_status doit être robuste même si current_status_df vide

Estimation

• Status dominant + colors: 45–90 min
• Fit bounds: 20–40 min
• Recherche: 1–2 h
• Filtres map: 1–2 h

Total: ~3–6 h selon niveau de polish.