Nous prenons en main addok à Rennes Métropole pour le déployer en interne.
Me replongeant trèèèèèès longtemps après dans ce logiciel on trouve bien la doc de référence (https://addok.readthedocs.io/) qui documente bien le logiciel mais peu sur le format de données.
Sur cette page : Import - Addok on lit pour importance que c’est un chiffre entre zéro et un. Super…
Je pose la question car nos utilisateurs et nous-même pensions que c’était le score d’appariement mais que nenni car le chiffre qui apparaît est le chiffre présent dans le fichier addok importé dans l’API comme source de données.
Bonjour Maël,
L’importance d’une adresse BAN est calculée par l’équipe en charge de la BAN. Si je me souviens bien et en vulgarisant beaucoup, il se base sur la taille de la commune et la taille de ses voies. Cela permet de dire que la rue De Gaulle de Paris et plus “importante” que la rue De Gaulle de Trifouillis-les-Deux-Oies.
Le score présent dans la réponse d’Addok prend en compte cette “importance”, mais aussi la pertinence du résultat par rapport à la requête de l’utilisateur. Si l’utilisateur a tapé “de gaulle trifouillis”, l’adresse sera certes moins “importante” mais plus “pertinente” (distance de Levenstein ?), et donc affichera un meilleur score “final”.
PS : le score final peut aussi être impacté par un 3e score si un XY est founi lors de la requête : le score final prendra alors compte de l’importance, de la pertinence et de l’éloignement géographique (au XY fourni).
On aurait très bien pu retourner les 3 composantes du score (la distance textuelle, la distance géo, l’importance) et laisser le client choisir de trier comme il veut, mais ça semblait plus simple de fournir un score global.
Pour la distance textuelle, c’est une combinaison de trigrammes et un peu de distance de Levenshtein (pour départager “Rue de Paris à St Mandé” et “Rue de St Mandé à Paris”).
On aurait très bien pu retourner les 3 composantes du score (la distance textuelle, la distance géo, l’importance) et laisser le client choisir de trier comme il veut
Oui : c’est exactement ça qu’il manque dans un contexte de remplacement d’outils de géocodage adresse “pro” par Addok car il manque ce genre de paramètres !
L’importance d’une adresse BAN est calculée par l’équipe en charge de la BAN
OK : c’est donc eux également qui discrimine les types (street /locality). Et ça fiche la pagaille. je vais me rapprocher d’eux en ce cas.
On a d’autres choses à remonter en terme de besoin d’évolutions. Un manque rédhibitoire c’est la recherche en entonnoir !!! Ce serait pourtant pas compliqué. On va coder un plugin python branché sur nos données internes pour pallier à ça. C’est dommage. Comment contribuer directement au cœur ? Parce que Redis…
Encore une autre lecture
Merci Christian. On voulait rajouter des POI et autres localisants (ZAC…) je vais explorer cette piste de rajout au fichier importé.
Saisie de la commune, puis de la voie, puis du numéro ?
Ce n’est plus du tout du géocodage, mais un formulaire de saisie. Le but d’addok est justement d’éviter ça avec l’autocomplétion.
Si il s’agit de géocoder des données existantes, les filtre d’addok permettre de limiter la recherche à une commune quand tu as l’info séparée dans tes données.
Donc ma question finale est simple… vous voulez faire quoi précisément ?
On est d’accord mais on ne peut pas se permettre (collectivement) d’avoir 1 API pour le géocodage et 1 autre API pour la recherche en entonnoir. Les réutilisateurs (développeurs, prestataires, etc) qu’on renvoie vers /search/ ont aussi besoin d’une bête recherche par entonnoir.
Je pensais naïvement jusqu’il y a qqs mois que c’était possible mais non pas du tout et ça plante / retarde des projets. ça ne doit pas être bien compliqué à rajouter vu que les données sont toutes là.
Mais on s’éloigne de mon sujet initial de mon post… Je propose d’ouvrir une discussion dans un post spécifique préalablement à un une énième issue sur github ?