Bonjour,
Avec la casquette Etalab, j’ai rédigé de la documentation pour utiliser les APIs Adresse, Découpage Administratif et OpenMapTiles Introduction | guides.etalab.gouv.fr (source sur https://github.com/etalab/guides.etalab.gouv.fr/tree/master/apis-geo)
N’hésitez pas à nous faire des retours sur le contenu.
Merci de vos retours
Bonjour Thomas.
Excellent ! En particulier le fait de ne plus dépendre de l’API de Google !
Savez-vous s’il est possible d’afficher avec ce même interface :
Merci
Merci, c’est très intéressant.
Sur l’API adresses, une explication serait bienvenue sur le « score » qui peut quelques fois déterminer si l’adresse trouvée est bien celle recherchée ou bien si elle s’en rapproche seulement.
Des seuils à partir desquels c’est très approximatif, des explications sur son calcul…
Dans les ressources complémentaires, vous pouvez citer le MOOC : La gestion des adresses par les communes
Sur les tuiles, j’ai un besoin un peu différent et peut-être pourrez-vous m’aider.
Quelques éléments ici:
On ne peut malheureusement pas donner un score à partir duquel on peut considérer que l’adresse trouvée est bien celle cherchée, car cela dépend fortement de la qualité des deux adresses et de la façon dont elles sont libellées.
Avec la version 1.1 d’addok le mode de calcul a aussi un peu changé.
Merci @cquest . Très intéressant d’en savoir un peu plus sur ce qu’il y a sous le capot.
Sur le score, je suis bien conscient que c’est un challenge. Cependant sur des applications/services « à l’adresse », il est important d’avoir LA bonne adresse. Et on ne peut pas toujours proposer un autocomplete à l’utilisateur. Quelques fois on part d’adresses « normalisées » à partir de référentiels différents (Google, La poste) dont la nomenclature peut être différente de celle de la BAN. Ou d’adresse pas du tout normalisée issues de champs de saisie « libres » 
En tout cas pour nous cette notion de score est très importante.
La « normalisation »… si il s’agit de la norme NF à destination de l’usage postal, elle ne s’occupe que de faire tenir l’adresse dans les fenêtres des enveloppes 
De plus elle n’est même pas d’accès libre et même La Poste ne la respecte pas entièrement.
C’est sûr que l’approche d’addok était plutôt à l’origine l’autocomplétion, d’où ce mode de fonctionnement très orienté recherche full-text et le mode de calcul du score.
En tout cas, je suis preneur de suggestions pour améliorer ça !
Est-ce que fournir un forme structurée de l’adresse à chercher pourrait être une piste à suivre ?
Il faut aussi exploiter au maximum les filtres d’addok, qui permet de limiter la recherche à un sous ensemble de la base, par exemple en fournissant le code INSEE de la commune ou le code postal.
Ceci élimine le risque de résultats incorrects mais proches textuellement (exemple: Rue de Paris à St Mandé vs Rue de Saint-Mandé à Paris).
J’ai envisagé de fournir le score de l’adresse suivante car si il est trop proche de la première, c’est un bon indicateur de confusion possible.
Oui ! En découpant numéro / rue / CP / Ville, il est surement possible d’améliorer le matching et d’avoir un score plus exploitable.
Ça serait presque une autre API…
Une information du genre : l’API a trouvé la rue (dans la « bonne ville »), mais le numéro n’existe pas (encore) dans cette rue, pourrait être aussi intéressante.
Cela pourrait aider sur des cas ou l’adresse est récente (bâtiment neuf) ou la municipalité n’a pas fini de compléter son référentiel d’adresse.
C’est déjà le cas, si le numéro n’est pas trouvé, addok ne retourne que l’info sur la rue avec un type=street
Exemple: https://demo.addok.xyz/search?q=555+avenue+de+la+republique&citycode=94068
{
"type": "FeatureCollection",
"version": "draft",
"features": [
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [
2.486021,
48.802021
]
},
"properties": {
"label": "Avenue de la République 94100 Saint-Maur-des-Fossés",
"score": 0.7167318593171534,
"id": "940688165Y",
"citycode": "94068",
"type": "street",
"name": "Avenue de la République",
"postcode": "94100",
"city": "Saint-Maur-des-Fossés",
"departement": "Val-de-Marne",
"region": "Île-de-France",
"importance": 0.4459,
"street": "Avenue de la République"
}
},
...
Oui et oui
1000 mercis Thomas je vais regarder avec attention.
Peut-être des exemples sont plus parlants:
https://api-adresse.data.gouv.fr/search/?q=19%20rue%20Chappe%2063100%20CLERMONT%20FERRAND
retourne bien un
label": "19 Rue Chappe 63100 Clermont-Ferrand"
avec un bon score (0.977)
Mais https://api-adresse.data.gouv.fr/search/?q=19%20rue%20Chappe%2063000%20CLERMONT%20FERRAND
(avec un CP changé de 1 caractère) retourne une rue complètement différente :
"label": "19 Rue de Cotepet 63000 Clermont-Ferrand"
avec un score de 0.656
https://api-adresse.data.gouv.fr/search/?q=54%20BOULEVARD%20CLEMENCEAU%2035000%20RENNES
retourne bien le
label": "54 Boulevard Georges Clemenceau 35200 Rennes"
mais avec un score de 0.672
Et donc quand on a ces adresses en entrée, c’est difficile pour nous de les rattacher au bon endroit…
@cquest, un autre comportement un peu étrange (mais surement explicable ):
https://api-adresse.data.gouv.fr/search/?q=rue%20de%20rouen%2080080%20Amiens
"properties": {
"label": "Rue de Rouen 80000 Amiens",
"score": 0.7680531468531469,
"id": "80021_7030",
"name": "Rue de Rouen",
"postcode": "80000",
"citycode": "80021",
"x": 648081.52,
"y": 6976662.51,
"city": "Amiens",
"context": "80, Somme, Hauts-de-France",
"type": "street",
"importance": 0.8332,
"street": "Rue de Rouen"
https://api-adresse.data.gouv.fr/search/?q=Rue%20de%20rouen%2080080%20Amiens
"properties": {
"label": "Rue de Doullens 80080 Amiens",
"score": 0.5995446920821114,
"id": "80021_2750",
"name": "Rue de Doullens",
"postcode": "80080",
"citycode": "80021",
"x": 650036.21,
"y": 6978841.6,
"city": "Amiens",
"context": "80, Somme, Hauts-de-France",
"type": "street",
"importance": 0.78854,
"street": "Rue de Doullens"
En changeant un caractère, majuscule/minuscule on a un résultat très différent.
Et en entreprenant le meilleur résultat obtenu, (nom de la rue avec les majuscules) on a un résultat différent de l’input qui était pourtant (mis à part le CP) la réutilisation d’un output de l’API
C’est très étrange car tout est mis en minuscules (en principe) au tout début du traitement…
En répétant les appels, j’obtiens des résultats différents.
Ceci me fait penser à un problème de chargement incomplet de la BAN sur un des backend addok car il n’y a pas de raison qu’une même requête retourne des résultats variables.
Bien sûr, je n’arrive pas à reproduire le bug sur mon instance:
https://ban.addok.xyz/search/?q=Rue+de+rouen+80080+Amiens
Il faut voir avec l’équipe actuelle… cela fait 5 ans que je ne m’occupe plus de cette API
Maintenant quand je refais des tests, le comportement est inversé !
Email envoyé, je vous tiendrais au courant…