Incohérences entre la BAN et la BD TOPO

[florimondmanca]

Problème

Nous avons régulièrement des problèmes de correspondance entre les autocomplétions de l'API Adresse (BAN) et le géocodage IGN (BD TOPO)

Par exemple #616 (tirets, et #616 (comment) pour un pb possible sur des accents) et aussi #595 avant ça

Ces incohérences se manifestent dans l'UI sous la forme de "voies non reconnues"

Elles pourraient aussi empêcher d'intégrer des données si on fait appel à l'API Adresse pour "normaliser" les communes / voies, mais ça n'est pour l'instant pas le cas pour Eudonet Paris ni Bac IDF.

Exploration

Dans l'idéal l'autocomplétion et le géocodage devraient utiliser la même source de données

Options possibles

• Utiliser l'API d'autocomplétion (https://data.geopf.fr/geocodage/completion) (Comme suggéré dans Le géocodage d'une voie nommée peut échouer à cause de tirets / traits d'union #616 (comment))
• Utiliser les champs "identifiants d'interopérabilité BAN" de la BD TOPO
  • Avantage : permet de conserver l'API Adresse
  • Inconvénient : nécessite de passer sur la table troncon_de_route ce qui nécessite un refactoring d'ampleur
• Implémenter une recherche d'autocomplétion par-dessus la BD TOPO
  • Cf Incohérences entre la BAN et la BD TOPO #661 (comment)
  • Avantage : on peut continuer à travailler avec voie_nommee, pas besoin de passer sur troncon_de_route
  • Inconvénient : pas trivial si on veut conserver une recherche "fuzzy"
• Explorer techniquement l'intérêt du remplacement de l'API Adresse par l'API IGN pour l'autocomplétion (commune, voie)
  • Est-ce que ça évite les problèmes comme dans Le géocodage d'une voie nommée peut échouer à cause de tirets / traits d'union #616 ?
    • => ❌ NON. L'API de l'IGN semble renvoyer le même nom que l'API Adresse, et pas le nom tel qu'il est stocké dans la BD TOPO. Exemple avec la "Rue du Faubourg Sainte Catherine" : sans tiret dans l'API Adresse, sans tiret dans l'API IGN non plus, AVEC tiret dans la BDTOPO.
  • Est-ce que l'API de l'IGN est aussi fuzzy que l'API Adresse ?
    • => OUI, on dirait bien. Par ex "Famars" donne bien "Rue de Famars" comme résultat.
  • (Optionnel) Etude comparative possible : comparer la liste de résultats pour les premiers caractères de chaque cityLabel en base (autocomplétion commune) ; faire la même comparaison pour les couples cityLabel + les premiers caractères de la roadName (autocomplétion commune)
• Le géocodage d'une voie nommée peut échouer à cause de tirets / traits d'union #616 (comment)
• Explorer d'utiliser la BD TOPO elle-même pour faire les recherches (ce qui est différent d'utiliser le service de géocodage de l'IGN)
  • Une recherche "fuzzy search" (ce que fait l'API Adresse)
    • Plus complexe à implémenter, nécessite un ts_search_vector PostgreSQL
    • UX meilleure et similaire à l'API Adresse

Implémentation

• Improve search autocomplete using BDTOPO #727

[mmarchois]

Ouvrir un ticket sur https://github.com/Geoplateforme/gpf-geocodeur pour signaler l'usage de code_postal par l'API alors que la doc parle de code Insee (et c'est ce qu'on veut), cf #616 (comment)

Apparemment pas possible de créer un ticket sur le repo 🤔

[florimondmanca]

Ah oui mince. Et y'a pas de CONTRIBUTING.Md non plus. Alors il faut passer par le Mattermost BetaGouv ?

Une prise de contact auprès de Jérôme Desboeufs (via email ou Mattermost beta) serait utile je pense.

[johanricher]

Il y a cette adresse email aussi : contact.geoservices@ign.fr

[MathieuFV]

Je fais suivre à mes contacts à l'IGN aussi pour voir si ça peut débloquer la situation

[MathieuFV]

Pour info, après traitement du bug #616 j'arrive à entrer certaines voies qui disposent d'un trait d'union, par exemple la rue Jean-Jacques Rousseau de Saint Ouen sur Seine passe, mais la rue Saint Denis ne passe pas. Il est possible que la rue s'écrive Saint-Denis dans la BD TOPO, ce qui crée un conflit avec l'autocomplete de la BAN.

[florimondmanca]

@mmarchois Quand on regarde la doc et qu'on essaie l'API https://geoservices.ign.fr/documentation/services/services-geoplateforme/geocodage

On peut sans problème utiliser l'option code_insee

curl -X 'GET' \
  'https://data.geopf.fr/geocodage/search?q=famars&index=address&limit=10&returntruegeometry=false&citycode=59606&type=street' \
  -H 'accept: application/json'

Donc en fait je ne sais plus ce qui nous a fait pensé qu'il y avait un bug (il n'y a pas d'option "terr" contrairement à ce que je disais dans #616), mais on dirait qu'on pourrait y aller

[florimondmanca]

En fait l'API géocodage de l'IGN a l'air de s'appuyer sur la BAN directement, et pas la BD TOPO.

En effet voilà la réponse à cette question du ticket:

• Est-ce que ça évite les problèmes comme dans Le géocodage d'une voie nommée peut échouer à cause de tirets / traits d'union #616 ?
  • => ❌ NON. L'API de l'IGN semble renvoyer le même nom que l'API Adresse, et pas le nom tel qu'il est stocké dans la BD TOPO. Exemple avec la "Rue du Faubourg Sainte Catherine" : sans tiret dans l'API Adresse, sans tiret dans l'API IGN non plus, AVEC tiret dans la BDTOPO.

Conséquence, je dirais qu'il n'y a pas d'intérêt véritable à basculer de l'API Adresse à l'API IGN du point de vue de la cohérence API / BD TOPO concernant le géocodage de voies nommées

Il ne reste plus que l'option d'utiliser la clé d'interopérabilité...

Utiliser les champs "identifiants d'interopérabilité BAN" côté IGN. NOTE : ces champs se trouvent dans la table troncon_de_route et non voie_nommee, donc nécessiteraient de migrer vers l'usage de cette table quand on interroge la BD TOPO.

Mais comme écrit ci-dessus le problème qu'on a c'est qu'il faut alors utiliser troncon_de_route. En gros, pour le géocodage de voie nommée, il faudrait alors reconstituer la voie nommée entière à partir des tronçons, au lieu de simplement "piocher" dans voie_nommee. (Il n'y a pas de lien entre ces deux tables, l'IGN semble construire voie_nommee au moment de la mise en livraison. Le champ id_pseudo_fpb a l'air legacy.)

[Une voie nommée] est formée par la concaténation des tronçons de route qui portent le même 'identifiant_voie_1_gauche' et 'identifiant_voie_1_droite'.

Ce n'est pas forcément une mauvaise chose car du point de vue de la BAN, utiliser voie_nommee semble devoir être considéré comme de la dette technique. Cette table n'a aucun champ la reliant à la BAN... ces liens sont dans troncon_de_route.

Ça aurait été utile que la BD TOPO ait une version de voie_nommee basée sur les identifiants BAN... Car là on se retrouve à devoir faire la concaténation nous-mêmes.

[florimondmanca]

Nouveau cas dans Eudonet Paris:

L'arrêté 2023T19817 comporte une localisation sur la "Rue des Docteurs Déjérine"

La BD TOPO connaît "rue des docteurs augusta et jules dejerine"...

[johanricher]

La BAN contient bien cette rue avec ce même libellé donc pas un cas d'incohérence mais un problème de matching entre une donnée en entrée (arrêté) et les référentiels BAN / BD TOPO.

Tentative de synthèse de ma compréhension et convergence vers une solution :

Si on demande à l'API Adresse de matcher une voie dans la BAN avec une donnée en entrée, la réponse de l'API a l'air plutôt satisfaisante : pour reprendre ton exemple et nous renvoie un identifiant (celui dont on parlait plus haut et ici #518 (comment)), qui nous permet alors de faire un rapprochement dans la BD TOPO qu'on a en local avec un tronçon de route et donc une voie (nommée, numérotée, etc.).

Je me plante quelque part ?

[florimondmanca]

un problème de matching entre une donnée en entrée (arrêté) et les référentiels BAN / BD TOPO.

Oui c'est vrai c'est plus un problème côté saisie Eudonet dans ce cas précis.

[florimondmanca]

Si on demande à l'API Adresse de matcher une voie dans la BAN avec une donnée en entrée, la réponse de l'API a l'air plutôt satisfaisante : pour reprendre ton exemple et nous renvoie un identifiant (celui dont on parlait plus haut et ici #518 (comment)), qui nous permet alors de faire un rapprochement dans la BD TOPO qu'on a en local avec un tronçon de route et donc une voie (nommée, numérotée, etc.).

Je n'avais pas pensé à ça, mais effectivement dans le cas d'usage intégration de données, on ne passe pas par l'API Adresse donc on a + de risque qu'un nom de voie saisi soit en décalage par rapport à la BD TOPO.

Pour Eudonet il faudrait donc faire une sorte de pré-traitement en récupérant la voie (nom, id si on arrive à l'exploiter) auprès de l'API Adresse. Pour le cas d'usage UI on le fait déjà puisque les utilisateurs choisissent parmi l'autocomplete dont les choix viennent de l'API Adresse.

[florimondmanca]

Nouvelle piste suggérée par @MathieuFV

Utiliser la BD TOPO elle-même pour faire les recherches (ce qui est différent d'utiliser le service de géocodage de l'IGN)

Deux options de complexité différente

• Une recherche bateau par préfixe (on cherche les voies qui commencent par le terme de recherche)
  • Facile à implémenter
  • UX pas géniale, on peut facilement ne pas trouver ce qu'on cherche
  • => À mon avis à exclure
• Une recherche "fuzzy search" (ce que fait l'API Adresse)
  • Plus complexe à implémenter, nécessite un ts_search_vector PostgreSQL
  • UX meilleure et similaire à l'API Adresse