bePelias, un géocodeur local basé sur BeSt Address

Nederlandstalige versie

Le géocodage est l’opération qui permet de transformer une adresse postale textuelle (“av. Fonsny 20, 1060 Bruxelles”) en une version décomposée et standardisée, associée à une localisation géographique1 :

{"street":  "Avenue Fonsny", 
 "number":  20, 
 "zipcode": 1060,  
 "city":    "Saint-Gilles",
 "lat":     50.8358216, 
 "lon":     4.3386884}

Dans un article précédent, nous avons montré qu’il existe une série d’outils pour réaliser cette opération et que, dans certaines circonstances, il est nécessaire de disposer d’un outil sur site (on-premise), ou local. Nous avons déjà mis en avant NominatimWrapper, une solution que nous avons développée, basée sur OpenStreetMap.

En Belgique, le service public fédéral “Stratégie et Appui” (BOSA) gère BeSt Address, la source authentique des adresses belges. Elles sont disponibles en open data dans différents formats. Dans cet article, nous allons nous pencher sur la question suivante : est-il possible de mettre en place un géocodeur local basé sur ces données ? La réponse nécessite une certaine nuance : Oui, mais…

Précisons d’abord que BOSA met à disposition une série de web services, mais avec deux limitations :

  • Ceux-ci sont uniquement disponibles pour les services publics, pas pour les entreprises ou les citoyens ;
  • Ils n’offrent pas l’aspect “standardisation” : il est nécessaire de connaitre l’orthographe (quasi) exacte d’une rue ou d’une (sous-)commune pour l’utiliser.

Pelias

Le projet open source Pelias permet de mettre en place un géocodeur basé sur ses propres données. En combinaison avec OpenAddresses.io, un projet rassemblant des données d’adresses ouvertes, il est possible de déployer Pelias pour une série de pays ou de villes, dont la Belgique avec BeSt Address (en combinaison avec OpenStreetMap).

S’il est facile de mettre en place un géocodeur combinant Pelias et BeSt Address qui semble bien marcher quand on le teste sur quelques adresses, on déchante vite quand on tente de passer à la vitesse supérieure, en lui envoyant des ensembles de données venant de la Banque Carrefour des Entreprises (belge), du répertoire des employeurs (ONSS) ou encore du registre national.

Pelias permet deux modes d’interrogation : structuré ({“address”: “Avenue Fonsnsy 20”, “postalcode”: 1060, “locality”: “Saint-Gilles”}) ou non structuré ({“query”: “Avenue Fonsnsy 20, 1060 Saint-Gilles”}). Sur les données que nous avons testées (10.000 adresses provenant de diverses sources en légende ci-dessous) en mode structuré (cf. “pelias_struct” dans le graphique ci-dessous), Pelias n’a été capable de localiser précisément que de l’ordre de 55 % des adresses. Quelques pour cents (1-2) sont localisés au niveau de la rue, et dans +/- 35 % des cas, Pelias n’a trouvé que la ville … autant dire, rien d’exploitable. Et dans 7-10 %, on ne reçoit même aucun résultat.   

Pelias fait un petit peu mieux en mode “non-structuré” (pelias), puisqu’il sera presque toujours capable de fournir un résultat, et 11 % des adresses supplémentaires sont localisées précisément.

