Nederlandstalige versie

Pour être capable de positionner une adresse sur une carte, pour calculer un itinéraire ou pour identifier l’ensemble des commerces dans un quartier donné, il est nécessaire de passer par une étape fondamentale : le géocodage. Cette opération consiste, à partir d’une adresse postale, comme “Av. Fonsny 20, 1060 Bruxelles”, d’une part à la “standardiser” (partie bordeaux de l’image ci-dessous), d’autre part à lui assigner des coordonnées géographiques (“location” dans l’image).  

La standardisation va permettre une découpe correcte de l’adresse en composants, et une rectification (“Av.” en “Avenue”, “1060 Bruxelles” en “1060 Saint-Gilles”). Elle pourra aussi supprimer des éléments non pertinents pour le géocodage, comme par exemple la partie en italique grisée dans “Av. Fonsny 20 bte 5 (en face de la gare)“. Cette étape revient en fait à faire la correspondance entre une adresse en entrée et le référentiel dans lequel chaque adresse structurée est associée à ses coordonnées géographiques. Cette étape de standardisation fait donc intégralement partie du processus de géocodage et est nécessaire.

L’opération inverse, qui consiste à demander toutes les adresses existantes dans un périmètre donné d’un point, s’appelle le “géocodage inverse” (reverse geocoding).

Le géocodage peut être fait avec OpenStreetMap en appelant l’URL suivante :

https://nominatim.openstreetmap.org/?q=Av.+fonsny+20,+1060+Bruxelles&format=jsonv2

Le “reverse” correspondant peut se faire avec l’adresse suivante : 

https://nominatim.openstreetmap.org/reverse?lat=50.83586776&lon=4.3385087&format=jsonv2

Les outils

Cette opération de géocodage se fait typiquement via une API, mise à disposition par un serveur. De nombreuses solutions existent, le choix va fortement dépendre des réponses aux différentes questions que nous allons mentionner dans la suite de ce texte. Nous nous focaliserons sur le géocodage d’adresses en Belgique, mais à part quelques éléments spécifiques, les questions seront génériques.

Nous avons examiné de façon approfondie une série d’outils, commerciaux ou non : 

• Commerciaux (Cloud) :
  • Google Maps
  • Bing Maps
  • Here
  • TomTom
  • Mapbox
• Non-commerciaux (on premise) :
  • Nominatim (OpenStreetMap), version “dockerisée locale“
  • NominatimWrapper, une solution que nous avons développée pour combler certaines lacunes de Nominatim
  • Pelias, en y chargeant les données de BestAddress (source authentique des adresses en Belgique) et d’OpenStreetMap

Nous avons par ailleurs examiné en “avant-première” l’API de BestAddress, qui n’est pas disponible publiquement. Notons que plusieurs grands acteurs de solutions GIS peuvent aussi offrir des solutions dédiées, (semi-)on-premise ou non. Nous n’avons pas exploré ces pistes, qui nécessitent des démarches commerciales complexes avec ces entreprises.

Cloud vs on-premise

Une première question à se poser est de savoir si l’on peut utiliser une API commerciale qu’il “suffit” d’appeler, ou s’il est nécessaire d’avoir un géocodeur “on-premise”, géré et installé au sein de l’infrastructure de l’entreprise ou de l’administration.

L’avantage d’une solution Cloud (Google Maps, Here, Bing…) commerciale est sa facilité de gestion et l’absence de coût d’infrastructure. Ces solutions sont en général également de bonne qualité et offrent une couverture mondiale. Il faudra cependant tenir compte d’un coût par appel, qui peut devenir problématique pour des volumes importants. Souvent, un quota d’appels gratuits est cependant proposé (40.000/mois pour Google Maps, 30.000/mois pour Here, ….)

Les solutions on-premise permettent de répondre à des besoins de confidentialité ou de respect du GDPR plus élevé. Elles seront en général aussi plus rapides si le volume de données est important. Il faudra cependant tenir compte de coûts d’infrastructure et de gestion plus important, et une couverture mondiale sera difficile à envisager, à moins de disposer de plusieurs téraoctets de données à consacrer au produit.

	Cloud solutions	On-premise solutions
