refactor(search): remplacer l’index .six hors-ligne par find/json + lignes en mémoire #6

New issue

Closed

opened 2026-06-23 19:58:52 +02:00 by CyrilLeblanc · 0 comments

CyrilLeblanc commented

2026-06-23 19:58:52 +02:00

Owner

Contexte

La recherche lit aujourd'hui un index binaire bundlé assets/grenoble-search.six (data/local/SearchIndex.kt) qui indexe 3 types — LINE, STOP, ADDRESS — et fonctionne 100 % hors-ligne. Cet index est généré à froid par scripts/generate_addresses.py (transit-data.json + géocodage BAN), est gitignoré, et doit être régénéré à chaque évolution du réseau. Cela ajoute du poids à l'APK, un pipeline à maintenir, et fige des données (adresses, noms d'arrêts) qui évoluent côté M réso.

L'API M réso find/json couvre nativement la recherche d'arrêts et d'adresses à jour ; les lignes (jeu borné, ~60) sont déjà chargées en RAM depuis Room.

Comportement attendu

Supprimer l'index .six et son pipeline, et répartir la recherche sur trois sources :

Lignes → recherche en mémoire depuis state.lines (Room), filtre sur shortName/longName. Reste hors-ligne.
Arrêts (clusters) → GET https://data.mobilites-m.fr/api/find/json?query=<q>&types=clusters&epci=All. L'API renvoie un GeoJSON dont features[].properties.id (ex. SEM:VICTHUGO) matche directement les ClusterData.id de l'app → résolution Room pour les données complètes.
Adresses → find/json?types=rue,lieux (remplace BAN). Couvre l'agglomération M réso (LaMetro).

Décisions retenues :

Recherche en ligne : arrêts + adresses nécessitent le réseau ; lignes hors-ligne. Accepté (robustesse > hors-ligne partiel).
Couverture adresses : agglomération seulement (find/json remplace BAN).
Types : clusters,rue,lieux uniquement (pas de POI M réso secondaires : parkings, recharge…).

Pistes d'implémentation

Nouvel endpoint Retrofit findJson(query, types, epci) → désérialisation du GeoJSON (FeatureCollection → features[].properties.{type,id,name,city} + geometry.coordinates). L'intercepteur Origin existe déjà (TransitApp.kt).
SearchViewModel : debounce (~250–300 ms) avant l'appel ; fusion des résultats lignes (mémoire) + clusters/adresses (API) ; état « recherche indisponible hors-ligne » explicite plutôt qu'un crash.
Supprimer data/local/SearchIndex.kt, l'asset assets/grenoble-search.six, scripts/generate_addresses.py, et l'import du .six au premier lancement.

Critères d'acceptation

Rechercher une ligne (« C11 », « tram A ») → apparaît (Room, hors-ligne).
Rechercher un arrêt (« victor hugo ») → apparaît et est résolu en données complètes depuis Room (find/json clusters).
Rechercher une adresse/rue → résultat géocodé utilisable en origine/destination Plan (find/json rue/lieux).
Sans réseau : la recherche de ligne fonctionne ; une recherche d'arrêt/adresse affiche un message clair au lieu de planter.
Plus aucun .six dans les assets ni le build ; assembleRelease OK.
Aucune régression sur le routage (Plan) ni l'exploration de ligne (Search).

## Contexte La recherche lit aujourd'hui un index binaire bundlé `assets/grenoble-search.six` (`data/local/SearchIndex.kt`) qui indexe 3 types — `LINE`, `STOP`, `ADDRESS` — et fonctionne 100 % hors-ligne. Cet index est généré à froid par `scripts/generate_addresses.py` (transit-data.json + géocodage BAN), est gitignoré, et doit être régénéré à chaque évolution du réseau. Cela ajoute du poids à l'APK, un pipeline à maintenir, et fige des données (adresses, noms d'arrêts) qui évoluent côté M réso. L'API M réso `find/json` couvre nativement la recherche d'arrêts et d'adresses à jour ; les lignes (jeu borné, ~60) sont déjà chargées en RAM depuis Room. ## Comportement attendu Supprimer l'index `.six` et son pipeline, et répartir la recherche sur trois sources : - **Lignes** → recherche **en mémoire** depuis `state.lines` (Room), filtre sur `shortName`/`longName`. Reste hors-ligne. - **Arrêts (clusters)** → `GET https://data.mobilites-m.fr/api/find/json?query=<q>&types=clusters&epci=All`. L'API renvoie un GeoJSON dont `features[].properties.id` (ex. `SEM:VICTHUGO`) matche directement les `ClusterData.id` de l'app → résolution Room pour les données complètes. - **Adresses** → `find/json?types=rue,lieux` (remplace BAN). Couvre l'agglomération M réso (LaMetro). Décisions retenues : - **Recherche en ligne** : arrêts + adresses nécessitent le réseau ; lignes hors-ligne. Accepté (robustesse > hors-ligne partiel). - **Couverture adresses** : agglomération seulement (find/json remplace BAN). - **Types** : `clusters,rue,lieux` uniquement (pas de POI M réso secondaires : parkings, recharge…). ## Pistes d'implémentation - Nouvel endpoint Retrofit `findJson(query, types, epci)` → désérialisation du GeoJSON (`FeatureCollection` → `features[].properties.{type,id,name,city}` + `geometry.coordinates`). L'intercepteur `Origin` existe déjà (`TransitApp.kt`). - `SearchViewModel` : debounce (~250–300 ms) avant l'appel ; fusion des résultats lignes (mémoire) + clusters/adresses (API) ; état « recherche indisponible hors-ligne » explicite plutôt qu'un crash. - Supprimer `data/local/SearchIndex.kt`, l'asset `assets/grenoble-search.six`, `scripts/generate_addresses.py`, et l'import du `.six` au premier lancement. ## Critères d'acceptation - [ ] Rechercher une ligne (« C11 », « tram A ») → apparaît (Room, hors-ligne). - [ ] Rechercher un arrêt (« victor hugo ») → apparaît et est résolu en données complètes depuis Room (find/json `clusters`). - [ ] Rechercher une adresse/rue → résultat géocodé utilisable en origine/destination Plan (find/json `rue`/`lieux`). - [ ] Sans réseau : la recherche de ligne fonctionne ; une recherche d'arrêt/adresse affiche un message clair au lieu de planter. - [ ] Plus aucun `.six` dans les assets ni le build ; `assembleRelease` OK. - [ ] Aucune régression sur le routage (Plan) ni l'exploration de ligne (Search).

CyrilLeblanc added the

enhancement

label

2026-06-23 19:58:52 +02:00

CyrilLeblanc referenced this issue

2026-06-23 20:51:16 +02:00

feat(ux): état hors-ligne / échec réseau dans la liste des passages #11

CyrilLeblanc referenced this issue from a commit

2026-06-23 21:41:18 +02:00

refactor(search): remplacer l'index .six par find/json + lignes en mémoire

CyrilLeblanc closed this issue

2026-06-23 21:41:18 +02:00