Il est intéressant de remarquer quelques éléments :

  • Quand le résultat n’est pas précis, le résultat ne contient pas de données provenant de BeSt Address, mais d’OpenStreetMap (niveau “street”) ou WhosOnFirst (niveau “city”) ;
  • Il arrive qu’une adresse ne donne pas de résultat en mode “structuré”, mais en donne en “non-structuré”, et vice-versa ;
  • En mode structuré, Pelias semble fréquemment perturbé par la présence du paramètre “locality” en addition du “postalcode”. Souvent, une adresse donne un résultat de niveau “city” quand on lui fournit ce paramètre, mais de niveau “building” quand on lui fournit uniquement le code postal (en plus de la rue et du numéro). On peut voir la différence dans le graphique sur la ligne “pelias_struc_noloc”, où la partie localisée précisément (“building”, en vert) augmente de près de 25 %. En contrepartie, la partie localisée au niveau de la ville, grandement basée sur cet argument “locality”, disparaît quasiment ;
  • Le résultat fourni par Pelias ne contient pas de “BeSt id”, qui permettrait d’obtenir l’identifiant unique et authentique d’une adresse ;
  • Ni les adresses en français des communes flamandes à facilités (et vice-versa) ni les adresses germanophones des cantons de l’Est ne sont importées.

Mais il y a à l’heure d’écrire ces lignes un problème encore plus important : les données utilisées par Pelias datent de mi-2021, et ce pour deux raisons : 

  • Le format reconnu par OpenAddresses a changé vers octobre 2021 et n’est plus compatible avec les fichiers mis à disposition par Bosa ;
  • OpenAddresses a changé son flux de données mi-2021 : au préalable, les données préparées étaient mises à disposition à l’adresse https://results.openaddresses.io/, qui est toujours disponible mais dont les données ne sont plus mises à jour ; elles le sont maintenant sur https://batch.openaddresses.io/data. Mais Pelias n’a pas été adapté et continue à télécharger les données sur l’ancien système.

bePelias

Il semble donc assez clair que Pelias n’est en l’état, pas un candidat sérieux pour une application nécessitant de géocoder des adresses en Belgique. Tant les données importées (trop anciennes, sans ID, sans données au niveau des rues si un numéro n’est pas identifié) que la robustesse font défaut. Mais il nous semblait que le potentiel était là et avons cherché à l’améliorer. Il y avait deux pistes : 

  • Créer un “clone” de Pelias, en modifiant son code. Avec le risque de faire des changements qui ne soient pas compatibles avec les futures évolutions de Pelias, et un effort de compréhension et de développement important ;
  • Rajouter une “sur-couche”, comme nous l’avons déjà fait avec succès dans NominatimWrapper, pour pallier les défaut de Pelias. C’est cette seconde voie que nous avons choisie.