Complexité à mettre en place	🙂	🙁
Coût infra	🙂	🙁
GDPR, Confidentialité	🙁	🙂
Coût pour gros volumes (temps, €)	🙁	🙂
Accès internet	🙁	🙂
Qualité	🙂	😐
Couverture mondiale	🙂	🙁

Niveau de précision

L’exigence de la précision, à savoir la nécessité que l’adresse soit localisée exactement au bon endroit, ne sera pas la même s’il s’agit de faire des statistiques globales, de savoir dans quel quartier se trouve une adresse, quel livreur ou contrôleur devrait l’intégrer dans sa tournée, que s’il s’agit d’envoyer une équipe de secours. Dans les premières situations, on acceptera que par exemple qu’une certaine proportion d’adresses soit localisée au niveau de la rue et pas du bâtiment précis.

Structuration des adresses

La plupart des géocodeurs acceptent de recevoir en entrée soit une adresse structurée (rue=’Av. Fonsny’, numéro=’20’…) soit une adresse non structurée  (adresse=’Av. Fonsny 20, 1060 St-Gilles’). Mais certains exigent que l’adresse soit structurée, ce qui peut poser un problème si on n’en dispose pas sous cette forme, ou qu’elles sont souvent mal découpées (rue=’Av. Fonsny 20′, numéro=”).

Source authentique

Une même adresse peut connaitre des orthographes différentes en fonction de la source. Par exemple, à Bruxelles, deux rues sont nommées suivant la commune de “Tervuren” (une chaussée sur Auderghem, une avenue sur Etterbeek, Auderghem et Woluwé-Saint-Pierre) :

• Selon Bing, il y a la chaussée de Tervuren et l’avenue de Tervueren ;
• Selon Google maps ou OpenStreetMap, il s’agit de la chaussée de Tervueren et l’avenue de Tervueren ;
• Selon BestAddress, on a l’avenue de Tervueren à Etterbeek et Woluwé-Saint-Pierre, mais la chaussée et l’avenue de Tervuren à Auderghem ;
• Selon le registre national, il s’agit tout le temps de Tervueren.

En fonction du contexte, il peut être important d’obtenir toujours la formulation correspondant à une source en particulier. Par exemple parce qu’on a nécessairement besoin d’avoir une version connue par une source authentique. Ou, pour les coordonnées géographiques, parce qu’on va ensuite l’afficher sur un fond de carte, et qu’on désire donc être le plus en accord possible. En effet, placer sur une carte de Google Maps une adresse qui a été géocodée avec OpenStreetMap risque dans certains cas de provoquer un léger décalage.

S’il est nécessaire d’obtenir des données selon BestAddress (en Belgique), il y a à l’heure actuelle principalement trois possibilités : 

• L’API  “officielle” offerte par Bosa (pour l’instant uniquement en phase de test)
• En installation locale, Pelias en chargeant le dataset de BestAddress
• Phacochr (cf plus bas), uniquement en mode batch, sans API.

Notons aussi qu’il existe une API fournie par “geopunt.be”, spécifiquement pour les adresses belges en Flandre et à Bruxelles (en néerlandais). 

Couverture

Un des avantages des solutions Cloud est qu’elle permettent à la fois de géocoder une adresse à Bruxelles, à New-York et à Taipei. Faire la même chose avec une solution locale peut exiger un espace prohibitif. Pour la (toute petite) Belgique, OpenStreetMap (Nominatim) nécessite 30 GB d’espace disque. Le monde entier nécessiterait plusieurs téraoctets, et une mise en place de plusieurs semaines.

Une installation limitée à un pays peut cependant convenir pour une administration qui ne devrait que gérer des adresses dans son pays. Il existe aussi des possibilités hybrides : il est possible de configurer Nominatim pour offrir un géocodage complet pour une sélection de pays, et se limiter à la localisation et nettoyage au niveau des villes pour le reste du monde.

Besoin d’une API

