Géocodage avec Addok


(Christian Quest) #1

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.


Don't be evil... until
(Joël Gombin) #2

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 ?) !


(Christian Quest) #3

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


(François Broussais) #4

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.


(Christian Quest) #5

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.


(Christian Quest) #6

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 ?


(Joël Gombin) #7

splitté :wink:


(Christian Quest) #8

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:


(Donat ROBAUX) #9

@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:


(Christian Quest) #10

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