Geocodering is de bewerking waarbij een tekstueel postadres (‘Fonsnyln 20, 1060 Brussel’) omgevormd wordt tot een in componenten opgesplitste en gestandaardiseerde versie, gelinkt aan een geografische locatie1¹ :

{"street":  "Fonslylaan", 
 "number":  20, 
 "zipcode": 1060,  
 "city":    "Sint-Gillis",
 "lat":     50.8358216, 
 "lon":     4.3386884}

In een vorig artikel hebben we aangetoond dat er een aantal tools bestaan om deze bewerking uit te voeren en dat het, onder bepaalde omstandigheden, nodig is om over een on-site (on-premise) of lokale tool te beschikken. We zetten eerder al NominatimWrapper in de kijker, een oplossing die we ontwikkeld hebben op basis van OpenStreetMap.

In België beheert de federale overheidsdienst “Strategie en Ondersteuning” (BOSA) BeSt Address, de authentieke bron voor Belgische adressen. Ze zijn beschikbaar als open data in verschillende formaten. In dit artikel stellen gaan we dieper in op de volgende vraag: is het mogelijk om een lokale geocoder op te stellen gebaseerd op deze gegevens? Het antwoord vergt zekere nuance: Ja, maar…

Ten eerste stelt BOSA een aantal webservices ter beschikking maar met twee beperkingen:

• Deze zijn enkel beschikbaar voor overheidsdiensten, niet voor bedrijven of burgers.
• Ze bieden geen ‘standaardisatie’: je moet de juiste schrijfwijze van een straat of (deel)gemeente kennen om het te gebruiken.

Pelias

Met het opensourceproject Pelias kan een geocoder opgezet worden op basis van je eigen gegevens. In combinatie met OpenAddresses.io, een project dat open adresgegevens samenbrengt, is het mogelijk om Pelias in te zetten voor een reeks landen of steden, waaronder België met BeSt Address (in combinatie met OpenStreetMap).

Hoewel het eenvoudig is om een geocoder op te zetten die Pelias en BeSt Address combineert en die goed lijkt te werken wanneer je hem test op een paar adressen, raak je al snel teleurgesteld wanneer je probeert naar een hogere versnelling te schakelen en hem datasets stuurt van de (Belgische) Kruispuntbank van Ondernemingen, het werkgeversrepertorium (RSZ) of het rijksregister.

Met Pelias zijn er twee vraagmodi: gestructureerd ({“address”: “Fonsnylaan 20”, “postalcode”: 1060, “locality”: “Sint-Gillis”}) of ongestructureerd ({“query”: “Fonsnylaan 20, 1060 Sint-Gillis”}). Van de gegevens die we gestructureerd (cfr. “pelias_struct” in de grafiek hieronder) getest hebben (10 000 adressen afkomstig van verschillende bronnen in onderstaande legende), was Pelias slechts in staat om 55 % van de adressen exact te lokaliseren. Enkele percentages (1-2) zijn gelokaliseerd wat betreft de straat en in +/- 35% van de gevallen vond Pelias enkel de stad… met andere woorden niks bruikbaars. En in 7-10 % krijgen we zelfs geen enkel resultaat.   

Pelias doet iets beter ‘ongestructureerd’ (pelias), aangezien hij bijna altijd in staat is om een resultaat te verschaffen, en 11 % bijkomende adressen worden exact gelokaliseerd.

Het is interessant om een paar zaken op te merken:

• Wanneer het resultaat niet exact is, bevat het resultaat geen gegevens van BeSt Address, maar van OpenStreetMap (niveau ‘street’) of WhosOnFirst (niveau ‘city’);
• Soms geeft een adres geen resultaat in ‘gestructureerde’ modus, maar wel in ‘ongestructureerde’ modus, en omgekeerd;
• In gestructureerde modus lijkt Pelias vaak in de war te raken door de aanwezigheid van de parameter ‘locality’ naast de ‘postalcode’. Vaak geeft een adres een resultaat op niveau ‘city’ wanneer deze parameter wordt opgegeven, maar een resultaat op niveau ‘building’ wanneer alleen de postcode wordt opgegeven (naast de straat en het nummer). Je kunt het verschil zien in de grafiek op de regel “pelias_struc_noloc”, waar het precies gelokaliseerde deel (‘building’, in groen) met bijna 25% toeneemt. Aan de andere kant verdwijnt het deel gelokaliseerd op stadsniveau, dat grotendeels gebaseerd is op dit ‘locality’-argument, zo goed als;
• Het door Pelias geleverde resultaat bevat geen ‘BeSt id’ die het mogelijk zou maken om de unieke en authentieke identificatie van een adres te verkrijgen;
• Noch de Franstalige adressen van de Vlaamse faciliteitengemeenten (en vice-versa), noch de Duitstalige adressen van de Oostkantons worden geïmporteerd.

Maar op het moment van schrijven is er een nog groter probleem: de gegevens die Pelias gebruikt, dateren van midden 2021, om twee redenen: 

• Het door OpenAddresses erkende formaat veranderde rond oktober 2021 en is niet langer compatibel met de door Bosa beschikbaar gestelde bestanden;
• OpenAddresses veranderde zijn ‘dataflow’ midden 2021: de voorbereide gegevens werden eerst ter beschikking gesteld op het adres https://results.openaddresses.io/ dat nog steeds beschikbaar is maar waarvan de gegevens niet meer up-to-date zijn; ze zijn wel up-to-date op https://batch.openaddresses.io/data. Pelias werd echter niet aangepast en blijft de gegevens van het oude systeem downloaden.

bePelias

Het lijkt dus duidelijk dat Pelias in zijn huidige vorm geen serieuze kandidaat is voor een toepassing die geocodering van adressen in België vereist. Zowel de geïmporteerde gegevens (te oud, geen ID, geen gegevens op straatniveau als een nummer niet geïdentificeerd is) als de robuustheid ontbreken. Maar het leek ons dat het potentieel aanwezig was en we gingen aan de slag om het te verbeteren. Er waren twee mogelijkheden: 

• Een ‘kloon’ van Pelias maken door de code aan te passen. Met het risico om wijzigingen aan te brengen die niet compatibel zouden zijn met de toekomstige ontwikkelingen van Pelias, en een grote inspanning op het vlak van begrip en ontwikkeling;
• Een ‘extra laag’ toevoegen, zoals we al met succes hebben gedaan met NominatimWrapper, om de tekortkomingen van Pelias te compenseren. Het is deze tweede optie die we hebben gekozen.

