API Adresse (Base Adresse Nationale - BAN)

Bonjour, À ce jour, l'API ne permet pas de récupérer dans des champs distincts le type de voie (rue, avenue, boulevard, etc.) ni les compléments de numéro (bis, ter, quater, etc.). Les données sont diffusées telles qu'elles sont décrites dans la Base Adresse Nationale (BAN), dont la responsabilité de saisie relève des communes. Aucun retraitement visant à isoler ces informations n'est actuellement prévu. Si vous souhaitez disposer de ces éléments séparément, un traitement devra être réalisé côté applicatif à partir du libellé d'adresse retourné par l'API. Bonne journée Karim

Bonjour, Vous est il possible d'apporter plus d'éléments, je n'arrive pas à reproduire voici un exemple : https://data.geopf.fr/geocodage/search?q=Pont-de-Montvert Bonne journée Karim

Bonjour, Merci pour votre retour, après vérification, c'est l'usage que j'ai fait d'une fonction php qui coupe à l'octet au lieu du caractère qui a provoqué le problème. La coupure ayant été effectuée sur un caractère accentué, c'est ce qui expliquait l'erreur. La norme postale "impose" de ne pas avoir plus de 38 caractères (cp + ville) (https://cnig.gouv.fr/IMG/pdf/prj_standard_adresse_pour_revue.pdf) : par conséquent n'est-ce pas étonnant d'avoir des villes qui font plus de 32 caractères dans cette API ? Bonne journée,

Bonjour, La BAN ne limite pas la longueur du nom de la commune. Elle diffuse les noms officiels des communes tels qu’ils sont définis par l’INSEE (et issus des arrêtés administratifs), sans appliquer de contrainte postale. La règle du CNIG relève d'un usage postal et d'acheminement et non une règle de dénomination administrative. Bonne journée Karim

Bonsoir, Merci pour l'explication, c'est très clair ! Bien à vous

Bonjour, Veuillez nous excuser pour le délai de traitement, avez vous testé d'utiliser le WFS ? Le Géocodage ne permet pas d'interroger l'ID BAN, l'API de géocodage de la Géoplateforme a pour but de fournir des coordonnées à partir d’une adresse ou d’une parcelle cadastrale (ou à l’inverse de fournir le localisant le plus proche à partir de coordonnées). Bonne journée Karim

Bonjour, Cela dépend du contexte métier (livraison, facturation, etc.), mais voici des repères courants : ≥ 0.95 : quasi parfait → adresse considérée comme exacte. 0.85 – 0.95 : très proche → généralement fiable pour livraison, mais vérifier si le numéro de rue est correct. 0.70 – 0.85 : correspondance approximative → risque d’erreur (ex. rue correcte mais ville différente). < 0.70 : faible → nécessite validation manuelle. Bonne journée Karim

Bonjour, Suite de nos travaux : il existe un paramétrage dans l'appel à l'API qui change considérablement le score et donc l'interprétation que l'on en fait. Par exemple pour une saisie "25 rue" à Villeurbanne, qui a priori ne garanti pas la livraison nous avons : - Un score de 0,52 avec autocomplete à 0 (cela correspond à un appel de type saisie "égale" ?) : https://api-adresse.data.gouv.fr/search?q=25%20rue&postcode=69100&City=Villeurbanne&autocomplete=0&index=address&limit=1&returntruegeometry=false - Un score de 0,89 avec autocomplete à 1 (cela correspond à un appel de type "commence par" ou "contient" ?) : https://api-adresse.data.gouv.fr/search?q=25%20rue&postcode=69100&City=Villeurbanne&autocomplete=1&index=address&limit=1&returntruegeometry=false 1) Manifestement, le premier choix s'impose pour fiabiliser nos livraisons. Est-ce que vous confirmez que c'est le meilleur usage de ce paramètre dans ce contexte ? 2) Existe-t-il d'autres paramètres dans l'API qui font varier le score de cette manière ? Si oui, comment les configurer afin d'obtenir un score exploitable pour fiabiliser des livraisons ?

Bonjour Pour fiabiliser vos livraisons avec l’API Adresse, il est important de bien comprendre l’impact des paramètres sur le score retourné. Le paramètre autocomplete joue un rôle majeur : lorsqu’il est fixé à 0, la recherche est stricte et privilégie une correspondance exacte ou très proche de la saisie. Cela permet d’obtenir un score qui reflète réellement la précision de l’adresse saisie, ce qui est essentiel pour éviter les faux positifs. À l’inverse, avec autocomplete=1, la recherche devient tolérante et complète ou corrige la saisie, ce qui peut être utile pour l’assistance à la saisie, mais présente un risque pour la validation, car le score peut être élevé même si l’adresse initiale est incomplète. Pour la validation avant livraison, il est donc recommandé d’utiliser autocomplete=0. D’autres paramètres influencent également le score. Il est conseillé de fournir une requête la plus complète possible (numéro, rue, code postal, ville) et de renseigner systématiquement le code postal et la ville pour réduire les ambiguïtés. L’index doit rester sur address afin de cibler les adresses précises, et il est préférable de limiter la réponse à un seul résultat (limit=1) pour éviter les confusions. Enfin, il est judicieux de mettre en place un seuil de score (par exemple 0,80) pour considérer une adresse comme fiable. En option, on peut utiliser la latitude et la longitude pour favoriser un match proche d’une position connue. Bonne journée Karim

Bonjour, Merci pour cette réponse rapide, si je résume dans les recommandations nous devons avoir : - autocomplete=0 - limit=1 - index=address Lors de nos tests nous avons eu l'impression que le paramètre : - type=housenumber Nous aidait à obtenir un score "crédible", est-ce à retenir aussi ou une illusion ?

Bonjour, La recherche via le paramètre q n’interprète pas les mots comme des opérateurs booléens (AND / OR). Elle fonctionne par tokenisation et similarité (Addok). Les résultats peuvent être imprécis si la requête contient trop de mots ou des noms d’établissements (ex. « Hôpital Nord Laënnec »). Je vous recommande d'utiliser les filtres disponibles citycode (INSEE) ou postcode pour contraindre la commune. Exemple pour Saint-Herblain (code INSEE : 44162) : https://api-adresse.data.gouv.fr/search?q=boulevard%20jacques%20monod&citycode=44162&type=street&lat=47.2360&lon=-1.6403&limit=5 Bonne journée Karim