Intégrer les adresses de la BAN #2001

Décrivez votre problème, votre suggestion

Salut! On aimerait intégrer les adresses (recherche et layer) depuis la BAN plutôt que BANO pour plus de complétude. Je peux me charger de proposer une PR.
Il s'agirait d'utiliser l'API Adresse pour les recherches d'adresse (https://data.geopf.fr/geocodage/openapi)
Et pour la carto, des tuiles vectorielles de la BAN sont disponibles ici https://plateforme.adresse.data.gouv.fr/tiles/ban/z/x/y.pbf

Ça parait jouable?

Système d'exploitation

No response

Navigateur

No response

@MaGOs92 et moi-même travaillons pour le programme BAL, à votre disposition pour échanger et participer à l'intégration technique.

L'idée serait d'avoir plus de complétude car aujourd'hui :

• la BANO c'est 12 millions d'adresses
• la BAN c'est 26 millions d'adresses, dont 22 millions issues de bases adresses locales (produites par les mairies, donc censées être fiables)
  https://bano.openstreetmap.fr/stats/france_par_dept.html

Les contributeurs OSM intègrent progressivement les adresses BAN manuellement, mais c'est un chantier très long qui prendra du temps, nous travaillons avec eux sur le sujet.

À l'heure actuelle, la seule plateforme qui intègre les adresses BAN c'est l'IGN avec le Géoportail et "Cartes IGN" à ma connaissance.
Google map, apple map et consorts sont complètement dans les choux niveau adresses, puisqu'ils ont initié leurs données avec des fichiers adresses propriétaires (SNA de la Poste par exemple), ce qui engendre des conflits lorsqu'ils tentent de récupérer les adresses BAN.
CoMpaps, OrganicMaps, Osmand... utilisent les adresses BANO comme vous le savez.

Il n'existe donc l'heure actuelle aucune plateforme opensource exploitant les adresses BAN.

Merci pour le ticket ! Oui ce serait très cool d'utiliser ça. Je pense que dans un premier temps on pourrait faire les requêtes d'adresse seulement si pas de réponse de notre API de recherche, Photon.

Il faudrait identifier des adresses qui sont dans la BAN mais pas dans Photon.

Car le problème, c'est de gérer les deux résultats de deux sources différentes.

• Je cherche "12 rue des lilas à Ploumoguer" (fictif)
• si Photon l'a, est-ce important d'aussi faire une requête BAN ? Je pense que c'est bien moins important que de gérer les requêtes introuvables
• si elle est introuvable, et que la recherche se fait depuis la France (métropolitaine ?), on peut lancer la requête secondaire
• mais il faut gérer l'hypothèse que Photon renvoie quand même des résultats : comment être sûr que ces résultats sont les mauvais ? Du style, la rue sans le numéro, ou n'importe quoi d'autre

Je sais qu'il y a https://openaddresses.io . après, je ne sais pas comment ça marche et si ça gère le dédoublonnage ?

@Cayenne79 wrote in #2001 (comment):

Je sais qu'il y a https://openaddresses.io . après, je ne sais pas comment ça marche et si ça gère le dédoublonnage ?

Ça utilise la BAN pour la France et a une couverture mondiale.

Le projet a l'air solide

Clairement une piste à creuser

@laem wrote in #2001 (comment):

• mais il faut gérer l'hypothèse que Photon renvoie quand même des résultats : comment être sûr que ces résultats sont les mauvais ? Du style, la rue sans le numéro, ou n'importe quoi d'autre

Effectivement, Photon risque assez souvent de renvoyer des rues sans les numéros... Je ne vois pas trop comment gérer ces cas

Effectivement, Photon risque assez souvent de renvoyer des rues sans les numéros... Je ne vois pas trop comment gérer ces cas

Ça c'est assez simple à gérer côté client : on compare le résultat Photon et on propose celui qui est le plus précis.

Merci @laem du coup, comment peut-on aider à l'intégration ?

Comme je le disais plus haut, il faut partir du problème, concrètement : un jeu de 4-5 adresses qui ne sont pas trouvables sur cartes.app mais qui sont dans la BAN.

À partir de là, on regarde la réponse actuelle et on la "patch" avec un appel à la BAN côté client.

On vérifie que ça n'implique pas une requête inutile pour les recherches qui ne sont pas des adresses, ou les recherches pour lesquelles Photon trouve les bons résultats, et les recherches en dehors du périmètre de la BAN.

Je pense que ce serait déjà un super ajout très utile.

Voici quelques exemples, pris au hasard en utilisant Pifomap

2 exemples de voies présentes dans OSM mais sans numéros/adresses :

• voies dans OSM sans les adresses Rue des Fauvettes, Méral et voie avec les adresses dans la BAN
• voies dans OSM sans les adresses Rue du Val d'Hortus, Mas-de-Londres et voie avec les adresses dans la BAN

3 exemples d'absence totale de nom de voie et d'adresses dans OSM :

• Chemin du petit Jas, Saint-Martin-de-Castillon (84112) dans OSM et dans la BAN
• Le Bourg, Saint-Martial-Entraygues (19221) dans OSM et dans la BAN
• Chemin du Moulin, Salérans (05160) dans OSM et dans la BAN

pour info, je signale tous les tickets avec le label Recherche
https://codeberg.org/cartes/web/issues?labels=1331235

En lien : !1230

@severo nous signale le geocodeur pelias, qui a l'avantage de combiner données OSM et OpenAdresses.
Est ce que l'un de vous connaît et a un avis ?
https://pelias.io/
https://github.com/pelias

^ la mise à jour n'est pas forcément simple, si j'ai bien compris il faut refaire tous les index ElasticSearch pour remplacer les existants, à chaque mise à jour. Et ça prend une dizaine d'heures sur une grosse machine. Pour Photon, l'avantage est que l'index déjà calculé est publié sur https://download1.graphhopper.com/public/ chaque semaine.

Pour information @laem @LySioS @Cayenne79 @etienneJr : CoMaps a ouvert une PR afin d'intégrer les adresses de OpenAddresses : comaps/comaps#4162

@laem penses-tu que l'intégration via OpenAddresses est la bonne solution ?

@obliv wrote in #2001 (comment):

@laem penses-tu que l'intégration via OpenAddresses est la bonne solution ?

N'hésite pas à le resolliciter la semaine prochaine, il est en vacances actuellement

@LySioS wrote in #2001 (comment):

@obliv wrote in #2001 (comment):

@laem penses-tu que l'intégration via OpenAddresses est la bonne solution ?

N'hésite pas à le resolliciter la semaine prochaine, il est en vacances actuellement

Et à présenter cette solution si tu as des informations sur comment ça marche, si ça intègre le jeu de données de la BAN, comment ça s'héberge ou s'il y a une autre solution pour y avoir accès...

@pmiossec wrote in #2001 (comment):

Et à présenter cette solution si tu as des informations sur comment ça marche

pas plus d'information que le ticket CoMaps en cours : comaps/comaps#4162

@pmiossec wrote in #2001 (comment):

si ça intègre le jeu de données de la BAN

oui !

J'appréhende le moment où qq va devoir écrire la routine qui fusionnera le résultat de requête photon (qui aura les POI mais pas toutes les adresses) avec le résultat de requête BAN ou OpenAddresses ou autre (qui aura les adresses mais pas les POI) en supprimant les doublons ...

Mais je ne dis pas qu'il ne faut pas le faire, au contraire, ça sera incroyable quand on aura résolu ce ticket !

@obliv @MaGOs92 vous auriez du temps pour faire une POC ?

Ah mais si je comprends bien, OpenAddresses c'est juste une compilation des fichiers sources d'adresses, ya pas de soft pour faire des requêtes, donc faudrait utiliser pelias, ce qui impose de recalculer les index elasticsearch à partir de zéro à chaque mise à jour, la galère...

@severo wrote in #2001 (comment):

Et ça prend une dizaine d'heures sur une grosse machine.

• pour quelle couverture ?
• en incluant des données OSM ? ou seulement des données d'adresses ?

Couverture : planet

C'est très largement OpenAddresses qui prend le plus de temps, genre 95%, dans mon cas (Brésil)

je n'ai pas compris : si tu as fait une couverture mondiale, qu'est-ce qui est restreint au Brésil ?

La dizaine d'heure j'ai lu ça sur une doc de pelias, et c'était sur une machine beaucoup plus grosse que mon portable.

Moi je n'ai travaillé que sur le Brésil. Mais j'imagine que le temps relatif entre les différents jeux de données sera à peu près le même.

@etienneJr wrote in #2001 (comment):

@obliv @MaGOs92 vous auriez du temps pour faire une POC ?

Alors moi je ne serai pas d'une grande aide n'étant pas dev, mais @MaGOs92 pourrait dégager un peu de temps je pense oui

Bonjour à tous,

J'ai commencé un POC (PR : #2365) pour intégrer les adresses BAN dans la recherche.

Voici où j'en suis :

• Quand on fait une recherche via la barre de recherche, on détermine si on doit enrichir les résultats avec ceux de la BAN (si pas de point d'exclamation, que la recherche est probablement une adresse et qu'on est pas sur une recherche locale dans un autre pays que la France)
• On dé-duplique les résultats BAN (suppression d'un résultat BAN si il match avec un dans Photon)
• Si la recherche porte sur une adresse, les résultats BAN sont affichés en premier
• Composant BANFeatureUI pour afficher les infos relative à l'adresse BAN, grosso modo la même chose que OSMFeatureUI à la différence que le bouton modifier ne renvoie pas vers OSM mais vers mes-signalements et qu'il n'y a pas les avis bluesky.

Quid de la carto : Les adresses présentent dans OSM sont visibles sur le fond de carte, vous savez si c'est possible de faire pareil avec les adresses BAN?

Screenshot avec une adresses issue des résultats BAN :

@MaGOs92 wrote in #2001 (comment):

• On dé-duplique les résultats BAN (suppression d'un résultat BAN si il match avec un dans Photon)

C'est le principe de la BANO. Du coup, on peut s'appuyer sur la BANO pour s'éviter les règles de recherche côté cartes.app.

Si on part sur BAN (et non BANO), le choix d'OpenAdresses me semble plus pertinent puisque la couverture est mondiale. Et appliquer ta solution de déduplication

Quid de la carto : Les adresses présentent dans OSM sont visibles sur le fond de carte, vous savez si c'est possible de faire pareil avec les adresses BAN?

Il faudrait supprimer les adresses OSM des tuiles et rajouter une couche BAN. C'est faisable.

Connaissez-vous le moteur de recherche d'adresse Addok? Il est prévu pour la BANO https://demo.addok.xyz
C'est Cquest qui l'a développé (gage de confiance donc ;)) et c'est très efficace. Voilà ce sur quoi c'est basé: https://cq94.medium.com/sous-le-capot-du-g%C3%A9ocodeur-addok-398ce9b2b1fa
Il y a des plugins pour gérer les abbréviations (ex Av pour Avenue), des scores géographiques/importance, etc.
Reste à déterminer comment fusionner les résultats avec Photon.

@MaGOs92 wrote in #2001 (comment):

J'ai commencé un POC (PR : #2365) pour intégrer les adresses BAN dans la recherche.

Super ! merci !!
Je n'ai pas eu le temps de regarder ton code (et je crains d'ailleurs de ne pas être pertinent), mais en attendant la revue par @laem j'ai déployé sur https://dev3.cartes.app pour que tout le monde puisse tester (j'ai déployé une copie de ta branche sur le remote, pas le fork directement car j'ai pas réussi)
(削除) [edit] plus possible de tester j'ai récupéré l'instance dev3 pour un autre test (削除ここまで)
[re-edit] finalement si, le test est toujours possible, je me suis arrangé pour cumuler ce test de la BAN et le style vélo dans une même branche.

@etienneJr wrote in #2001 (comment):

en attendant la revue par @laem j'ai déployé sur https://dev3.cartes.app

ça semble marcher parfaitement ! exemple : https://dev3.cartes.app/?allez=19+Rue+des+Fauvettes%2C+53230+M%C3%A9ral%7C%7C-0.98368%7C47.95636#15/47.95636/-0.98368/15/40

Test effectué

• recherche d'adresse présente que dans BAN ✔️
• recherche d'adresse présente dans BAN et OSM mais différemment positionnée : priorité à OSM ✔️(削除) priorité à la BAN (je suis pas fan) (削除ここまで)
  • (削除) orthographe de la voirie pas toujours propre (absence d'accents, de cédille, minuscules au nom propre) (削除ここまで)
  • (削除) positionnement possiblement de moindre qualité (削除ここまで)
• recherche d'adresse présente que dans OSM ✔️

Super boulot, à voir si on priorise OSM sur la BAN lorsque les adresses sont dans les 2.

@MaGOs92 ça serait possible d'utiliser la BAN aussi pour le reserse geocoding lors du clic gauche sur la carte ? (clic long sur mobile)

d'ailleurs, j'ai l'impression que même photon trouve rarement quelque chose, ça m'étonne, faudrait investiguer.

@etienneJr wrote in #2001 (comment):

ça serait possible d'utiliser la BAN aussi pour le reserse geocoding

je pense oui, via l'api de géocodage https://adresse.data.gouv.fr/outils/api-doc/adresse, mais il y a des limites d'usage sur les appels

@LySioS wrote in #2001 (comment):

recherche d'adresse présente dans BAN et OSM mais différemment positionnée : priorité à OSM ✔️(削除) priorité à la BAN (je suis pas fan) (削除ここまで)

* ~orthographe de la voirie pas toujours propre (absence d'accents, de cédille, minuscules au nom propre)~
* ~positionnement possiblement de moindre qualité~

En fait, je m'étais trompé, la priorité est donné au point OSM. Sur l'adresse que j'avais essayé, le manque de la cédille dans la BAN faisait que c'était 2 point adresses différents entre OSM et BAN, la recherche proposait 2 solutions différentes

Y'aurait peut-être quelque chose à creuser de ce côté là pour qu'une seule réponse soit affichée, ça risque d'être un peu confus sinon.
Soit il faut coder des règles vis-à-vis des signes diacritiques, soit regarder du côté de BANO si ces règles sont déjà intégrées.

Reste la question de l'international et de OpenAdresses

@LySioS wrote in #2001 (comment):

Reste la question de l'international et de OpenAdresses

je propose de déployer cette intégration de la BAN le moment venu, elle apporte déjà beaucoup à 99% de nos utilisateurs.

et de repousser OpenAdresses à un ticket suivant, surtout que ça demande un énorme boulot côté serveur.

@LySioS wrote in #2001 (comment):

soit regarder du côté de BANO si ces règles sont déjà intégrées.

Pifomètre ne fait pas se genre de rapprochement, il me semble...

Je fais une revue de la PR.

Il y a un petit binz : on dirait que la recherche se lance pas toujours, sur l'exemple cité plus haut.

image

Je regarde.

Et si je ne m'abuse BAN renvoi les coordonnées GPS donc on pourrait ordonner en fonction de la distance quand "rechercher ici" est coché

En fait, l'API BAN semble avoir un problème : elle ne propose pas le résultat Méral alors même qu'on lui donne les cordonnées GPS. Il faut ajouter "méral" à la fin de la recherche pour que l'adresse soit enfin proposée devant Toulouse.

Certes, ça ajoute quand même des adresses pas couvertes aujourd'hui par OSM+Photon, mais j'ai peur qu'en pratique 80 % des saisies d'adresse de nos utilisateurs se fassent sans ajouter la ville, simplement zoomée sur la ville manuellement ou via l'historique de position.

https://data.geopf.fr/geocodage/search?index=address&q=19+rue+des+fauvettes&limit=5&lat=47.9603&lon=-0.9832

Je retrouve ce problème sur le moteur addok qui fait tourner ce site https://adresse.data.gouv.fr/carte-base-adresse-nationale#47.956277_-0.983928_16.33

19 rue des fauvettes introuvable sans ajouter la commune :/

@pmiossec le problème ne semble pas être une question d'ordre, mais plus profond : il ne trouve tout simplement pas l'adresse malgré les coordonnées lat lon.

https://data.geopf.fr/geocodage/search/?q=19+rue+des+fauvettes&limit=50&autocomplete=1&lat=47.9579&lon=-0.9876

@laem wrote in #2001 (comment):

Je retrouve ce problème sur le moteur addok qui fait tourner ce site https://adresse.data.gouv.fr/carte-base-adresse-nationale#47.956277_-0.983928_16.33

19 rue des fauvettes introuvable sans ajouter la commune :/

Je pense que c'est la même API, il n'y a plus d'instance addok qui tourne côté DINUM à ce que je sache.

Sur data.geopf.fr, le lat/lon est bien pris en compte, car on n'a pas le même ordre dans les résultats avec et sans.

Ce lat/lon c'est un "boost" géographique, qui n'est pas utilisé pour la recherche en elle même, mais pour le scoring il n'est peut être pas suffisant pour compenser une "importance" très faible de cette adresse (0.22), Bordeaux et Toulouse sont à 0.59.
Il y a aussi beaucoup de "rue des fauvettes" et même en passant la limite à 50, la dernière par importance est à 0.36 donc encore loin devant celle de Méral.

Donc, ici, il n'y a qu'un mot signifiant "Fauvettes', très commun, donc beaucoup de candidats et le lat/lon n'est pas utilisé dans la première phase de recherche dans l'index d'une centaine de candidats.

Ce qui serait faisable en recherche vraiment de proximité serait si on ne trouve pas de résultat proche, de faire une seconde requête avec un filtre sur le CITYCODE de la commune...

https://data.geopf.fr/geocodage/search?index=address&q=19+rue+des+fauvettes&citycode=53151

Si tu n'a pas ce CITYCODE tu peux le trouver avec avec un geocodage inverse...

https://data.geopf.fr/geocodage/reverse?index=address&lat=47.9603&lon=-0.9832&limit=1

Merci pour les détails ! Oui j'ai pensé à filter par commune via les données sur les tuiles, mais on n'a que le nom de la ville, pas le code postal. Aller chercher le code postal, ça pourrait marcher... mais c'est pas simple, car dans de nombreuses situations le lieu recherché sera dans une autre commune que celle qui est au centre lat,lon de la carte :S

@MaGOs92 est-ce que tu aurais d'autres idées pour résoudre ce problème ?

Ça n'empêche pas le merge de ta PR, mais j'aimerais bien être sûr qu'on n'a pas de petit patch intelligent à faire avant quand même.

Salut @laem, en reprenant l'idée du citycode de @cquest, je suis arrivé à quelque chose qui semble fonctionner pour le cas du 19 rue des fauvettes à Méral.

Voici l'idée : J'ai ajouté la source découpage administratif dans la carte de cartes.app avec un hook qui ajoute une fonction accessible globalement permettant de récupérer les communes dans un rayon de 20km.
Ensuite dans la recherche, si il s'agit d'une recherche locale, je récupère les communes environnantes depuis la variable globale et je les envoie à l'API Adresse pour le filtrage (l'API Adresse accepte jusqu'à 200 communes dans son param citycode)

Voici des screen pour le cas du 19 rue des Fauvettes à Méral :

Ah trop cool ! Astucieux, je vais regarder ça.

Après y'a les cas où les features ne sont pas accessibles sur la carte car zoom trop faible (mais dans ce cas la recherche locale n'a pas vraiment de sens) ou trop élevé (cas d'un utilisateur qui arrive sur le site en zoom max )

OK je bascule sur la PR pour discuter de ce patch en particulier.

Eh ben, il est pas mal financé ce OpenAddresses ! image
https://opencollective.com/openaddresses

https://jonready.com/blog/posts/geocoder-for-ai-agents.html

Très intéressant.

@laem wrote in #2001 (comment):

Eh ben, il est pas mal financé ce OpenAddresses ! image https://opencollective.com/openaddresses

Tant mieux ! 148 000$ reçus depuis 2020

C'est en ligne :) Bravo pour tout le boulot. Un petit fil Atproto bientôt pour expliquer ça.

https://mu.social/profile/cartes.app/post/3mpqgtaq3xk2l

@laem wrote in #2001 (comment):

C'est en ligne :) Bravo pour tout le boulot. Un petit fil Atproto bientôt pour expliquer ça.

Oh, mais trop bien 🚀🎉, merci à tous ! Je ferai moi aussi un petit article sur le blog de la BAN pour fêter ça !!!

@laem si tu veux il y a un petit formulaire à remplir en bas de cette page pour être intégré à la liste des "usagers" BAN https://adresse.data.gouv.fr/communaute/usages