Deze tool die we ‘bePelias’ hebben genoemd en die we open source ter beschikking stellen (https://github.com/SmalsResearch/bePelias) doet hoofdzakelijk twee dingen:

• Een meer volledige voorbereiding van de ‘BeSt Address-’gegevens, inclusief een reeks aanvullende gegevens (adres- en straatidentificatienummers, NIS-codes voor gemeenten, enz.), die het meertalige aspect vervolledigen en identificatie op straatniveau mogelijk maken wanneer het nummer niet bekend is. We hebben Pelias ook geconfigureerd om interpolatie mogelijk te maken (ervan uitgaande dat de ‘8’ van een straat, indien niet bekend, tussen de ‘6’ en de ’10’ ligt).
• Een tussenlaag tussen Pelias en de client, in de vorm van een REST API, om een reeks varianten van een adres uit te proberen. Een reeks combinaties van de volgende varianten wordt getest, totdat er één een bevredigend resultaat geeft:
  • Gestructureerde of ongestructureerde versie van de oproep tot Pelias;
  • Met de lokaliteit (plaats), of alleen de postcode;
  • Met een reeks reguliere expressies om de straat- of plaatsnaam op te schonen. Meestal zullen we alle tekst tussen haakjes verwijderen, wat heel gebruikelijk is in straatnamen om een opmerking of de naam van de deelgemeente te specificeren;
  • Door het huisnummer op te schonen, dat heel vaak ook een busnummer bevat, wat in de meeste gevallen de locatie niet verandert.

In de praktijk zien we dat de ‘basis’ gestructureerde versie (zonder opschoning of selectie) een resultaat geeft voor +/- 53 % van de adressen (voor KBO-gegevens, zie bijgevoegde figuur). Dit wordt gevolgd door 20 % na verwijdering van de lokaliteit, nog steeds in gestructureerde vorm, dan 11% in ongestructureerde vorm, 8% na opschoning in gestructureerde vorm, en dan een reeks andere combinaties voor een klein aantal adressen. Bijna alle combinaties zijn op een bepaald moment bruikbaar.

Resultaten

Het resultaat is zichtbaar in onderstaande grafieken. De bePelias-oplossing is bijna net zo efficiënt als Here WeGo (here in de grafieken) of Microsofts Bing Maps (bing); beter dan Google Maps (google), dat vrij gevoelig is voor ruis in adressen, zoals tekst tussen haakjes, en NominatimWrapper, dat enkel de straten lokaliseert voor een groot deel van de adressen.

We hebben ook de nauwkeurigheid van de bePelias-resultaten getest met behulp van een ‘majority voting’-methodologie door dezelfde dataset naar verschillende geocoders te sturen. We presenteerden de resultaten in een recent webinar, waaruit bleek dat de prestaties zeer vergelijkbaar zijn met die van Here WeGo of Bing Maps, en opnieuw aanzienlijk beter dan Google Maps, dat naast het feit dat het vaak alleen de straat lokaliseert, een vervelende neiging heeft om te hallucineren en resultaten biedt die duizenden kilometers verwijderd zijn van het juiste antwoord.

Wat snelheid betreft, geeft het feit dat de oplossing lokaal draait een aanzienlijk voordeel, namelijk twee keer zo snel als Google Maps of 5 keer zo snel als Bing Maps. Hiervoor moet de geocoder natuurlijk zo dicht mogelijk bij de toepassing die hem nodig heeft worden geïnstalleerd.

Conclusies: tool bePelias

Op basis van bovenstaande stellen wij een werkende oplossing, bePelias, ter beschikking, die je in staat stelt om lokaal een geocoder te instantiëren, met behulp van Docker, uitsluitend gebaseerd op open source code (Pelias) en open data (voornamelijk BeSt Address), met nauwelijks een paar duizend regels extra code in Python of Bash.

Onze oplossing heeft natuurlijk niet alleen maar voordelen:

• bePelias werkt alleen voor België;
• bePelias werkt alleen voor adressen. Je krijgt geen antwoord op ‘Smals, Sint-Gillis’ of ‘Bakker, Namen’;
• bePelias vereist de installatie, het beheer en het onderhoud (updaten van de server, bePelias en ‘BeSt Address’-gegevens) van een server met ongeveer 15 GB schijfruimte en minstens 8 GB RAM geheugen, wat, afhankelijk van het project, een hogere kost kan betekenen dan het gebruik van een commerciële cloud-oplossing;
• In dit stadium is dit nog een onderzoeksproject dat zich moet bewijzen in een industriële omgeving.

Daar staat tegenover dat:

• bePelias vergelijkbare prestaties biedt met de grote commerciële spelers in de sector;
• bePelias on-premise werkt, wat de problemen van vertrouwelijkheid en GDPR oplost;
• bePelias gebaseerd is op BeSt Address, de (recente) authentieke bron van adressen in België. Het verkrijgen van een ‘BeSt id’ maakt het gemakkelijker om te communiceren met een reeks webservices die deze bron hebben geïntegreerd.

Feedback is zeer welkom en zal helpen om deze tool, die klaar staat om gebruikt te worden, te verbeteren!

1. Dit is een vereenvoudigd illustratief voorbeeld, waarvan de syntaxis niet overeenkomt met een bekende tool. ︎

Deze post is een individuele bijdrage van Vandy Berten, gespecialiseerd in data science bij Smals Research. Dit artikel is geschreven onder zijn eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

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éographique¹ :

{"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.

Le géocodage est l’opération qui permet, à partir d’une adresse postale, de la standardiser et d’en obtenir les coordonnées géographiques. Nous verrons que cette opération, que nous réalisons inconsciemment tous les jours dans notre GPS ou en cherchant une adresse sur Google Maps ou autre outil cartographique, nécessite en fait une machinerie complexe. Pour en exploiter les capacités au maximum, une certaine compréhension sera nécessaire.

Durant ce webinaire, essentiellement pratique, nous répondrons à un certain nombre de questions. Qu’est-ce que le géocodage ? À quoi sert-il ? Comment s’en servir et quels sont les outils permettant de le faire ? Quels sont les avantages et inconvénients des différentes solutions, qu’elles soient commerciales ou open source, on-premise, authentiques, et comment peut-on comparer deux outils ? Nous comparerons plusieurs solutions disponibles sur le marché (commerciales ou libres), ainsi que plusieurs améliorations de solutions existantes, dont NominatimWrapper, un outil développé par Smals Research, qui est basé sur le projet collaboratif open-source OpenStreetMap.

Ce webinaire fait suite au webinaire “GIS Analytics : Quel potentiel pour les données géographiques ?” du 5 mai 2022. Il n’est cependant pas un prérequis. Aucun prérequis n’est par ailleurs nécessaire pour suivre le webinaire.

Hoe plaats je een adres op een kaart met behulp van geocodering? Geocodering is de handeling die toelaat om een postadres te standaardiseren en om er de geografische coördinaten van te verkrijgen. We zullen zien dat deze handeling, die we elke dag onbewust uitvoeren in onze gps of bij het zoeken naar een adres op Google Maps of in een andere mappingstool, eigenlijk een complex proces vereist. Om de mogelijkheden ervan optimaal te benutten, is een zekere mate van begrip nodig.

Tijdens dit voornamelijk praktische webinar beantwoorden we een aantal vragen. Wat is geocodering? Waartoe dient het? Hoe kan het worden gebruikt en met welke tools? Wat zijn de voor- en nadelen van de verschillende oplossingen, commercieel of opensource, on-premise of authentiek, en hoe kunnen we twee tools met elkaar vergelijken? We zullen verschillende bestaande oplossingen vergelijken (zowel commercieel als opensource), evenals verschillende verbeteringen van bestaande oplossingen, waaronder NominatimWrapper, een tool ontwikkeld door Smals Research op basis van het opensource samenwerkingsproject OpenStreetMap.

Dit webinar volgt op het webinar “GIS Analytics: Welk potentieel voor geografische gegevens?” van 5 mei 2022. Deelname aan het vorige webinar is echter geen vereiste. Er zijn ook geen vereisten om het webinar te volgen.

Presentation

Om een adres te kunnen plaatsen op een kaart, om een reisweg uit te stippelen of om alle winkels in een bepaalde wijk te bepalen, moet er eerst een belangrijke stap genomen worden: geocodering. Deze handeling houdt in dat een postadres zoals “Av. Fonsny 20, 1060 Bruxelles” enerzijds “gestandaardiseerd” kan worden (bordeaux gedeelte van onderstaande afbeelding), en anderzijds dat deze geografische coördinaten toegewezen krijgt (“location” in de afbeelding).  

De standaardisering zal voor een juiste opsplitsing in componenten zorgen van het adres en ook een correctie (“Av.” in “Avenue”, “1060 Bruxelles” in “1060 Saint-Gilles”). Er zullen ook niet-relevante elementen voor de geocodering kunnen geschrapt worden, zoals het grijze schuingedrukte gedeelte in “Av. Fonsny 20 bte 5 (tegenover het station)“. Deze stap komt eigenlijk neer op het maken van een correspondentie tussen een ingevoerd adres en de repository waarin elke gestructureerd adres verbonden is met zijn geografische coördinaten. Deze standaardisering maakt dus integraal deel uit van het geocodeproces en is nodig.

De omgekeerde handeling, het vragen naar alle bestaande adressen binnen een bepaalde omtrek van een punt, heet “reverse geocoding”.

Geocodering kan gedaan worden met OpenStreetMap door de volgende url op te roepen:

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

De “reverse” correspondant kan via volgend adres bekomen worden :

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

Tools

Deze handeling gebeurt normaal gezien via een API die ter beschikking gesteld wordt door een server. Er bestaan talrijke oplossingen en de keuze zal sterk afhangen van de antwoorden op de verschillende vragen die we verder gaan vermelden. We zullen ons richten op geocode van adressen in België, maar behalve enkele specifieke elementen, zullen de vragen algemeen zijn.

We hebben een aantal al dan niet commerciële tools uitgebreid bestudeerd: 

• Commercieel (Cloud) :
  • Google Maps
  • Bing Maps
  • Here
  • TomTom
  • Mapbox
• Niet-commercieel (on premise) :
  • Nominatim (OpenStreetMap), “lokaal gedockte” versie
  • NominatimWrapper, een oplossing die we ontwikkeld hebben om bepaalde lacunes van Nominatim op te vullen
  • Pelias, door er data van BestAddress op te laden (authentieke bron van adressen in België) en van OpenStreetMap

We hebben overigens in “avant-première” de API van BestAddress, bestudeerd die niet publiek beschikbaar is. Merk op dat meerdere grote actoren voor GIS-oplossingen ook gerichte oplossingen kunnen bieden, al dan niet (semi-)on-premise. We hebben deze pistes nog niet verder uitgezocht. Ze vereisen complexe commerciële stappen met deze ondernemingen..

Cloud vs on-premise

Een eerste vraag die we ons stellen is of we een commerciële API kunnen gebruiken die ‘enkel’ moet opgeroepen worden, of dat het nodig is om een “on-premise” geocoder te beheren en installeren binnen de infrastructuur van de onderneming of administratie.

Het voordeel van een commerciële Cloud-oplossing (Google Maps, Here, Bing, …) is het beheersgemak en gebrek aan infrastructuurkosten. Deze oplossingen zijn in het algemeen ook van goede kwaliteit en bieden een wereldwijde dekking. Er zal echter rekening gehouden moeten worden met kosten per oproep, wat problematisch kan worden voor grote volumes. Vaak wordt er echter een gratis aantal oproepen voorgesteld (40 000/maand voor Google Maps, 30 000/maand voor Here, …)

Dankzij de on-premise oplossingen kan beantwoord worden aan hogere eisen op het vlak van vertrouwelijkheid of naleving van de GDPR-regelgeving. Ze zullen in het algemeen ook vlugger zijn als het datavolume groter is. Er zal echter rekening gehouden moeten worden met hogere infrastructuur- en beheerskosten, en een wereldwijde dekking zal moeilijk te realiseren zijn, tenzij we beschikken over meerdere terabytes aan gegevens die aan het product gewijd kunnen worden.

Nauwkeurigheidsniveau

De eis van nauwkeurigheid, d.w.z. de noodzaak dat het adres zich precies op de juiste plaats bevindt, zal niet dezelfde zijn als het doel is om globale statistieken op te stellen, om uit te zoeken in welke wijk een adres zich bevindt, welke bezorger of inspecteur het in zijn ronde moet opnemen, als wanneer het doel is om een noodhulpteam uit te sturen. In de eerste situaties zullen we accepteren dat bijvoorbeeld een bepaald deel van de adressen zich op straatniveau bevindt en niet op het niveau van een specifiek gebouw.

Structurering van adressen

De meeste geocoders aanvaarden als invoer ofwel een gestructureerd adres (straat= “Av. Fonsny”, nummer=”20″…) ofwel een niet-gestructureerd adres (adres=”Av. Fonsny 20, 1060 St-Gilles”). Maar sommige vereisen dat het adres gestructureerd is, wat voor problemen kan zorgen als we er niet in die vorm over beschikken of wanneer ze verkeerd opgesplitst worden (straat=”Av. Fonsny 20″, nummer=””).

Authentieke bron

Eenzelfde adres kan meerdere schrijfwijzes hebben afhankelijk van de bron. Zo zijn er in Brussel twee straten genoemd (in het Frans) naar de gemeente “Tervuren” (een steenweg in Oudergem, een laan in Etterbeek, Oudergem en Sint-Pieters-Woluwe):

• Volgens Bing bestaat er “chaussée de Tervuren” en “avenue de Tervueren” ;
• Volgens Google Maps of OpenStreetMap, bestaat er “chaussée de Tervueren” en “avenue de Tervueren” ;
• Volgens BestAddress is er “Tervueren” in Etterbeek en Sint-Pieters-Woluwe, maar “chaussée” en “avenue de Tervuren” in Ouderghem ;
• Volgens het rijksregister gaat het altijd om Tervueren.

Afhankelijk van de context kan het belangrijk zijn om altijd de formulering te bekomen die overeenstemt met een precieze bron. Bijvoorbeeld omdat we per se een versie nodig hebben die bekend is bij een authentieke bron. Of, in het geval van geografische coördinaten, omdat je het gaat weergeven op een achtergrondkaart en je zo consistent mogelijk wilt zijn. Het plaatsen van een adres dat geocodeerd is met OpenStreetMap op een kaart van Google Maps kan in sommige gevallen een kleine afwijking veroorzaken.

Als je gegevens moet verkrijgen van BestAddress (in België), zijn er momenteel drie belangrijke opties:

• De “officiële” API aangeboden door Bosa (momenteel alleen in de testfase)
• In lokale installatie, Pelias met de BestAddress-dataset
• Phacochr (cfr. hieronder), enkel in batchmodus, zonder API.

Merk ook op dat er een API bestaat verschaft door “geopunt.be”, specifiek voor de Belgische adressen in Vlaanderen en Brussel (in het Nederlands).

Dekking

Een van de voordelen van Cloud-oplossingen is dat je een adres in Brussel, New York en Taipei tegelijk kunt geocoderen. Hetzelfde doen met een lokale oplossing kan onbetaalbaar veel ruimte in beslag nemen. Voor het (zeer kleine) België heeft OpenStreetMap (Nominatim) 30 GB schijfruimte nodig. Voor de hele wereld zouden meerdere terabytes nodig zijn, en meerdere weken om op te zetten.

Een installatie beperkt tot één land kan echter geschikt zijn voor een administratie die alleen adressen in haar eigen land moet beheren. Er zijn ook hybride mogelijkheden: het is mogelijk om Nominatim te configureren om volledige geocodering aan te bieden voor een selectie van landen, en zich te beperken tot lokalisatie en opschoning op stadsniveau voor de rest van de wereld.

Behoefte aan een API

We hebben ons gericht op API’s, d.w.z. “technische” interfaces die de functionaliteit bieden om adressen één voor één te geocoderen. Dit maakt het mogelijk om deze functionaliteit te integreren in een toepassing of een geautomatiseerd datamanagementproces. In sommige gevallen heb je echter een bestand met adressen die je manueel wilt geocoderen vóór een specifieke analyse. Er zijn een aantal tools beschikbaar voor dit doel, zoals GeoApify, of, voor Belgische adressen met BestAddress-gegevens, Phacochr (in een R-script, ou met de webversie)

Performantie

Het is niet voldoende om een oplossing te hebben die aan de bovenstaande criteria voldoet. Het moet ook de juiste performanties leveren. Er moet zeker rekening worden gehouden met het aspect ‘snelheid’, maar we zijn hier vooral geïnteresseerd in “robuustheid”, d.w.z. de mogelijkheid om een (nauwkeurig) resultaat te bieden voor het grootste aantal adressen. Voor een reeks steekproeven van Belgische adressen uit verschillende bronnen (officiële en niet-officiële) hebben we een aantal tests uitgevoerd. In de grafieken hieronder staat het blauwe deel voor het aandeel adressen dat de API nauwkeurig kon lokaliseren (op gebouwniveau). In oranje werd de straat gevonden, maar niet het exacte nummer. In groen kon alleen de plaats worden gelokaliseerd.

De steekproeven van elk 1000 adressen komen uit de volgende bronnen (allemaal Belgische):  

• kbo : Kruispuntbank van de Ondernemingen
• rep : Werkgeversrepertorium
• rrn : Rijksregister
• best : BestAddress (Bosa)
• resto : de site resto.be

Enkele bemerkingen konden geformuleerd worden:

• Here doet het hier beter dan Google Maps en zijn concurrenten en lokaliseert meer adressen nauwkeurig;
• Nominatim is niet erg robuust: afhankelijk van de dataset, behalve voor de BestAddress-gegevens (best_1000, die veel schoner en meer gestandaardiseerd zijn dan de andere datasets), worden tussen 10 en 15% van de adressen gewoon niet gevonden. En van een aanzienlijk deel van de adressen is alleen de straatnaam bekend;
• Onze oplossing gebaseerd op Nominatim (NominatimWrapper) verbetert zeer duidelijk de robuustheid. Maar we hebben nog steeds een groot deel van de adressen die alleen op straatniveau liggen;
• Op dit moment is Pelias beperkt tot een groot deel van de adressen op stadsniveau. Maar de integratie van BestAddress-gegevens is vrij recent, dus we kunnen in de nabije toekomst verbeteringen verwachten;
• De robuustheid van de BOSA API (bestaddress) ligt dicht bij die van Nominatim, maar dit is momenteel een bewuste keuze: het doel is niet echt om een API voor geocodering te verkrijgen, maar om de locatie van een adres mogelijk te maken dat al bekend is, d.w.z. waarvan de plaats- en straataanduidingen bekend zijn, of op zijn minst correct gespeld. De verschillende diensten die door de API worden aangeboden, maken het mogelijk om een lijst met straten voor elke gemeente te verkrijgen, waardoor het mogelijk wordt om een interface met lijsten of automatische aanvulling aan te bieden, zodat de invoergegevens “schoon” zijn. Het is dus geen volledige API voor geocodering, aangezien alleen het “lokalisatie”-gedeelte wordt aangeboden, en niet het “opschonen van gegevens”-gedeelte.

Merk op dat het feit dat een resultaat precies is, niet betekent dat het ook correct is. We hebben deze problematiek al aangehaald in een eerder artikel. Een Python-notebook is eveneens beschikbaar die een vergelijkingsmethodologie voorstelt.

NominatimWrapper staat sinds juni 2023 in de Re-Use Catalogus van de sociale zekerheid in België: https://www.ict-reuse.be/nl/service/geocode-met-verbeterde-nominatim

Om af te sluiten

Er zijn veel oplossingen beschikbaar voor geocodering. Soms moet je verder kijken dan de eerste die je te binnen schiet: elke tool heeft zijn voor- en nadelen. Technische en wettelijke beperkingen betekenen dat je jezelf een aantal vragen moet stellen. Het is ook cruciaal om de tool te testen op de soort gegevens die je moet beheren, omdat het kwaliteitsniveau en de structuur van de invoergegevens een grote invloed kunnen hebben op de kwaliteit van het resultaat.

Deze post is een individuele bijdrage van Vandy Berten, gespecialiseerd in data science bij Smals Research. Dit artikel is geschreven onder zijn eigen naam en weerspiegelt op geen enkele wijze de standpunten van Smals.

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.

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.

Nous mettons à disposition le code (Python) qui permet d’appliquer la logique présentée ci-dessous, soit en mode “batch”, soit via une API REST :

https://github.com/SmalsResearch/NominatimWrapper.

Une version plus détaillée de ce travail sera disponible sous peu, incluant une comparaison fonctionnelle et de performance, entre la solution que nous proposons, le logiciel Trillium (utilisé chez Smals) et le projet BeStAddress (source authentique d’adresses en Belgique). 

Principe de “Transformers”

Le principe général de notre solution est le suivant : avant d’envoyer les adresses à OpenStreetMap, on les fera passer par un séquence (éventuellement vide) d’opérateurs, nommés “transformers” ci-dessous, visant à les nettoyer. Les résultats d’OSM seront ensuite analysés, pour éventuellement rejeter certains résultats (avec la méthode de vérification des résultats présentée dans notre article précédent). Pour toutes les adresses qui n’ont pas donné de résultats (soit parce qu’OSM n’a donné aucun résultat, soit parce que ceux-ci ont été rejetés), nous appliquons une autre séquence de “transformers” avant ré-envoi, et ce jusqu’à ce que soit toutes les adresses ont donné un résultat, soit toutes les séquences de transformers définies ont été épuisées.

Suppression du numéro

Il est fréquent que Nominatim ne renvoie aucun résultat pour une adresse, mais qu’il en retourne un si l’on supprime le numéro. Ce premier transformer est donc très simple : il supprime simplement toute valeur du champ “house_number”. 

Il faut être conscient qu’on baisse la fiabilité, puisqu’il ne sera plus possible d’obtenir un résultat précis au niveau du bâtiment (place rank=30). Mais un résultat, même imprécis, reste meilleur qu’une absence de résultat.

Remplacement par expression régulière

Notre expérience nous a montré qu’il est fréquent de trouver des conventions peu habituelles. Par exemple, dans l’exemple détaillé ci-dessous, de nombreuses adresses sont écrites sous la forme “A FONSNY” ou “R DE LA LOI”. Nous avons aussi rencontré un grand nombre d’adresses du type “Fonsny (Avenue)” ou “Loi (Rue de la)”. Ou encore “Rue de l été”. Voire encore “SN” (sans numéro) dans le champs du numéro.

Ce genre d’adresse peut facilement être corrigée par un replacement par expression régulière. Par exemple, le cas de l’apostrophe manquante peut être corrigé en remplaçant toute occurrence de ” de l ” par ” de l'”. L’ensemble des expressions à considérer sera typiquement dépendant du dataset et des habitudes et convention que l’on y observera.

Libpostal

La librairie libpostal, présentée dans notre article précédent, est un utilitaire permettant de parser un adresse, c’est-à-dire identifier ses différentes composantes. Si on lui soumet par exemple “Smals, Avenue Fonsny 20 bte 5, 1060 Saint-Gilles”, on obtiendra comme résultat : 

[('smals', 'house'),
 ('avenue fonsny', 'road'),
 ('20', 'house_number'),
 ('bte 5', 'unit'),
 ('1060', 'postcode'),
 ('saint-gilles', 'city')]

Il devient alors facile d’ignorer les éléments qui ne font pas réellement partie de l’adresse (‘smals’, ‘house’) et ce qui décrit la boite ou l’étage (‘bte 5’, ‘unit’), de façon à ne pas les envoyer à OSM. 

Photon

Photon est un utilitaire qui combine OpenStreetMap et ElasticSearch, également présenté dans notre article précédent. Il est nettement moins sensible aux fautes de frappe que Nominatim. 

Les adresses, non trouvées jusqu’ici par Nominatim, sont envoyée à Photon (une API). On vérifie que le résultat est raisonnablement proche de l’adresse initiale, puis on la renvoie à Nominatim.

Prenons l’exemple de la « Rue de Brabant », à 1030 Schaerbeek, qui serait erronément orthographiée « Rue du Brabant ». Envoyé à Nominatim, nous n’obtenons aucun résultat :

https://nominatim.openstreetmap.org/search.php?q=RUE%20DU%20BRABANT,%201030%20SCHAERBEEK&format=jsonv2

Photon, pour la même rue, va en fait retourner dans son résultat une série de rues avoisinant la rue en question :

http://photon.komoot.de/api/?q=RUE%20DU%20BRABANT,%201030%20SCHAERBEEK

On a dans le résultat, certes la « Rue de Brabant », mais également « Rue du Pavillon », « Rue du Saphir », …. Seul le premier résultat sera gardé et renvoyé à Nominatim, qui proposera cette fois-ci un résultat.

Suppression de la rue

En dernier recours, lorsqu’aucune (séquence de) transformation n’a permis à Nominatim de trouver une adresse, nous supprimons la rue (et le numéro), dans l’espoir qu’au moins la localité soit reconnue. Il va de soi qu’un “match” d’une adresse ayant subi cette modification n’aura pas le même poids qu’un “match” sur une adresse complète.   

Expérimentations

Comme pour nos articles précédents, nous avons repris les adresses disponibles en open data, de la Banque Carrefour des Entreprises, en Belgique (https://kbopub.economie.fgov.be/kbo-open-data/login?lang=fr). Cette base de données contient 3,112 millions d’adresses d’entreprises, dont 3,027 millions en Belgique. 

Dans un premier temps, nous avons envoyé les adresses telles quelles. 83,3 % (matching rate) des adresses ont donné un résultat accepté par nos règles de vérifications présentées ci-dessus (qui en ont seulement rejeté 0,46 %). Nous avons ensuite appliqué une série de combinaisons de « transformers », présentées dans le tableau et la figures ci-contre. Au final, la séquence de transformers a permis de faire monter le taux de succès de 83,3 à 98,6 %, en 2 petites heures sur un serveur virtuel  avec 8 cœurs et 24 GB de mémoire. Nous avons évalué plusieurs séquences de transformers (par exemple, d’abord suppression du numéro, puis libpostal, ou l’inverse), mais l’impact sur le résultat était en général très faible.

Le transformer “orig” ne fait aucune modification. Nous avons dans notre expérimentation utilisé deux variantes du transformer « regex » : un premier (regex[init] ci-dessous) permettait de nettoyer les adresses en entrée, principalement la suppression de tout texte apparaissant entre parenthèse. Le second (regex[lpost]) les adresses traitées par libpostal. 

Le tableau ci-dessous indique, pour chaque étape, le nombre d’adresses ayant été envoyées à OSM (Sent), le nombre de résultats acceptés (Match), le ratio des deux (Match rate), le ratio par rapport au nombre d’adresses globales (Glob MR), ainsi que sa valeur cumulée (Cum MR). Cette dernière colonne nous permet de voir comment nous arrivons au « matching rate » de 98,64 % pour le dataset en question (99,97 en incluant « nostreet »).

Nous constatons que le « transformer » ayant eu le plus d’effet est le « regex[init] », essentiellement grâce à la suppression des parenthèses (10,43% d’amélioration), suivi de la combinaison libpostal + photon (2,84 %)

Notons que nous avons aussi appliqué notre méthode sur des adresses de moins bonne qualité, typiquement correspondant à des adresses encodées par des agents lors d’inspections. Nous avions alors un taux de succès initial de 65 %, que nos transformers ont pu faire grimper à 93 %.

Adresses non trouvées

Au total, 1,3%, soit  de l’ordre de 30.000  adresses, n’ont pas été trouvées, ou seulement après suppression de la rue. Si l’on ignore les numéros de bâtiment, cela représente 6.123 couples rue-ville. Nous avons envoyé ces 6.123 au géocodeur de Here (Nokia). Nous avons trouvé un résultat pour 4.060 adresses. Parmi ces résultats, 580 ont un code postal différent des données, indiquant soit que le résultat est incorrect, soit que le code postal est incorrect dans les données.

Lorsque le code postal est compatible (3.480), 1.960 ont une rue (quasiment) identique à la rue en entrée. Il s’agirait probablement de bons candidats pour enrichir OpenStreetMap. Nombre d’entre elles sont effectivement présentes sur OSM, mais non nommées.

Parmi les 1.540 adresses restantes, nous constatons qu’elles sont fréquemment si mal encodées qu’il est peu probable qu’un processus fiable puisse les traiter sans prendre de grands risques. Il s’agit soit d’adresses très abrégées comme « 20 P.ST.GERY » (pour « Place Saint-Géry », avec un numéro qui devrait se trouver dans un champ adéquat) ou « A 11 NOVEMB. » (pour « Avenue du Onze Novembre »), soit des informations plutôt descriptives (« Maison communale », « Hôtel XXX », « Ferme de XXX », « Café XXX », « Centre commercial XXX »…). Nous remarquons que souvent, la réponse proposée par Here est suspecte, et mériterait des investigations que nous n’avons pas menées dans le cadre de ce travail.

Numérotation

Dans les résultats fournis par OSM, 49,4 % contenant un numéro de bâtiment (avec un place_rank à 30) et 50 % n’en contenait pas (place_rank à 26), alors que seul 1,1 % n’avait pas d’information dans la champ numéro (0,8 % si on considère les numéros présents dans le champ de la rue). Si l’objectif est de géocoder les adresses, c’est-à-dire de les convertir en coordonnées géographiques, nous ne pouvons vraisemblablement pas faire mieux avec OSM, et devons simplement savoir que la moitié des points ont une précision au niveau de la rue.

S’il s’agit par contre de nettoyer les adresses, auxquelles on doit pouvoir envoyer une lettre ou un agent, il va de soi que l’on ne peut pas se contenter d’adresses où la moitié des numéros manque. Par ailleurs, plusieurs transformers ont potentiellement simplifié les numéros (22 bte 5 vers 22). Nous avons donc choisi d’enrichir les données résultat avec un numéro de bâtiment supplémentaire, suivant le principe suivant :

• Si le numéro est présent dans l’adresse en entrée, on le reprend
• Sinon, on applique « libpostal ». Si ce « parsing » donne un numéro, on le garde.

En faisant ceci (on calcule donc le numéro uniquement sur base des données en entrée, et non sur le résultat d’OSM), on a donc un numéro dans 99,2 % des cas (cf les 0,8 % évoqués ci-dessus).

Pour 50,2 % des adresses, il s’agit d’une information que OSM n’avait pas fournie. Dans 44.6 % des cas, elle est identique à celle d’OSM. Dans 4,3% des cas, il y a une différence, essentiellement constituée de différentes façons d’écrire « la même chose » (« 10 » au lieu de « 10-12 », « 10 ;12 » au lieu de « 10-12 ») ou presque (« 10 » au lieu de « 10 a »).  Nous avons également identifié quelques très rares cas, où quand on fournissait à Nominatim une adresse sans numéro, il y en avait un dans le résultat.

Conclusions

Au travers de ce travail, nous avons pu répondre aux principales contraintes que nous rencontrions, à savoir proposer une solution efficace de géocodage (standardisation des adresses, et calcul des coordonnées géographiques), on-premise et open source. Les difficultés étaient nombreuses, mais toutes ont pu être résolues avec des solutions ouvertes et gratuites : OpenStreetMap, Photon et Libpostal.

Notre solution est disponible en open source : https://github.com/SmalsResearch/NominatimWrapper

Il reste certes des pistes d’amélioration, mais le niveau de ce que nous offrons est déjà largement supérieur à ce qu’OpenStreetMap offre de base.

____________

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

Dans ce premier article, nous décrirons les difficultés que nous avons rencontrées. Suivra un second article détaillant la solution que nous avons élaborées.

Contexte

Lorsque l’on traite des données administratives ou commerciales, les adresses (de clients, de citoyens, d’entreprises…) sont probablement une des données pour lesquelles s’assurer une bonne qualité peut sembler facile, mais ne l’est dans la pratique pas du tout. Il est très difficile de s’assurer de deux choses :

• Que l’adresse soit standardisée, qualité essentielle pour pouvoir soit détecter des doublons (Matching), soit relier des entités entre deux bases de données (Entity Linking). On veut donc éviter à tout prix une base de données qui ressemblerait à ceci :

• Que l’adresse existe, autant la ville que la rue (dans ladite ville) et le numéro (dans la rue). 

Ni la standardisation ni la vérification d’existence ne peut se faire sans une base de connaissance complexe et mise à jour, associée aux outils adéquats permettant de l’interroger intelligemment. Ceci peut principalement se faire par deux types d’outil :

• Soit des outils spécialisé en qualité de données : Trillium (SyncSort), RedPoint, ou le module “Data Quality” de la plupart des gros vendeurs de solution de gestion de données (Informatica, IBM, SAS, SAP, Talend, Oracle…)
• Soit des API publiques, souvent associées à un outils de visualisation cartographique (déjà présentées dans un blog précédent): google.com, www.here.com (Nokia), maps.bing.com (Microsoft), www.openstreetmap.org

Nous avons plusieurs fois été confrontés à des clients qui, d’une part, ne devaient – ou ne voulaient – que nettoyer des adresses, et pour qui investir dans une suite logicielle complexe, chère et difficile à prendre en main n’était pas une option. D’autre part, pour qui la législation ou la confidentialité des données ne leur permettaient pas d’envoyer des centaines de milliers, voire de millions d’adresses, à un gros acteur américain. 

Il nous a donc fallu penser à une autre solution, et nous nous sommes tournés vers l’outil de cartographie Open Source et communautaire, OpenStreetMap, qui permettait d’installer une copie de leur géocodeur, intégrale ou localisée. Nous avons vite été confrontés à de nombreux obstacles, que nous allons partager ci-dessous, avec, dans le prochain article, la façon dont nous sommes parvenus à les contourner.

OpenStreetMap et Nominatim

OpenStreetMap (ou OSM) est un projet de cartographie libre, que l’on peut voir comme l’équivalent Open Source et collaboratif de Google Maps. Un des composant d’OSM est son géocodeur, qui permet, à partir d’une adresse ou du nom d’un lieu, d’obtenir un certain nombre d’informations, dont des coordonnées géographiques et un version standardisée de l’adresse.

L’outil de géocodage d’OpenStreetMap s’appelle Nominatim. Il peut soit s’utiliser via une page web (https://nominatim.openstreetmap.org/), soit via une API, en invoquant simplement une URL.

Nous pouvons par exemple obtenir des informations à propos du « 16, Rue de la Loi, Bruxelles », en appelant l’URL suivante :

https://nominatim.openstreetmap.org/search.php?q=16%2C+rue+de+la+loi%2C+bruxelles&format=jsonv2&addressdetails=1

On obtiendra :

[{
  [...]  "lat":"50.8461624",
  "lon":"4.3665285",
  "display_name": "16, Rue de la Loi, Quartier Royal, Brussels, 
      Ville de Bruxelles, Brussels-Capital, 1000, Belgium",
  "place_rank":30,
  "address":{
     "house_number":"16",
     "road":"Rue de la Loi",
     "suburb":"Quartier Royal",
     "state":"Brussels-Capital",
     "postcode":"1000",
     "country":"Belgium",
    [...] }
[...]}]

Par la suite, nous utiliserons indistinctement les termes OpenStreetMap, OSM ou Nominatim.

Contraintes 

Nous allons supposer pour la suite un certain nombre de contraintes, correspondant à notre expérience auprès de plusieurs clients, détaillées dans les sections suivantes.

Liste structurée

Nous avons en entrée une liste d’adresses structurée, à savoir avec un champ pour la rue, un autre pour le numéro, puis deux champs pour le code postal et la ville. Il va de soi qu’il arrive cependant fréquemment que la numéro du bâtiment soit renseigné dans la champ “rue”. 

Cette découpe “rue-numéro-code postal-ville” correspond à la plupart des adresses postales dans les pays d’Europe occidentale, mais n’est pas universelle : elle ne permet pas de désigner un point telle qu’une borne kilométrique sur une autoroute, et n’est pas le standard dans de nombreux pays d’Asie ou d’Amérique.

Ça n’empêchera cependant pas certains commerçants de faire preuve de créativité pour désigner leur magasin, en indiquant dans le champ rue : “Centre commercial XXX, 2ème étage, aile droite”. Des valeurs de ce genre, difficile à géocoder automatiquement, pourront être laissées telles quelles.

Vérification du résultat

Nous choisissons de ne pas faire une confiance aveugle au géocodeur : si une adresse semble trop différente de l’adresse en input (et nous reviendrons plus pas sur la difficulté de ce test), nous la refusons. 

Nous avons constaté que là où d’autres géocodeurs, comme Google Maps, donnent presque toujours une réponse, quitte à être éloignée de la réponse attendue, OpenStreetMap joue plutôt la carte de la prudence, et préférera ne pas renvoyer de réponse qu’une réponse fausse. Mais il nous est cependant arrivé de tomber sur des réponses incorrectes. Par exemple, pour “Chée de Bruxelles, 1780 Wemmel”, OpenStreetMap renverra les résultats ci-dessous, sur la requête suivante (en tout cas au moment d’écrire ces lignes) : 

https://nominatim.openstreetmap.org/search.php?q=Ch%C3%A9e+de+Bruxelles%2C+1780+Wemmel&format=jsonv2&addressdetails=1

[
  { (...)
     "lat":"50.8096144","lon":"4.4437879",
     "address":
         {"house_number":"2057",
          "road":"Chaussée de Wavre",
          "town":"Auderghem",
          "postcode":"1160" (...)}
   },
   {(...)
    "lat":"50.8571889","lon":"4.3324168",
    "address":
      {"road":"Chaussée de Gand",
       "town":"Molenbeek-Saint-Jean",
       "county":"Brussels-Capital",
       "postcode":"1080" (...)}
]

Unicité du résultat

Alors que la plupart des géocodeurs, pour une adresse en entrée, proposent plusieurs résultats en sortie, nous ne pouvons dans notre contexte pas laisser à un être humain le choix du meilleur candidat et devrons le sélectionner automatiquement.

Environnement multilingue

Nous travaillons en Belgique dans un environnement multilingue, en particulier dans certaines régions de Belgique : “Avenue Fonsny, Bruxelles” (en français) est donc équivalent à “Fonsnylaan, Brussel” (en néerlandais).

Solution “on-premise”

Comme précisé plus haut, il nous fallait une solution tournant entièrement en interne, sans connexion à Internet, y compris au moment de la mise en place de la solution.

Limitation d’OpenStreetMap

Dans un premier temps, nous avons installé une instance Docker d’OpenStreetMap (https://hub.docker.com/r/mediagis/nominatim/) en y installant toutes les données de la Belgique (disponibles sur http://download.geofabrik.de), et y avons simplement, au travers d’un script en Python, envoyé toutes les adresses (entre 200.000 et 3.000.000 selon le dataset). Mais nous avons vite déchanté : le match rate (la proportion d’adresses pour lesquelles OSM proposait une adresse) se situait, en fonction du dataset, entre 65 et 93 %. Nous avons cependant rapidement eu le sentiment, en effectuant des légères modifications sur les adresses entrées, que ce taux pouvait facilement être augmenté. Voici quelques-unes des difficultés que avons rencontrées.

Manque de souplesse

Au niveau des numéros

OpenStreetMap, en général, connait les numéros des maisons, mais pas les informations de boite, appartement, étage… information que l’on retrouve très souvent dans le champ “numéro” des bases de données sur lesquelles nous avons travaillé.

On obtient donc bien un résultat pour “Avenue Fonsny 20, 1160 Bruxelles”, mais on ne reçoit aucun résultat pour “Avenue Fonsny 20 bte 2, 1160 Bruxelles”. Si nous écrivons, par contre, “Avenue Fonsny 20/2, 1160 Bruxelles”, OSM nous propose un résultat au niveau de la rue, en ignorant le numéro.

Au niveau des noms

Il s’agit d’être précis dans les noms que l’on fournit. OSM ne fournit par exemple aucun résultat pour les adresses suivantes : 

• Avenue Fonsny 20, 1060 Bruxelle
• Avenue Fonsni 20, 1060 Bruxelles
• Avenu Fonsny 20, 1060 Bruxelles

Manque de consistance du résultat

L’inconvénient principal du modèle d’OpenStreetMap, où chaque contributeur peut ajouter des données à sa guise, est qu’il est difficile d’imposer une cohérence dans la façon d’introduire les données. 

Le résultat d’une requête à Nominatim est un dictionnaire au format “json”, qui contient une entrée “address” dans laquelle on trouve les différentes parties de l’adresse. En analysant un grand nombre de ces résultats, nous avons trouvé le concept de “rue” dans pas moins de 7 champs: “road”, “pedestrian”,”footway”, “cycleway”, “path”, “address27”, “construction” (ainsi que, de façon plus marginale, dans “hamlet” ou “park”). Idem au niveau de la localité : “town”, “village”, “city_district”, “county”, “city”.

Si la distinction entre ces différents types de rue ou de localité a bien du sens, elle nous posait un problème : au final, nous devions produire un résultat avec une colonne “Rue” et une colonne “Localité”. 

Manque de précision

Dans le résultat d’OSM, on trouve un champ “rank” indiquant le degré de précision : 30 si le bâtiment précis a été identifié ; 26 si seulement la rue a pu être localisée (plus de détails ici). 

En général, nous avons constaté que seuls 50% des résultats avaient un rank à 30, les autres seulement 26. Donc seulement 50% des adresses ont pu être localisées au niveau du bâtiment, les autres l’ayant été uniquement au niveau de la rue, alors que plus de 99% des adresses en entrée contenaient un numéro.

Par ailleurs, nous avons constaté que quand le numéro de bâtiment n’est pas connu d’OSM, nous avons soit pas du tout de résultat, soit un résultat sans numéro (rank à 26). Et dans de très nombreux cas sans résultat, il a suffi de renvoyer à Nominatim l’adresse sans numéro pour obtenir un résultat (de rank 26 en général). Nous ne sommes pas parvenu à identifier de critère qui justifiait la différence de traitement.

Outils de nettoyage

Face à ces limitations, nous avons identifié deux outils qui nous permettait de préparer les données avant de les envoyer à Nominatim :  Libpostal et Photon.

Libpostal

La librairie libpostal est un utilitaire permettant de parser un adresse, c’est-à-dire identifier ses différentes composantes. Si on lui soumet par exemple “Smals, Avenue Fonsny 20 bte 5, 1060 Saint-Gilles”, on obtiendra comme résultat : 

[('smals', 'house'),
 ('avenue fonsny', 'road'),
 ('20', 'house_number'),
 ('bte 5', 'unit'),
 ('1060', 'postcode'),
 ('saint-gilles', 'city')]

Il devient alors facile d’ignorer les éléments qui ne font pas réellement partie de l’adresse (‘smals’, ‘house’) et ce qui décrit la boite ou l’étage (‘bte 5’, ‘unit’), de façon à ne pas les envoyer à OSM. 

Photon

Photon est utilitaire qui combine OpenStreetMap et ElasticSearch. Il permet de donner beaucoup de flexibilité, notamment en étant nettement moins sensible aux fautes de frappe. Il s’avère très utile dans un environnement interactif, où l’utilisateur peut choisir parmi une liste proposée par Photon, mais nous avons trouvé que dans un environnement “batch” (sans interaction avec un être humain), il n’était pas vraiment une alternative viable à OpenStreetMap, essentiellement parce qu’il fournit souvent énormément de résultats, parfois très éloignés de ce qui était attendu.

Par contre, nous avons trouvé qu’il s’agissait d’un excellent partenaire d’OpenStreetMap, permettant de préparer les données. Nous avons envoyé à Photon toutes les adresses qu’OpenStreetMap ne reconnaissait pas. Cela nous a donné un grand nombre de résultats, mais en utilisant la technique décrite ci-dessous, nous n’en avons gardé que ceux étant “raisonnablement proches” des données en entrée. Les adresses qui ont ainsi été légèrement modifiées sont renvoyées à OpenStreetMap.

Vérification des résultats d’OSM

Comme déjà évoqué, nous voulions limiter les risques de recevoir pour une adresse un résultat ne correspondant pas du tout à nos attentes. Sachant que nos données en entrée sont relativement structurées, il semblait relativement aisé de comparer, par exemple, la rue en entrée avec la rue du résultat, avec un algorithme de distance entre deux chaines de texte, comme (Damerau-)Levenshtein ou Jaro(-Winkler). 

Pour la comparaison de rue, nous avons cependant fait face à un certain nombre d’obstacles. En particulier, il est fréquent le nom de la rue du résultat soit (légitimement) très éloigné du nom fourni à OSM. Voici quelques exemples :

Le premier cas s’explique par le fait que la langue dans laquelle l’adresse a été encodée (le français dans l’exemple) ne correspond pas à la langue officielle de la ville en question (le néerlandais). 

Dans le deuxième cas, il arrive en particulier quand la rue porte le nom d’une personne, que le prénom soit complet, abrégé ou absent, dans l’adresse en entrée comme dans le résultat. 

Le troisième cas est une conséquence de l’évolution des noms des rues et autre place. La place communale a en l’occurrence été rebaptisée, et OSM connait tant le nouveau nom que l’ancien, mais renverra toujours le nom actuel dans le résultat. 

Le dernier cas concerne surtout les grands axes, qui peuvent à la fois avoir un nom local (un nom de rue) et un nom plus large, quand elles font partie d’un axe plus important, comme ici une nationale.

Tous ces exemples illustrent le fait qu’OSM connait dans de nombreux cas plusieurs dénominations pour une seule rue. Ces différentes dénominations sont utilisées pour reconnaître un nom, mais la dénomination du résultat ne correspond pas nécessairement à celle qui a permis de le trouver. 

Heureusement, un simple ajout du paramètre “namedetails=1” à la requête vers Nominatim permettra d’obtenir toutes les dénominations connues pour l’axe en question. Pour le premier exemple, on aura dans la requête suivante : 

https://nominatim.openstreetmap.org/search.php?q=Rue%20des%20Bluets,%20Crainhem&format=jsonv2&addressdetails=1&namedetails=1

un bloc supplémentaires (“namedetails”) contenant les valeurs suivantes : 

{"name":"Korenbloemenstraat",
 "name:fr":"Rue des Bluets",
 "name:nl":"Korenbloemenstraat"}

Conclusion

À travers cet exercice, nous avons pu prendre mesure de la complexité que représentait le nettoyages d’adresses postales. Un outil tel qu’OpenStreetMap, optionnellement installé localement, permettra à moindre coût de corriger une grande partie des données. Mais il se peut, en fonction de la qualité des données à traiter, que le résultat (principalement en termes de proportion d’adresses correctement nettoyées) ne soit pas à la hauteur des attentes. Heureusement, nous verrons dans notre prochain article qu’avec un peu de travail et quelques outils adaptés, il est possible de notablement améliorer les performances du nettoyage.

____________

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

Le contexte d’aujourd’hui a changé, mais le besoin est plus que jamais présent : à partir d’une liste d’adresses de clients, de patients, de citoyens, de chantiers, de succursales, de nombreuses sociétés ou organismes publiques ont besoin de visualiser des données sur une carte. Si John Snow, connaissant bien le quartier, a pu localiser sur une carte chaque adresse de sa liste, cette opération peut aujourd’hui se faire automatiquement : c’est le rôle d’un géocodeur.

À partir d’une adresse postale (Rue Fonsny 20, 1060 Bruxelles), un géocodeur fournit typiquement un couple de coordonnées géographiques : 50.8361263, 4.3382716 (selon le standard WGS84, utilisé entre autres par les GPS, et qui diffère de la notation traditionnelle apprise à l’école : 50°50’10.1″N, 4°20’17.8″E). Une fois la liste des coordonnées obtenue, on peut typiquement en réaliser une carte de type “bubble” (la taille et la couleur des points pouvant dépendre d’un paramètre quelconque), ou une “heatmap”, mettant en évidence la densité des points.

Géocodeurs

Il existe de nombreux outils permettant ce géocodage. Une partie de ces outils sont des interfaces web simples, dans lesquelles on envoie typiquement un fichier (listing Excel, par exemple), dont chaque adresse est géocodée avant, pour certains, d’être affichée sur une carte : Google Fusion Table, CartoDB, BatchGeo ou EasyMapMaker en sont quelques exemples. En version gratuite, ces outils sont cependant assez contraignants. Soit le débit est fortement limité, soit le nombre de requêtes est limité à quelques dizaines, voire quelques centaines par mois.

Dans la suite de cet article, nous allons nous intéresser à des outils moins “grand public”, nécessitant un peu de programmation (dont nous passerons les détails), et ayant des contraintes nettement moins limitatives. Il s’agit d’API (Application Programming Interface) que l’on invoque soit via un script, soit, dans notre cas, via un outil tel qu’OpenRefine. Nous allons considérer les API de Google (Google Maps), OpenStreetMap, Microsoft (Bing), Nokia (Here), MapQuest, OpenCageData, ainsi qu’une version Beta de l’Institut Géographique National belge (uniquement pour les adresses en Belgique).

L’usage est en général assez simple. Par exemple, avec Google Maps, pour géocoder l’adresse “Avenue Fonsny 20, 1060 Bruxelles”, il suffit d’invoquer l’URL suivante (cliquer dessus pour voir le résultat) :

http://maps.googleapis.com/maps/api/geocode/json?sensor=false&address=Avenue%20Fonsy%2020,%201060%20Bruxelles

Deux informations nous intéressent dans le résultat : les coordonnées géographiques, bien sûr, mais également la fiabilité (ou confidence, en anglais) du résultat. Dans notre cas, “RANGE_INTERPOLATED”, qui signifie que Google ne connaît pas la position exacte du numéro 20 de l’Avenue Fonsny, mais qu’il l’a interpolée à partir d’autres numéros de la même rue pour lesquelles il connait la localisation. Il se peut par exemple que Google Maps soit capable de localiser la ville, mais pas la rue. Il donnera alors la position du centre de la ville, et précisera comme qualité “GEOMETRIC_CENTER”.

Toutes les API n’ont cependant pas la même façon de préciser la fiabilité du résultat. Il s’agit parfois d’une valeur entre 0 (très précis) et 10 (très peu précis), parfois de valeurs telles que “High”, “Medium” ou “Low”.

Comparer la qualité

Ce n’est bien sûr pas parce qu’un géocodeur retourne des coordonnées et précise qu’elles sont d’une fiabilité optimale que le résultat est correct. Par exemple, la commune de Mons (province du Hainaut) est composée de plusieurs localités, dont Frameries (Code postal : 7022) et Jemappes (Code postal : 7012). À Frameries, il existe une rue nommée “Avenue Général Leman”, et à Jemappes, à 5 kilomètres de là, une “Rue du Général Leman”. Si l’on demande à Bing de localiser “Rue Léman, 7012 Mons”, il localise en fait l’Avenue Léman à 7022 Frameries, alors que Google Maps propose bien celle de Jemappes. Les deux géocodeurs annoncent par ailleurs un niveau de fiabilité élevé.

Si l’on veut comparer les performances de plusieurs géocodeurs, on trouve dans la littérature (par exemple ici) une méthodologie qui consiste à se construire un grand ensemble d’adresses, dont on connaît les coordonnées géographiques précises, puis de les soumettre aux géocodeurs à tester pour voir à quel point les réponses sont compatibles avec la connaissance préalablement acquise.

Méthodologie

L’inconvénient majeur de cette méthodologie est qu’il faut construire une telle base de connaissance, représentative de données qui seront ensuite utilisées. On ne pourra avec une telle méthodologie que comparer des régions connues des testeurs. Si deux géocodeurs orthographient une rue différemment, il faudrait quasiment se rendre sur place pour voir lequel se trompe. Nous proposons ici d’utiliser une méthodologie plus abordable, ne nécessitant aucune connaissance au préalable. L’idée est très simple : on part d’une liste d’adresses importante, et on géocode ensuite chacune de ces adresses avec une série de géocodeurs différents.

Supposons que pour une adresse, cinq géocodeurs la localise dans un périmètre restreint, mais qu’un sixième géocodeur la situe à plusieurs kilomètres. On va supposer dans nos tests que ce dernier se trompe probablement, et on considère que si un géocodeur, pour un grand nombre d’adresses, se situe loin des autres, c’est qu’il est vraisemblablement de qualité moindre. Cette méthodologie n’a aucune prétention scientifique sérieuse. Il s’agit juste d’une réflexion, qui n’a pas été poussée aussi loin que si l’on se plaçait dans un contexte scientifique, mais qui nous a permis de nous éclairer dans une situation concrète rencontrée dans un contexte professionnel.

Pour nos tests, nous avons considéré un ensemble de 10.000 adresses provenant de la Banque Carrefour des Entreprises en Belgique, disponibles en Open Data. 98.4% de ces entreprises ont leur adresse en Belgique, les autres à l’étranger. Il conviendra bien sûr de prendre des données propres à la région ou au pays pour lequel on souhaite tester les géocodeurs. La qualité des données est quelque part conforme à ce que l’on trouve en pratique. Par exemple, il manque le nom de la rue dans 0.4% des cas, le champ “numéro” contient autre chose qu’un numéro dans 2.1% des cas.

Nous avons réalisé les géocodages en utilisant l’outil OpenRefine, et l’analyse a ensuite été faite avec Qlik Sense. L’analyse complète, nécessitant Qlik Sense, peut être obtenue ici.

Match rate

Une première métrique simple que nous avons considérée est le “Match rate”, à savoir la proportion d’adresses pour laquelle un géocodeur fournissait une réponse. On voit par exemple qu’OpenStreetMap (OSM) n’a pas pu géocoder à peu près un quart de nos adresses, alors que MapQuest (MQ) arrive à 0.01% d’échec. Le géocodeur (en phase Beta) de l’IGN (belge) a également encore du progrès à faire.

Un haut “match rate” n’implique bien sûr pas une bonne qualité, mais on pourrait déjà être amené, à ce stade, à écarter l’IGN et OpenStreetMap des compétiteurs.

Écart par rapport à la médiane

Pour évaluer si un géocodeur est éloigné de la majorité, nous considérons comme référence le point médian, c’est-à-dire un point laissant autant de points à droite qu’à gauche, et autant en bas qu’en haut. En effet, s’il y a un consensus, ce point se trouvera en général au cœur de ce consensus. Notons que ce point médian peut faire partie de l’ensemble (si la latitude médiane est fournie par le même point que la longitude médiane) ou être virtuellement ajouté.

Dans l’exemple ci-dessus, le point médian est en rouge. On peut voir qu’un résultat est très éloigné du point médian, alors que 5 en sont très proches. Notons que si nous avions pris la moyenne et non la médiane, le point moyen aurait été situé entre agrégat de gauche et le point à droite, et tous les résultats auraient été considérés comme éloignés de la référence.

Le graphique ci-contre reprend la distance moyenne en kilomètres (par approximation équirectangulaire) pour l’ensemble des adresses par rapport à leur médiane respective, pour chaque géocodeur. Plus la valeur est élevée, plus on s’éloigne souvent du consensus, et donc, selon notre méthodologie, moins bon est le géocodeur.

On constate très facilement que MapQuest, qui obtenait le meilleur match rate, est de très loin moins performant que tous les autres. En moyenne, les adresses géocodées par MapQuest sont localisées à plus de 2000 km des autres géocodeurs ! En poussant un peu plus loin l’analyse, on se rend compte que pour à peu près 25% des adresses, MapQuest ne parvient pas à localiser l’adresse, et, plutôt que de retourner un code d’erreur ou un résultat vide, localise l’adresse … au milieu des États-Unis ! Clairement donc à éliminer, en tout cas pour des adresses sur le territoire belge. Le graphique de droite supprime MapQuest.

Ce qui surprend maintenant, ce sont les mauvais résultats de Here (8 kilomètres du point médian en moyenne !), et OpenCageData (OCD), près de 5 kilomètres. Ces mauvais scores ont en fait des raisons très différentes, que nous allons maintenant détailler.

Here victime de son succès

Comme on a pu le voir plus haut, le “match rate” (proportion d’adresses pour lequel un géocodeur a fourni une réponse) est loin d’atteindre 100 % pour chaque adresse. Ce qui signifie que chaque adresse n’a pas 7 points (le nombre de géocodeurs de notre analyse) à comparer. Dans les faits, 70 % des adresses ont pu être géocodées (correctement ou non) par chacune des 7 API, 23 % par seulement 6, puis 5.7 % (5 géocodeurs), 1.1% (4), 0.2 % (3),  0.3 % (2) et 0.07 % (1).

Or, Here et MapQuest sont les deux géocodeurs avec le meilleur match rate, et un nombre non négligeable d’adresses ont été situées uniquement par MapQuest aux États-Unis (comme expliqué ci-dessus), et par Here au bon endroit, avec un écart dépassant souvent les 10.000 kilomètres. Or la médiane entre deux nombres est, dans l’outil que nous avons utilisé (Qlik Sense), la moyenne de ceux-ci. Ce qui nous fait un point de référence au milieu de l’océan Atlantique, les deux points étant alors considérés comme de 4 à 5000 kilomètres du point médian.

Pour éviter ce biais, nous pouvons supprimer toutes les adresses ayant été géocodées avec succès par moins de quatre géocodeurs (soit une soixantaine d’adresses). En supprimant de la comparaison 0.6 % des adresses, on obtient un résultat pour Here nettement meilleur, comme le montre le graphique ci-dessous.

OpenCageData : souvent uniquement la ville

On voit maintenant qu’OpenCageData (OCD) possède la distance moyenne à la médiane la plus élevée : plus de deux kilomètres ! Si un GPS avait cette précision-là, on aurait du mal à trouver son chemin !

Mais l’on peut s’intéresser au niveau de fiabilité associé à ces adresses. Pour chaque adresse géocodée, OpenCageData retourne également une valeur entre 0 (peu fiable) et 10 (très fiable). Sur les 10.000 adresses à géocoder, 3800 ont reçu un code “0”. Et en effet, pour la plupart de ces adresses, l’API a été capable de trouver la ville, mais pas la rue. On a donc des coordonnées qui correspondent au centre de la ville. Si l’on ne s’intéresse qu’à ces adresses-là, la distance moyenne à la médiane est de 4 kilomètres (pour un peu moins d’un kilomètre pour les autres, ce qui reste important).

On peut également remarquer que l’IGN et OpenStreetMap, même si elles n’ont pas un très bon “match rate”, semblent avoir une bonne précision (si l’on accepte le postulat que le point médian est, en générale, une approximation acceptable de la bonne réponse). Il semblerait que ces outils, contrairement à MapQuest, préfèrent, quand ils ne sont pas sûrs de la réponse, ne pas répondre plutôt que de donner une réponse aléatoire.

En dehors de l’IGN (qui n’a marché que sur 88% des adresses), le géocodeur qui se comporte le mieux par rapport au point médian est Bing, de Microsoft. La distance moyenne par rapport au point médian est de 230 mètres.

Distribution

Si la moyenne d’un ensemble de valeurs donne une information intéressante sur cet ensemble, la distribution complète est beaucoup plus riche. C’est ce que montre le graphique ci-contre. Il y regroupe les adresses par distance à la médiane, pour chaque géocodeur. On peut par exemple y voir que pour Bing et Here (bleu clair et turquoise), 85 % des adresses ont été géocodées dans un rayon de 100 mètres par rapport à la médiane et 10% entre 100 mètres et un kilomètre. On y voit également que pour OpenCageData, environ un tiers des adresses sont dans un rayon de 100 mètres par rapport à la médiane ; un autre (petit) tiers entre 100 mètres et 1 kilomètres, et un dernier tiers entre 1 et 10 kilomètres. On peut aussi apercevoir le pic que MapQuest présente entre 1000 et 10.000 kilomètres ; il s’agit des +/-25% d’adresses localisées aux États-Unis.

Selon notre méthodologie, on peut estimer que plus une distribution est “collée sur la gauche” (c’est-à-dire place un maximum de résultats dans la case 0-100 mètres), meilleure elle est. Google Maps et l’IGN restent dans le groupe de tête, juste derrière Here et Bing.

Conclusion

Si le postulat de base (le point médian est une bonne approximation de la position correcte) est contestable, il nous a permis néanmoins de mettre en évidence des problèmes que nous aurions difficilement pu localiser autrement : les 25% d’adresses que MapQuest localise erronément au milieu des États-Unis, ou les 38% d’adresses pour lesquelles OpenCageData localise la ville mais pas la rue. Nous avons le sentiment, suite à notre analyse, que Here et Bing fournissent des réponses de meilleure qualité que Google Maps, mais une étude plus poussée serait clairement nécessaire pour en avoir la certitude.

Si la méthodologie peut s’appliquer pour toute région géographique, les conclusions que nous tirons ici ne sont valables que pour des adresses majoritairement localisées sur le territoire belge. Il se pourrait par exemple très bien que pour des adresses américaines, MapQuest surpasse tous les autres.

Le modèle souffre encore de certains défauts, sources d’améliorations futures. On pourrait par exemple, avant de considérer le point médian comme référence, s’assurer qu’il se situe bien au sein d’un cluster de petite taille. Il arrive par exemple qu’une adresse soit localisée par seulement trois géocodeurs, une fois à la côte belge, une fois dans le fin fond des Ardennes et troisième fois en Amérique du Sud. Ce genre de cas devrait être éliminés de la comparaison, parce qu’aucun de ces trois points n’a de raison de servir de point de référence. Nous l’avons fait, mais cela n’a pas eu un impact notable sur les conclusions (si ce n’est que Here dépasse alors légèrement Bing en termes de distance moyenne par rapport au point médian).

Il serait également intéressant, avoir d’effectuer le géocodage, de faire passer la liste d’adresses par un outil de “Data Quality”, de façon à nettoyer toutes les adresses incomplètes ou mal formatées. Ou encore, quand cela s’applique, de comparer la différence entre fournir une adresse sous forme d’une seule chaîne de caractères, ou bien déjà découpée en ses différents composants (rue, numéro, code postal…).

On peut aussi, au lieu de s’intéresser à la distance au point médian, au nombre de fois que l’on s’en éloigne de, par exemple, plus d’un kilomètre. Un graphique dans ce sens est disponible sur notre dashboard nécessitant Qlik Sense. Nous serons bien évidemment heureux de faire une analyse plus poussée avec nos clients et partenaires qui en feront la demande !

]]>