Cet outil, que nous avons appelé “bePelias” et que nous mettons à disposition en open source (https://github.com/SmalsResearch/bePelias), fait principalement deux choses :

  • Une préparation plus complète des données de BeSt Address, incluant une série de données additionnelles (id des adresses, des rues, codes NIS des communes…), complétant l’aspect multilingue et permettant l’identification au niveau de la rue quand le numéro n’est pas connu. Nous avons par ailleurs configuré Pelias pour permettre l’interpolation (supposant que le “8” d’une rue, s’il n’est pas connu, se situe entre le “6” et le “10”).
  • Une couche intermédiaire entre Pelias et le client, sous forme de REST API, pour tenter une série de variantes d’une adresse. On testera une série de combinaisons des variantes suivantes, jusqu’à ce qu’une donne un résultat satisfaisant :
    • Version structurée ou non-structurée de l’appel à Pelias ;
    • Avec la localité, ou uniquement le code postal ;
    • En nettoyant, avec une série d’expressions régulières, le nom de rue ou de localité. Typiquement, on enlèvera tout texte entre parenthèses, très fréquent dans les noms de rue pour préciser un commentaire ou le nom de la sous-commune ;
    • En nettoyant le numéro de maison, qui contient très souvent également un numéro de boite, ce qui ne change pas la localisation dans la plupart des cas.

Dans la pratique, on constate que la version structurée “de base” (sans nettoyage ou sélection) donne un résultat dans +/- 50 % des adresses (pour les données KBO, cf. figure ci-jointe). Viennent ensuite 20 % après suppression de la localité, toujours en structuré, puis 11 % en non structuré, 8 % après nettoyage en structuré, puis une série d’autres combinaisons pour un petit nombre d’adresses. Quasiment toutes les combinaisons sont utiles à un moment.

Résultats

Le résultat est visible dans les graphiques ci-dessous. La solution bePelias est quasiment aussi efficace que Here WeGo (here dans les graphiques) ou Bing Maps de Microsoft (bing); meilleure que Google Maps (google), qui s’avère assez sensible au bruit dans les adresses, comme du texte entre parenthèse, ainsi que NominatimWrapper, qui localise uniquement les rues d’une grande proportion d’adresses.

Nous avons également testé l’exactitude des résultats de bePelias selon une méthodologie de vote par majorité en envoyant un même ensemble de données à plusieurs géocodeurs. Nous avons présenté les résultats lors d’un récent webinaire, qui nous montrent des performances très proches de Here WeGo ou Bing Maps, et, à nouveau, sensiblement meilleures que Google Maps, qui outre le fait qu’il ne situe fréquemment que la rue, a une fâcheuse à l’hallucination, en proposant des résultats à des milliers de kilomètres de la bonne réponse.

En termes de vitesse, le fait que la solution soit sur site lui donne un avantage non-négligeable, en étant deux fois plus rapide que Google Maps ou 5 fois que Bing Maps. Ceci nécessitera bien sûr d’installer le géocodeur au plus près de l’application qui en a besoin.

Conclusions : outil bePelias

Sur base de ce qui précède, nous proposons une solution fonctionnelle, bePelias, qui permet d’instancier un géocodeur localement. Ceci se fait à l’aide de Docker, est basé uniquement sur du code source ouvert (Pelias) et de données ouvertes (principalement BeSt Address), avec à peine un gros milliers de lignes de code additionnel en Python ou Bash.

Elle n’a bien sûr pas que des avantages :

  • Elle ne marche que pour la Belgique ;
  • Elle ne marche que pour des adresses. Vous n’aurez pas de réponse à “Smals, Saint-Gilles”, ou “Boulangerie, Namur” ;
  • Elle nécessite la mise en place, la gestion et la maintenance (mise à jour du serveur, de bePelias et des données de BeSt Address) d’un serveur avec une quinzaine de GB de disque et au moins 8 GB de mémoire RAM, ce qui, en fonction du projet, peut représenter un coût supérieur à l’utilisation d’une solution cloud commerciale ;
  • Il s’agit encore à ce stade d’un projet de recherche qui doit faire ses preuves dans un environnement industriel.

Mais en contrepartie :

  • Elle offre des performances comparables aux grands acteurs commerciaux du secteur ;
  • Elle est on-premise, ce qui règle des problèmes de confidentialité ou liés aux RGPD ;
  • Elle est basée sur BeSt Address, c’est-à-dire la (récente) source authentique des adresses en Belgique. L’obtention d’un “BeSt id” permettra d’interagir plus facilement avec une série de webservices qui auront intégré cette source.

Des retours d’expérience sont bienvenus et aideront à faire progresser cet outil qui ne demande qu’à être utilisé !


  1. Il s’agit d’un exemple illustratif simplifié, dont la syntaxe ne correspond à aucun outil connu. ↩︎

Ce post est une contribution individuelle de Vandy Berten, spécialisé en data science chez Smals Research. Cet article est écrit en son nom propre et n’impacte en rien le point de vue de Smals.

This entry was posted in [FR], Open Source and tagged , by Vandy Berten. Bookmark the permalink.
avatar

About Vandy Berten

Consultant Recherche chez Smals depuis mai 2013. Vandy était auparavant Professeur Assistant à l'ULB, où il enseignait les langages de programmation. Il a obtenu une thèse de doctorat dans la même institution en 2007. Depuis quelques années, il s'est spécialisé dans les techniques de Data Science, incluant le "(social) network analytics", le "data quality", le "GIS analytics", le "machine learning", en particulier dans le domaine de la détection de la fraude.

Leave a Reply

Your email address will not be published. Required fields are marked *