Nous nous sommes focalisés sur les API, c’est-à-dire les interfaces “techniques” offrant la fonctionnalité de géocodage d’adresses une par une. Ceci permet d’intégrer cette fonctionnalité dans une application ou dans un processus automatisé de gestion de données. Mais dans certains cas, on possède un fichier d’adresses, que l’on souhaite manuellement géocoder avant une analyse spécifique. Des outils permettent cette tâche, par exemple GeoApify, ou, pour des adresses belges avec en résultat les données de BestAddress, Phacochr (dans un script R, ou avec la version web)

Performances

Avoir une solution rencontrant les critères évoqués ci-dessus n’est pas suffisant. Encore faut-il que les performances soient au rendez-vous. L’aspect “vitesse” doit certainement être pris en considération, mais l’on s’intéresse ici surtout à la “robustesse”, à savoir la capacité à proposer un résultat (précis) pour le plus grand nombre d’adresses. Pour une série d’échantillons d’adresses belges provenant de diverses sources (officielles ou non), nous avons effectué quelques tests. Dans les graphiques ci-dessous, la partie en bleu représente la proportion d’adresse que l’API a été capable de localiser précisément (au niveau du bâtiment). En orange, lorsque la rue a été trouvée, mais pas le numéro précis. En vert, seule la ville a pu être localisée.

Les échantillons de 1000 adresses chacun proviennent des sources suivantes (toutes belges) : 

• kbo : la Banque Carrefour des Entreprises
• rep : le Répertoire des Employeurs
• rrn : le Registre National
• best : BestAddress (Bosa)
• resto : le site web resto.be

Quelques observations peuvent être faites : 

• Here s’en sort mieux que Google Maps et ses concurrents, en localisant plus d’adresses précisément ;
• Nominatim n’est pas très robuste : en fonction du jeu de données, mises à part sur les données de BestAddress (best_1000, nettement plus propres et standardisées que les autres jeux de données), entre 10 et 15 % des adresses n’ont tout simplement pas été trouvées. Et pour une proportion importante des adresses, seule la rue est connue ;
• Notre solution basée sur Nominatim (NominatimWrapper) améliore très nettement la robustesse. Mais on reste avec une proportion importante d’adresses localisées uniquement au niveau de la rue ;
• Pelias se limite, à ce stade, à une grande proportion d’adresses localisées au niveau de la ville. Mais l’incorporation des données de BestAddress est assez récente, on peut donc espérer des améliorations prochaines ;
• La robustesse de l’API de BOSA (bestaddress) est proche de celle de Nominatim, mais c’est à l’heure actuelle un choix assumé : le but n’est pas vraiment d’obtenir une API de géocodage, mais de permettre de localiser une adresse déjà connue, c’est-à-dire dont les identifiants de commune et rue sont connus, ou à tout le moins correctement orthographiées. Les différents services offerts par l’API permettent d’obtenir une liste de rues pour chaque commune, ce qui permet de proposer une interface avec des listes ou de l’auto-complétion, garantissant que les données en entrée soient “propres”. Ce n’est donc pas complètement une API de géocodage, puisque seule la partie “localisation” est offerte, et pas la partie “nettoyage de données”.

Notons que ce n’est pas parce qu’un résultat est précis qu’il est correct. Nous avons déjà abordé cette problématique dans un article précédent. Un notebook Python est également disponible proposant une méthodologie de comparaison.

NominatimWrapper est depuis juin 2023 dans le Re-Use Catalog de la sécurité sociale en Belgique : https://www.ict-reuse.be/fr/service/geocodage-avec-nominatim-ameliore.

Pour conclure

De multiples solutions sont disponibles pour faire du géocodage. Il faut parfois aller plus loin que de sauter sur la première à laquelle on pense : chaque outil aura ses avantages et inconvénients. Les contraintes techniques et légales nécessitent de se poser une série de questions. Il sera également crucial de tester l’outil sur des données types que l’on devra gérer, car le niveau de qualité et la structure des données en entrée peut avoir un impact majeur sur la qualité du résultat. 

---

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.