Géocodage avec Addok

OpenStreetMap est une bonne alternative pour le fond de carte et de nombreux services existent aussi pour les calcul d’itinéraire (osrm, mais aussi graphoper). Là où ça pêche le plus c’est sur le géocodage.

Nominatim, le service maintenu par la fondation OSM n’est malheureusement pas au niveau de service actuellement attendu. Il ne tolère aucune erreur de saisie, n’est pas assez rapide pour gérer de l’autocomplétion. Par contre, il indexe très bien les données OSM en les hiérarchisant et en ne se limitant pas uniquement aux adresses.

Je suis donc en train d’avancer sur le géocodage… en allant plus loin qu’un référentiel contenant uniquement les adresses.

J’avais déjà testé addok (le géocodeur de adresse.data.gouv.fr) avec des POI issus d’OSM, des entreprises issues de SIRENE, donc là j’essaye de mixer le tout pour avoir un service assez universel qui puisse se substituer aux services « place » de GMaps.


Complément: voici la liste des endpoints addok que je fais tourner à titre de démo/test:

4 « J'aime »

super intéressant @cquest, tiens nous au courant de l’avancée du projet (y a un repo github ?) et éventuellement de la manière dont on peut aider (code mais aussi pourquoi pas financièrement ou autre ?) !

L’idée c’est de s’appuyer sur le moteur de géocodage addok car il est vraiment très performant et je connais bien son fonctionnement (y compris interne). J’utilise d’ailleurs une version en cours de dev d’addok (future 1.1).

C’est surtout la partie extraction et préparation des données qui est à améliorer.

J’ai remis sur l’ouvrage mon « osmpoi4addok » démarré il y a presque trois ans (juin 2015) !

Le code est sur https://github.com/osm-fr/osmpoi4addok et Frédéric Rogrigo l’avait largement optimisé.

Ces derniers jours, je l’ai complété avec:

  • la prise en compte des noms alternatifs (alt_name, old_name, official_name, local_name, short_name, name:fr)
  • un calcul d’importance qui prend en compte l’emprise géographique de l’objet (utile pour le tri lors de l’autocomplétion)

Les données France sont extraites et dispo désormais sur https://www.data.gouv.fr/fr/datasets/points-dinterets-openstreetmap/

Deux fichiers sont produits, un CSV brut et un json prêt à importer pour addok et j’automatiserai leur extraction dès que ce sera stabilisé.

A ce fichier de POI, j’ajoute pour l’instant les adresses de BANO.

La suite ?

  • compléter les adresses,
  • compléter les POI, par exemple avec un extrait de SIRENE (j’ai déjà fait un POC avec ça aussi), mais aussi d’autres sources comme les données de transport, les bornes kilométriques pour les PK, etc…

Une démo (très quick and dirty) est visible sur http://demo.addok.xyz/ et l’API de géocodage est elle aussi sur http://demo.addok.xyz/ par exemple http://demo.addok.xyz/search?q=musee+du+louvre

3 « J'aime »

Bonjour,
Ca nous intéresse parce que jusqu’à maintenant, seul le moteur Pelias correspondait à nos besoins en matière de géocodage d’adresses+POI.
Or il me semble que votre solution est plus simple à installer et à customiser. Mais aussi plus jeune (mais aussi moins abandonnée). Il faudra qu’on fasse un POC dessus avec nos données. Le projet est-il en phase “très active” de développement, avec retroplanning et tout ?

Concernant l’article, ces augmentations confirment notre direction prise d’avoir notre propre serveur de tuiles (mapnik) pour nos applications “grand public”.
Pour le calcul d’itinéraires, notamment sur les transports en commun, OpenTripPlanner fonctionne très bien aussi.

Pelias est basé sur Elasticsearch et nous avons abandonné cette piste à cause d’un fonctionnement trop opaque de ce dernier. Les résultats “magiques” c’est peu traçable et quand ils ne correspondent pas à ce qu’on attend on a bien du mal à comprendre pourquoi.

addok a été écrit (à partir de fin 2014, donc pas si jeune) pour cette raison après avoir utilisé ES sur plusieurs projets, mais avec un résultat final qui ne s’approchait qu’à 80% de l’objectif.

Il est en production sur l’API de géocodage d’Etalab (adresse.data.gouv.fr) depuis 2015 et nous donne entière satisfaction en terme de stabilité, performance, fonctionnalités et qualité des résultats.

addok c’est pas actuellement en développement “très actif”. J’ai fait quelques commit il y a peu pour améliorer les perf encore un peu plus :wink:

Ses avantages:

  • très stable (utilisé sur adresse.data.gouv.fr la SLA est de 100% depuis janvier, pour environ 1 milliard de requêtes traitées)
  • très rapide: 30ms en moyenne pour traiter une requête
  • pas trop gourmand en ressources: 6Go de RAM suffisent pour la BAN, l’instance BANO+POI OSM a besoin de 9Go.
  • code clair… python, très propre, coverage de 95%

En fait, il fonctionne tellement bien, qu’on n’a pas trop eu besoin de bosser dessus depuis près de 2 ans :wink:

Inconvénients:

  • communauté d’utilisateurs assez réduite: je l’évalue à une douzaine d’instances
  • communauté de développement encore plus réduite: actuellement Yohan Boniface (auteur initial et principal), et je m’y suis mis récemment… mais on est hyper ouverts pour des renforts et expliquer la mécanique sous le capot

A ce sujet… j’ai une présentation au FOSS4G-FR dans 10 jours pour expliquer ce qu’il y a sous le capot d’addok.

2 « J'aime »

Pour info, j’ai ajouté les POI de geonames en complément… environ 70000 de plus donc, mais aussi 70000 doublons que je vais éliminer…

Prochaine amélioration prévue… plus d’adresses provenant des plans cadastraux

PS pour un admin… il y a moyen de “splitter” le sujet ?

splitté :wink:

1 « J'aime »

A l’occasion du FOSS4G-FR qui se tenait ces derniers jours à Marne la Vallée, j’ai publié un article à propos d’addok… qui soulève un peu le capot :wink:

2 « J'aime »

@cquest Très intéressant ton article. Y a par contre un souci ici:

Voici au final les principales étapes, ainsi que le temps passé en moyenne pour chacune d’elle :

nettoyage de la requête et tokenisation (6%)
classement des tokens (6%)
recherche et combinaison des tokens principaux (18%)
recherche “fuzzy” (27%)
récupération des données complètes (16%)
calcul de score (14%)

Ca fait 87% :wink:

Soit j’ai oublié une étape, soit c’est “le reste”, pas franchement catégorisable…

Je déterre ce sujet… car je me suis remis sur addok ce week-end.

Au programme sortir une 1.1 rc2 (release candidate 2), afin de sortir une 1.1.

Si vous voulez suivre un peu tout ça c’est sur:

Salut @cquest, peux-tu nous dire où ça en est ?
Ça m’intéresserait de pouvoir updater le package R banR qu’on développe avec @pac en permettant d’interroger OSM via Addok en plus de l’API Adresses, ça te semble envisageable à court ou moyen terme ?

C’est juste pour compléter api-adresse.data.gouv.fr ?

Tu as de dispo:

  • ban.addok.xyz (identique en principe à api-adresse.data.gouv.fr)
  • bano.addok.xyz avec les données BANO
  • poi.addok.xyz avec les POI d’OSM

Ce sont les instance addok que j’utilise pour géocoder SIRENE.

Tout est hébergé depuis mon « datacenter/chaton » perso, avec 2 fibres de 500Mbps en sortie, IPv4 et IPv6 :wink:

oui ce serait pour proposer une offre de sources plus large. À titre perso, ça m’intéresse aussi de comparer les performances entre BAN et BANO (par exemple pour géocoder les listes électorales).

Chaque base a ses avantages et inconvénients, c’est pour cela que j’utlise les 2 et que je complète même avec les POI d’OSM pour les entreprises qui peuvent avoir des adresses comme « CENTRE COMMERCIAL AUCHAN », sans plus de précision !

Pour ça aussi que ça prends plusieurs heures et que j’ai du code python qui appelle plusieurs fois les API, voire calcule des interpolations sur les adresses manquantes (genre on cherche le 12 et on a le 10 et 14). :wink:

Tu devrais apifier tes scripts de geoloc et vendre ça :wink:

1 « J'aime »

Pour info, je viens de refaire une extraction des POI OSM pour le géocodeur addok.

Cela fait plus de 3 million de POI (France et DOM/COM).

Le fichier de POI au format json destiné à addok est dispo sur: http://osm13.openstreetmap.fr/~cquest/osm_poi/

L’API de géocodage « démo » est en cours de rechargement… et toujours testable avec une petite interface sur

https://demo.addok.xyz/

Je déterre ce sujet pour la bonne cause :wink:

Le géocodeur addok, développé à l’origine et toujours utilisé par Etalab pour adresse.data.gouv.fr est en train d’évoluer depuis que je me suis (re)plongé dans son code.

Une version 1.1, en préparation depuis longtemps, pointe petit à petit le bout de son nez.

Je le teste pour des usages plus larges que les seules adresses, pour étendre son fonctionnement à la recherche de « localisants ».
Les localisants peuvent bien sûr être des adresses, mais aussi des points d’intérêts (POI), des intersections, des lieux-dits, etc.

J’ai une instance déployée chez moi, utilisant la dernière version en développement et qui permet de tester ce type d’usage avec une interface minimale.

https://demo.addok.xyz/ où vous pouvez tester l’auto-complétion avec préférence géographique centrée sur la carte.

Elle contient pour l’instant :

  • 22 627 589 d’adresses (au numéro)
  • 2 421 738 rues
  • 2 594 359 lieux-dits
  • 3 138 661 POI
  • 2 677 334 intersections de rues et/ou routes

Total : 33.46 million de localisants ayant comme source BANO pour les trois premiers items, et OSM les deux derniers.

En plus des adresses, on peut donc faire des recherches du type :

  • musée du louvre
  • A5 D40
  • A86 creteil
  • avenue montaigne champs élysées
    etc.

L’API n’offre aucune garantie de stabilité, c’est de la démo/dev, ne branchez donc aucune appli dessus.
Vos retours sont les bienvenus en particulier sur la pertinence des résultats et sur les performances (mes deux priorités).

Les perfs peuvent varier, la machine sur laquelle tourne cette instance fait bien d’autres choses en même temps et a quand même 10 ans de bons et loyaux services !
Le temps typique de recherche est de l’ordre de 20ms (tout est en RAM, ça aide).

Le projet est sur github et vous pouvez si besoin y créer des issues pour permettre leur suivi : https://github.com/addok/addok/issues

Et si vous voulez un aperçu du fonctionnement interne d’addok, voici un article que j’avais écrit il y a déjà quelque temps, mais toujours valable:

3 « J'aime »