Géocoder (standardiser + localiser) un grand volume d’adresses avec un outil commercial américain est un problème dans beaucoup de situations. D’une part parce que cela nécessite d’envoyer ses adresses en dehors de l’Europe, d’autre part parce que le résultat ne sera pas conforme à BeSt Address, le standard administratif de BOSA pour les adresses en Belgique. Avec bePelias, une version améliorée du géocodeur open-source Pelias adapté aux données de BeSt Address, nous proposons une solution on-premise de géocodage, ayant des performances comparables aux grandes solutions commerciales.

Presentation

Data quality management, regelmatig besproken in deze blog, bestaat vaak uit het verwerken (vergelijken, vergemakkelijken, transformeren, “fonetiseren”, enz.) van karakterketens: namen van mensen, ondernemingen, steden, straten, telefoonnummers, e-mailadressen, …

In deze blogpost nemen we een kijkje naar het soort problemen dat kan worden opgespoord wanneer data gekoppeld raken met geografische coördinaten (breedtegraden, lengtegraden), rekening houdend met open data van het project BeSt Address (Belgian Street Address), van de FOD BOSA, authentieke bron voor adressen in België. Dit project verzamelt en consolideert gegevens van de gewesten (UrbiS voor het Brussels Gewest, het Adressenregister voor Vlaanderen en ICAR voor Wallonië), die op hun beurt adresgegevens ophalen die verzameld zijn door elke gemeente, de instantie die verantwoordelijk is voor de toewijzing van adressen. Een reeks CSV- of XML-bestanden kan hier worden gedownload met de officiële spelling en geografische coördinaten van elk adres in België.

Onze ervaring heeft ons geleerd dat de BeSt Address data veruit de meest kwalitatieve zijn in vergelijking met andere officiële bronnen die adressen bevatten (Rijksregister, Werkgeversregister, Kruispuntbank van Ondernemingen, enz.), ten minste de klassieke aspecten van datakwaliteit (consistentie van namen, afwezigheid van afkortingen, enz.), het resultaat van de enorme inspanningen van de teams in de gewesten en de FOD BOSA. Toch konden we een aantal anomalieën vinden die alleen geïdentificeerd konden worden door naar de geografische gegevens en ruimtelijke analyses te kijken.

De meeste geïdentificeerde anomalieën komen overeen met verkeerd geplaatste adressen (verkeerde coördinaten) of problematische postcodes. Opschoning kan alleen worden uitgevoerd door de entiteiten op het terrein, d.w.z. de gemeenten.

Merk op dat de anomalieën die hieronder worden gepresenteerd het resultaat zijn van een “academische” analyse. Deze is al besproken met een aantal mensen van de relevante instanties (gewesten, rijksregister, FOD BOSA, NGI, etc.), en sommige van deze afwijkingen worden aanvaardbaar geacht. Deze blogpost wil geen kritiek uiten op de kwaliteit van de data, maar simpelweg een methodologie presenteren en deze illustreren met een relevante databron.

Context

Zoals in een vorige blogpost is beschreven, bestaat België op het moment van schrijven uit 581 gemeenten (dit aantal zal de komende maanden afnemen na een reeks fusies van gemeenten). Elk van deze gemeenten bestaat uit een of meer postcodes (verbonden met een naam in Brussel en Vlaanderen), en elk van deze postcodes kan een of meer deelgemeenten of lokaliteiten bevatten (part of municipality in Wallonië, in BeSt Address-jargon).

Voor de onderstaande analyse baseerden we ons op de CSV-bestanden die beschikbaar zijn op https://opendata.bosa.be/, en voerden we vier soorten analyses uit: 

• In de eerste analyse kijken we of alle busnummers op hetzelfde adres dicht bij elkaar liggen;
• In de tweede vergelijken we de grenzen van de postcodes gedefinieerd door bpost (de Belgische postdienst) met de postcodes van adressn uit BeSt Adress;
• In de derde analyse gaan we op zoek naar inconsistenties in straatnamen die geografisch dicht bij elkaar liggen (bv. een ‘rue Roi Albert I‘ naast een ’rue du Roi Albert I’);
• In de vierde zoeken we naar geometrische afwijkingen in de vorm van een straat.

Inconsistentie van bussen

Zoals eerder beschreven bevat een adres altijd een ‘huisnummer’, dat verwijst naar het gebouw, en soms een ‘ busnummer’, dat verwijst naar de wooneenheid binnen dat gebouw. In BeSt Address vinden we voor elk adres met een bus altijd een gelijkwaardig basisadres (zelfde straat, postcode, nummer) zonder bus. Laten we bijvoorbeeld zeggen dat de Fonsnylaan 20 twee bussen heeft, ‘bus 1’ en ‘bus 2’: we vinden drie items in BeSt Address: ‘Fonsnylaan 20’; ‘Fonsnylaan 20 bus 1’ en ‘Fonsnylaan 20 bus 2’. 

Voor elk adres (straat, postcode, nummer) hebben we gecontroleerd of de coördinaten die bij de bussen horen niet abnormaal ver uit elkaar liggen. In de overgrote meerderheid van de gevallen hebben de verschillende bussen met hetzelfde nummer allemaal dezelfde coördinaten, maar dit is niet altijd het geval.

Voor elk adres met busnummers schetsen we de ‘minimum rotated rectangle’ , d.w.z. de rechthoek met de minimale oppervlakte die alle punten omvat (de coördinaten van het ‘basis’-adres, voorgesteld door ‘/’, en die van elk van de bussen), waarbij elke rotatie van de rechthoek mogelijk is. Zo’n rechthoek die twee punten omvat zal een breedte van nul hebben en een lengte gelijk aan de afstand tussen de punten. In het geval van meerdere niet-uitgelijnde punten zullen beide afmetingen positief zijn.

De anomalieën werden voornamelijk gedetecteerd in Vlaanderen, met meer dan 100 gevallen. In Wallonië zijn de coördinaten van de verschillende bussen steeds gelijk aan de coördinaten van het basisadres. In Brussel werden slechts twee afwijkingen vastgesteld.

Om dit te illustreren nemen we twee voorbeelden, weergegeven in de figuur hieronder. Het eerste voorbeeld (Abdijstraat, 41 te 9140 Stekene) toont aan dat het basisadres (Abdijstraat, 41, voorgesteld door een ‘/’) zich op 11 kilometer van Abdijstraat, 41 bus 12 bevindt. We vonden bijna honderd zeer vergelijkbare voorbeelden.

Het tweede is een gevolg van het probleem dat in ons vorige artikel werd geïllustreerd: om adressen tussen ‘1’ en ‘3’ te maken, kun je ze maken met huisnummers ‘1A’, ‘1B’, ‘1C’… (zonder busnummer), of ze allemaal ‘nummer 1’ noemen, maar met een busnummer ‘A’, ‘B’, ‘C’… In de ‘Diamantstraat’ in Diksmuide is (ongetwijfeld per ongeluk) een hybride keuze gemaakt: naast de 1 vinden we ‘1A’, ‘1B’, … ‘1F’, dan … ‘1 bus G’! Dit creëert een grote afstand tussen de 1 (basisadres) en de 1 (bus G).

Postgrenzen

In deze analyse vergelijken we de door bpost gedefinieerde postcodegrenzen. Om dit te doen, kijken we voor elk BeSt-adres in welke bpost-polygoon het valt en selecteren we de adressen waarvoor er een inconsistentie is tussen de BeSt-postcode en de bpost-postcode.

Om nauwkeurigheidsproblemen van een punt dat precies op de grens ligt te voorkomen, verwijderen we een strook van 50 meter uit de contouren in de postcodes die door bpost zijn gedefinieerd. Een inconsistentie wordt daarom slechts geïdentificeerd wanneer een adres in een P1 postcode (volgens BeSt) eigenlijk in de polygoon van een P2 postcode (volgens bpost) ligt, met P1 ≠ P2.

In de onderstaande afbeeldingen kunnen we enkele van de geïdentificeerde voorbeelden zien. De rode lijn stelt de grens voor die overeenkomt met de postcode in kwestie, volgens bpost (6700 voor het hoofdvoorbeeld). Binnen deze lijn bevinden zich een groot aantal BeSt-adressen die bij dezelfde postcode horen. Deze adressen worden hier niet getoond om het beeld niet te overladen. De gekleurde stippen buiten de rode omlijning zijn dus adressen die BeSt associeert met de code in de titel, maar die volgens het postkantoor de postcode hebben uit de legende (6704 in het blauw, 6706 in het oranje voor de 1^e voorbeeld).

Merk op dat de geregistreerde ‘uitwisselingen’ altijd binnen dezelfde gemeente liggen (Aarlen voor het voorbeeld). Terwijl BeSt ervan uitgaat dat alle adressen in de gemeente Aarlen op 6700 liggen, gaat bpost er wel van uit dat een deel van het grondgebied op 6704 (Guirsch) of 6706 (Autelbas-Barnich) ligt, twee postcodes die BeSt niet kent.

Dit is niet alleen een kwestie van een bestand (Shapefile) dat niet up-to-date is op de website van de Post: de online adresvalidatietool van bpost is consistent met de getoonde postcodes.

Tijdens sommige gesprekken kregen we te horen dat gemeenten de vrijheid hebben om de toewijzing van postcodes op hun grondgebied te wijzigen. Hierover bestaat echter geen consensus: in de “Gids voor het vaststellen en toekennen van adressen”, staat dat “Postcodes en hun systematisering zijn echter eigendom van de dienstverlener van de universele postdienst, in voorkomend geval (…) bpost. Ze kunnen alleen worden toegekend en gewijzigd op basis van een voorstel van bpost en na een gemotiveerd advies van het BIPT en de goedkeuring van de minister overeenkomstig artikel 135 van de wet van 21 maart 1991. (Artikel 22)”.

We troffen iets meer dan 8000 anomalieën aan in Wallonië (op een totaal van 1,85 miljoen relevante adressen), ~ 11 000 in Vlaanderen (op 3,83 miljoen) en een marginaal aantal in Brussel (op 860 000). Merk op dat sommige afwijkingen aanvaardbaar zijn, zoals gebouwen (kastelen, boerderijen, enz.) die ver van de voordeur liggen. BeSt lokaliseert het gebouw, maar de postcode komt overeen met die van de ingang.

Inconsistentie van namen

Voor deze analyse gaan we een ‘klassieke’ benadering op basis van karakterketen combineren met een geografische benadering. We starten met het identificeren van de lijst van alle paren van aangrenzende straten (d.w.z. de ene heeft een adres op minder dan 100 meter van de andere). Vervolgens controleren we op kleine verschillen in straatnamen. We zien meestal twee situaties:

• Straten die verschillende gemeenten doorkruisen en in elke gemeente een andere schrijfwijze hebben: ‘Rue de Monténégro, 1060’, vs ‘Rue du Monténégro, 1190’;
• Straten met twee verschillende schrijfwijzen binnen dezelfde gemeente: ‘Chaussée Brunehault’ of ‘Chaussée Brunehaut’, in 4452 in beide gevallen.

Er zijn ook een paar fout-positieven: ‘Rue de Mars’ vs ‘Rue de Mai’. We schrappen namen uit onze vergelijkingen die identiek zijn op een geïsoleerde laatste letter na (“Hensellaan A” vs “Hensellaan B”), evenals namen waarbij slechts een cijfer verandert (‘5de Zijweg’ vs ‘6de Zijweg’).

Met betrekking tot de eerste situatie, waarbij de naam verandert wanneer men van de ene gemeente naar de andere gaat, is het betreurenswaardig dat er een gebrek aan consistentie is, wat in strijd is met artikel 5 van de hierboven beschreven richtlijn, waarin staat dat “[a]ls een weg zich uitstrekt over het grondgebied van meerdere gemeenten en die weg dezelfde naam behoudt, dan moeten die gemeenten erop toezien dat de spelling van die straatnaam in alle betrokken gemeenten dezelfde is”. De richtlijn is echter niet bindend, gemeenten kunnen dus een eigen spelling behouden.

Het is echter de moeite waard om je af te vragen of de spelling die in BeSt wordt gebruikt (zoals doorgegeven door de gemeenten) echt de juiste is. Bijvoorbeeld, ‘Rue Walckiers’ in 1030 Schaarbeek is een uitbreiding van ‘Rue Walkiers’ in 1140 Evere. Het (enige) Schaarbeekse bord voor deze straat schrijft het echter als … ‘Rue Walkiers’! Hetzelfde geldt voor het (kleine) deel van de Tervuerenlaan in Oudergem, dat als dusdanig gespeld wordt in Sint-Pieters-Woluwe en op de straatnaambordjes in Oudergem, maar in Oudergem vermeld staat als ‘Tervurenlaan’. Er zijn nog veel meer voorbeelden.

De situatie waarin, binnen dezelfde gemeente, soms zelfs voor dezelfde postcode, twee straatsecties niet op dezelfde manier worden gespeld, is een duidelijke indicatie van een probleem met de kwaliteit van de gegevens. We hebben tientallen van dergelijke gevallen geïdentificeerd, voornamelijk in Wallonië, en noemen er hier slechts enkele ter illustratie. 

Inconsistente geometrie

Hier bekijken we de geometrische vorm die bestaat uit de opeenvolging van punten van adressen met dezelfde pariteit, voor dezelfde straat en postcode. Vervolgens berekenen we een aantal metrieken op deze lijn, ervan uitgaande dat de hoogste waarden duiden op een afwijking.

We hebben op experimentele basis een aantal metrieken gedefinieerd. We zullen er slechts twee nader toelichten waarvan we vonden dat ze het meest relevant waren voor de analyse. In een diepgaande analyse moeten ze echter worden gecombineerd met andere: 

• delta_ratio: voor elk paar adressen in dezelfde straat en van dezelfde pariteit berekenen we de verhouding van het verschil tussen het numerieke deel van de huisnummers en de afstand. Een hoge waarde geeft aan dat twee huizen met zeer verschillende huisnummers abnormaal dicht bij elkaar liggen. Dit is vaak te verklaren door twee verschillende fenomenen:
  • Normale situatie: een “cirkelvormige” straat, waarin het laatste nummer naast het eerste staat,
  • Abnormale situatie: op de hoek tussen twee straten is een gebouw toegewezen aan de verkeerde straat. Of, meer algemeen, een inversie tussen twee nummers;
• prev_to_prev²_ratio: over het algemeen wordt verwacht dat een getal dichter bij het volgende getal (van dezelfde pariteit) ligt dan het getal dat daarop volgt. Indien nummer 2 veel dichter bij nummer 6 ligt dan bij nummer 4, is het waarschijnlijk dat nummer 4 op de verkeerde plaats staat. Hier berekenen we de ratio tussen de afstand tussen een nummer en het vorige nummer (bijvoorbeeld tussen 4 en 6) en de afstand tussen dat nummer en het nummer ervoor (bijvoorbeeld tussen 2 en 6). Een waarde van 100 geeft dus aan dat een getal (aangegeven met een ‘hn:…’ in de titel van de grafiek) 100 keer dichter bij twee nummers achter ligt dan bij het vorige nummer.

De eerste metriek zal adressen uitlichten die zich in de juiste straat bevinden, maar niet op de juiste plaats. De tweede geeft adressen aan die ver verwijderd zijn van andere nummers in dezelfde straat.

In de volgende illustraties zijn de stippen opeenvolgend gekleurd volgens de numerieke waarde van het huisnummer, gaande van paars voor de laagste waarde tot geel voor de hoogste. Een lijn verbindt deze stippen in numerieke volgorde. 

De analyse van deze anomalieën moet vaak van geval tot geval worden bekeken, om te bepalen of het om een duidelijke fout gaat of om de weerspiegeling van een enigszins ongebruikelijke bepaling. Dit werk kan enkel uitgevoerd worden door de lokale overheden, die de informatie doorgeven aan de gewesten en vervolgens aan het FOD BOSA.

Het slotwoord

De code (Python-notebook) waarmee we al deze anomalieën hebben geïdentificeerd, is beschikbaar op Github en biedt een interactieve weergave van alle kaarten die hierboven zijn gepresenteerd. Het is niet aan ons om voor elk van de anomalieën te bepalen of het werkelijk een fout is (er zullen veel fout-positieven zijn), en zo ja, op welk niveau het zich voordoet: de gemeente, de consolidatie door de regio’s of het FOD BOSA, bpost, het straatnaambord, enz. 

Bovendien blijft het aantal probleemgevallen klein in vergelijking met de 6,5 miljoen adressen in BeSt Address. Toch vonden we de methodologie interessant genoeg om te publiceren. Ze zou ook kunnen worden toegepast op andere datasets, zoals OpenStreetMap of andere open bronnen.

Hoe een databank ook wordt gevuld, er sluipen altijd fouten in. De gewesten en de FOD BOSA verrichten al bergen werk om ervoor te zorgen dat de gegevens van zeer hoge kwaliteit zijn. Het zal echter altijd mogelijk zijn om nieuwe problemen op te sporen. Met dit artikel hopen we zelf een klein steentje bij te dragen.

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.

La gestion de la qualité de données (Data Quality), régulièrement abordée dans ce blog, consiste souvent à traiter (comparer, simplifier, transformer, “phonétiser”…) des chaînes de caractères : des noms de personnes, d’entreprises, de villes, de rues, numéros de téléphones, adresses email…

Dans cet article, nous allons considérer le genre de problèmes que l’on peut détecter lorsque les données sont associées à des coordonnées géographiques (latitudes, longitudes), en considérant les données ouvertes du projet “BeSt Address” (pour “Belgian Street Address”), du SPF BOSA (Service Public Fédéral Stratégie & Appui), source authentique des adresses en Belgique. Ce projet agrège et consolide les données des régions (UrbiS pour la région bruxelloise, le Adressenregister pour la Flandre et ICAR pour la Wallonie), qui elles-mêmes récupèrent les données d’adresses collectées par chaque commune, autorité responsable de l’attribution des adresses. On peut y télécharger une série de fichiers CSV ou XML, permettant, pour chaque adresse en Belgique, d’en connaitre l’orthographe officielle ainsi que les coordonnées géographiques.

Notre expérience nous a montré que les données des BeSt Address sont de loin les données de la meilleure qualité par rapport à d’autres sources officielles contenant des adresses (Registre national, Répertoire des employeurs, Banque Carrefour des Entreprises…), à tout le moins sur les aspects classiques de la qualité de données (cohérence des noms, absence d’abréviation…), résultat de l’énorme travail réalisé par les équipes des régions et du SPF BOSA. Néanmoins, nous avons pu y trouver un certain nombre d’anomalies identifiables uniquement en considérant les données géographiques et des analyses spatiales.

Les anomalies identifiées correspondent en grande majorité à des adresses mal placées (mauvaises coordonnées), ou à des codes postaux problématiques. Le nettoyage ne pourra être fait que par les entités sur le terrain, à savoir les communes.

Notons que les anomalies présentées ci-dessous sont issues d’une analyse “académique”. Celle-ci a déjà été discutée avec un certain nombre de personnes des instances concernées (régions, registre national, SPF BOSA, IGN…), et certaines de ces anomalies sont considérées comme acceptables. Le but de cet article n’est pas de critiquer la qualité des données, mais simplement de présenter une méthodologie, en l’illustrant avec une source de données pertinentes.

Contexte

Comme déjà expliqué dans un article précédent, la Belgique est composée, à l’heure d’écrire ces lignes, de 581 communes (ce nombre diminuera dans les prochains mois, suite à une série de fusions de communes). Chacune de celles-ci est composée d’un ou plusieurs codes postaux (associés à un nom à Bruxelles et en Flandre), et chacun de ces codes postaux peut contenir une ou plusieurs sous-communes, ou localités (part of municipality en Wallonie, dans le jargon BeSt Address).

Pour l’analyse ci-dessous, nous sommes partis des fichiers CSV disponibles sur https://opendata.bosa.be/, et avons mené quatre types d’analyse : 

• Dans la première, nous regardons si tous les numéros de boite d’une même adresse sont bien localisés proches les uns des autres ;
• Dans la deuxième, nous comparons les frontières des codes postaux définis par bpost (la poste belge) avec les codes postaux des adresses BeSt Address ;
• Dans la troisième, nous recherchons des incohérences sur des noms de rues géographiquement proches (par exemple une “Rue Roi Albert I” juste à côté d’une “Rue du Roi Albert I”) ;
• Dans la quatrième, nous recherchons des anomalies géométriques dans la forme d’une rue.

Incohérence de boites

Comme détaillé précédemment, une adresse contient toujours un “numéro de police”, ou numéro de maison, qui désigne le bâtiment, et, parfois, un “numéro de boite”, qui désigne l’unité d’habitation au sein de ce bâtiment. Dans BeSt Address, pour chaque adresse avec une boite, nous trouvons toujours une adresse équivalente de base (même rue, code postal, numéro) sans boite. Imaginons qu’au 20 de l’avenue Fonsny, on trouve deux boites, “boite 1” et “boite 2” : on trouvera trois items dans BeSt Address : “Avenue Fonsny 20” ; “Avenue Fonsny 20 boite 1” et “Avenue Fonsny 20 boite 2”. 

Nous avons regardé pour chaque adresse (rue, code postal, numéro) si les coordonnées associées aux boites ne sont pas anormalement éloignées. Dans une grande majorité des cas, les différentes boites d’un même numéro auront toutes les mêmes coordonnées, mais ça n’est pas toujours le cas.

Pour chaque adresse ayant des numéros de boite, nous construisons pour ce faire le “rectangle orienté minimum” (minimum rotated rectangle), à savoir le rectangle de surface minimale englobant l’ensemble des points (les coordonnées de l’adresse “de base”, représentée par “/”, ainsi que celles de chacune des boites), en autorisant toute rotation du rectangle. Un tel rectangle englobant deux points aura une largeur nulle et une longueur équivalente à la distance entre les points. En cas de points multiples non alignés, les deux dimensions seront positives.

Les anomalies ont essentiellement été détectées en Flandre, avec plus de 100 cas. En Wallonie, les coordonnées des différentes boites sont toujours égales aux coordonnées de l’adresse de base. À Bruxelles, seules deux anomalies ont été détectées.

Pour illustrer ceci, prenons deux exemples, représentés dans la figure ci-dessous. Le premier exemple (Abdijstraat, 41 à 9140 Stekene) montre que l’adresse de base (Abdijstraat, 41, représenté par un “/”) est située à 11 kilomètres de Abdijstraat, 41 bus 12. Nous avons trouvé près d’une centaine d’exemples très similaires.

Le second est une conséquence du problème illustré dans notre article précédent : pour créer des adresses entre le “1” et le “3”, on peut soit créer les numéros de maison “1A”, “1B”, “1C”… (sans numéro de boite), soit toutes les appeler “numéro 1”, mais avec un numéro de boite “A”, “B”, “C”… Dans la “Diamantstraat” à Dixmude, un choix hybride (sans doute par erreur) a été fait : à côté du 1, on retrouve bien le “1A”, “1B”, … “1F”, puis … “1 boite G” ! Ceci génère une grande distance entre le 1 (adresse de base) et le 1 (boite G). 

Frontières postales

Dans cette analyse, nous comparons les frontières des codes postaux définies par bpost. Pour ce faire, pour chaque adresse de BeSt, nous regardons dans quel polygone de bpost elle tombe et on retient celles pour lesquelles il y a une inconsistance entre le code postal de BeSt et celui de bpost.

Pour éviter les problèmes de précision d’un point qui serait juste à la frontière, on supprime un ruban de 50 mètres des contours dans les codes postaux définis par bpost . On identifie donc une inconsistance uniquement quand une adresse d’un code postal P1 (selon BeSt) est réellement dans le polygone d’un code postal P2 (selon bpost), avec P1 ≠ P2.

Dans les images ci-dessous, on peut voir quelques-uns des exemples identifiés. La ligne rouge représente la limite correspondant au code postal en titre, selon bpost (6700 pour l’exemple principal). À l’intérieur de cette ligne sont localisées un grand nombre d’adresses de BeSt, associées au même code postal, que nous ne représentons pas ici pour ne pas surcharger l’image. Les points de couleurs en dehors du contour rouge sont donc des adresses que BeSt associe au code en titre, mais qui, selon la poste, sont du code postal indiqué dans la légende (6704 en bleu, 6706 en orange pour le 1er exemple).

Notons que les “échanges” relevés se font toujours au sein d’une même commune (Arlon pour l’exemple). Mais alors que BeSt considère que toutes les adresses de la commune d’Arlon sont sur 6700, bpost considère qu’une partie du territoire est sur 6704 (Guirsch) ou 6706 (Autelbas-Barnich), deux codes postaux inconnus de BeSt.

Il ne s’agit pas uniquement d’une question d’un fichier (Shapefile) qui ne serait pas à jour sur le site de bpost : l’outil en ligne de validation d’adresse de bpost est bien cohérent avec les codes postaux présentés.

Lors de certaines discussions, il nous a été répondu que les communes avaient la liberté de modifier, au sein de leur territoire, l’attribution des codes postaux. Mais il n’y a pas de consensus là-dessus : dans le “Guide en matière de constatation et attribution d’adresses“, il est dit que “(…) les codes postaux et leur systématisation sont la propriété du prestataire du service postal universel, en l’occurrence (…) bpost. Ils ne peuvent être attribués et modifiés que sur proposition de bpost, et après avis motivé de l’IBPT et l’approbation du ministre conformément à l’article 135 de la loi du 21 mars 1991. (Article 22)”.

Nous avons trouvé un peu plus de 8.000 anomalies en Wallonie (sur un total de 1.85 M adresses pertinentes), ~11.000 en Flandre (sur 3.83 M), et un nombre marginal à Bruxelles (sur 860.000). Notons que certaines anomalies sont acceptables, comme par exemple le cas de bâtiments (château, ferme…) loin de la porte d’entrée. BeSt localise le bâtiment, mais son code postal correspond à celui de son entrée.

Incohérence de noms

Pour cette analyse, nous allons combiner une approche “classique” basée sur des comparaisons de chaînes de caractères, et une approche géographique. Nous commençons par identifier la liste de tous les couples de rues adjacentes (c’est-à-dire que l’une a une adresse distante de moins de 100 mètres d’une adresse de l’autre). On regarde ensuite si l’on ne trouve pas de petites différences dans les noms de rue. Nous rencontrons typiquement deux situations :

• Des rues traversant plusieurs communes avec une orthographe différente dans chacune d’elle : “Rue de Monténégro, 1060″, vs “Rue du Monténégro, 1190″ ;
• Des rues avec deux orthographes différentes au sein de la même commune : “Chaussée Brunehault” ou “Chaussée Brunehaut“, à 4452 dans les 2 cas.

On trouvera également quelques faux positifs : “Rue de Mars” vs “Rue de Mai”. On élimine de nos comparaisons les noms identiques à part une dernière lettre isolée (“Hensel laan A” vs “Hensel laan B”), ainsi que les noms où seul un chiffre change (“5de Zijweg” vs “6de Zijweg”).

Concernant la première situation, où le changement de nom arrive au passage d’une commune à l’autre, on peut regretter le manque de cohérence qui va à l’encontre de l’article 5 de la directive décrite plus haut, qui dit que “[d]ans l’hypothèse où une voie s’étend sur le territoire de plusieurs communes, et que cette voie garde le même nom, ces communes doivent s’assurer que l’orthographe de ce nom de rue soit identique dans toutes les communes concernées”. La directive n’est cependant pas contraignante, les communes sont donc libres de garder leur orthographe propre.

Il est cependant pertinent de se demander si l’orthographe présente dans BeSt (transmise par les communes) est réellement la bonne. On peut par exemple citer la “Rue Walckiers” à 1030 Schaerbeek, qui prolonge la “Rue Walkiers” à 1140 Evere. Or, la (seule) plaque schaerbeekoise de la rue l’orthographie … “Rue Walkiers” ! Il en va de même pour la (petite) portion auderghemoise de l’avenue de Tervueren, orthographiée comme telle à Woluwé-Saint-Pierre, ainsi que sur les plaques de rue à Auderghem, mais reprise dans BeSt comme “Avenue de Tervuren” à Auderghem. Nous pourrions citer bien d’autres exemples.

La situation où, au sein d’une même commune, parfois même pour un même code postal, deux portions de rue n’ont pas la même orthographe, dénote de façon plus évidente d’un problème de qualité de données. Nous en avons identifié des dizaines, principalement en Wallonie, nous n’en reprenons ici que quelques-uns pour illustration. 

Géométrie incohérente

Nous considérons ici la forme géométrique composée de la séquence de points des adresses de même parité, pour une même rue et un même code postal. Sur cette ligne, nous calculons ensuite un certain nombre de métriques, en supposant que les valeurs les plus élevées dénotent d’une anomalie.

Nous avons défini de façon expérimentale un certain nombre de métriques. Nous allons juste en détailler deux qui nous ont paru les plus pertinentes à l’analyse. Mais dans une analyse approfondie, il conviendra de les combiner avec d’autres : 

• delta_ratio : pour chaque couple d’adresses d’une même rue et de même parité, on calcule le ratio de la différence entre la partie numérique des numéros de maison et la distance. Une valeur élevée indique que deux maisons de numéros très distants sont anormalement proches. Ceci s’explique souvent par deux phénomènes distincts :

  • Situation normale : une rue “circulaire”, dans laquelle le dernier numéro se situe à côté du premier,

  • Situation anormale : sur le coin entre deux rues, un bâtiment a été assigné à la mauvaise rue. Ou plus généralement, une inversion entre deux numéros ;

• prev_to_prev²_ratio : on s’attend en général à ce qu’un numéro soit plus proche du numéro suivant (de même parité) que de celui d’encore après. Si le numéro 2 est beaucoup plus proche du 6 que du 4, il est probable que le 4 soit mal placé. On calcule ici le ratio de la distance d’un numéro au numéro précédent (par ex. entre 4 et 6) sur la distance entre ce numéro et celui qui précède le précédent (par ex. entre 2 et 6). Une valeur de 100 indique donc qu’un numéro (indiqué un ‘hn:…’ dans le titre du graphique) est 100 fois plus proche de deux numéros en arrière que du numéro précédent.

La première métrique mettra en évidence des adresses qui ont été localisées dans la bonne rue, mais pas au bon endroit. La seconde fera ressortir des adresses qui ont été localisées très loin des autres numéros de la même rue.

Dans les illustrations suivantes, les points sont colorés séquentiellement selon la valeur numérique du numéro de police, allant de mauve pour la plus petite valeur à jaune pour la plus grande. Une ligne relie ces points dans l’ordre numérique. 

L’analyse de ces anomalies nécessite souvent une attention au cas par cas, pour savoir s’il s’agit d’une erreur manifeste, ou du reflet d’une disposition un peu particulière. Ce travail ne peut être fait que par des instances de terrain, à savoir les communes, qui transmettent ces informations aux régions puis au SPF BOSA.

Le mot de la fin

Le code (notebook Python) qui nous a permis d’identifier toutes ces anomalies est disponible sur Github, et permet entre autres une vue interactive de toutes les cartes présentées ci-dessus. Pour chacune des anomalies, il ne nous revient pas de déterminer s’il s’agit réellement d’une erreur (il y aura beaucoup de faux positifs), et, le cas échéant, à quel niveau elle se situe : la commune, la consolidation par les régions ou le SPF BOSA, bpost, la plaque de rue… 

Par ailleurs, le nombre de cas problématiques reste faible par rapport aux 6,5 millions d’adresses que contient BeSt Address. Mais la méthodologie nous paraissait suffisamment intéressante pour la publier. On pourrait par ailleurs l’appliquer à d’autres jeux de données, comme par exemple OpenStreetMap, ou d’autres sources ouvertes.

Quelle que soit la façon dont est alimentée une base de données, des erreurs s’y introduisent. Les régions et le SFP BOSA font déjà un travail considérable pour garantir des données d’une très bonne qualité. Mais il sera toujours possible de détecter des nouveaux problèmes. Par cet article, nous espérons apporter notre modeste contribution à l’édifice.

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.

Vaak denken we dat we om een gebouw te lokaliseren (in België, maar onze buren ervaren een zeer gelijkaardige situatie) we een adres nodig hebben dat bestaat uit een straatnaam (die eindigt in het Nederlands met ‘…straat’, ‘…laan’, ‘…steenweg’, of die in het Frans begint met ‘Rue…’, ‘Avenue…’, ‘Chaussée…’, of een gelijkaardige prefix/suffix). Vervolgens komt er een nummer, even aan een kant van de straat, oneven aan de andere. Als we een gebouw zetten tussen ‘10’ en ‘12’, krijgt dit het nummer ‘10A’, en als nummer 10 een gebouw is met meerdere appartementen dan onderscheiden we ze met ‘10 bus 1’, ‘10 bus 2’, enz. (of 10/1, 10/2, enz.). We moeten ook een gemeente vermelden, samen met de postcode van 4 cijfers (5 in Frankrijk). Hiermee zou de postbode jouw brievenbus met gemak moeten vinden.

Hoewel dit inderdaad zo is voor de meeste adressen, is de realiteit spijtig genoeg vaak veel ingewikkelder. We hebben al meerdere keren vermeld dat databases informatie kunnen bevatten die niet overeenstemt met de werkelijkheid, wat geocodering kan bemoeilijken. In dit artikel tonen we aan dat de realiteit vaak in strijd is met het gezond verstand! En als een realiteit niet coherent is, dan bemoeilijkt dat duidelijk het gegevensbeheer ervan.

Er bestaan “Richtlijnen en aanbevelingen voor het vaststellen en toekennen van een adres (…)” (richtlijn – gids). Het probleem is dat deze niet altijd worden nageleefd. Bovendien werden de meeste straten en nummers toegekend voordat deze richtlijnen werden opgesteld.

Straatnamen

In Franstalig België dekken de 10 belangrijkste prefixen (in volgorde van voorkomen): Rue, Chemin, Avenue, Place, Clos, Route, Allée, Chaussée, Ruelle, Impasse) slechts 85% van de (62 000) straatnamen. In de overige 15% zien we enkele grote klassiekers (Drève: 0,4%, Boulevard: 0,3%, Square: 0,2%) maar ook talloze straatnamen die we moeilijk zouden kunnen onderscheiden van een plaatsnaam. Iets meer dan 2000 (3%) straatnamen bestaan uit een enkel woord (zoals “Dries” in Watermaal-Bosvoorde; niet te verwarren met de “Driesstraat” in Sint-Lambrechts-Woluwe); 1000 beginnen met een determinator (bijvoorbeeld “La Chapelle“, en niet een van de 160 “Rue” of “Avenue de la Chapelle”, of “La Chavée” in plaats van een van de 35 varianten van “Rue de la Chavée”). Deze laatste gevallen worden echter sterk afgeraden door artikel 8 §4 (“Straatnamen zonder type weg worden ten stelligste afgeraden”) van de hierboven vermelde richtlijn.

Aan de Nederlandstalige kant (Vlaanderen en Nederlandstalige straatnamen in Brussel) is de situatie vergelijkbaar: de top 10 suffixen (straat, laan, weg, dreef, plein, steenweg, baan, hof, veld, berg) vertegenwoordigen slechts 82% (88 000) van de straatnamen. We zien daarna een groot aantal namen met plaatsnamen (Dorp, Tuinwijk, Warande, enz.). We hebben 26 keer “Vogelzang” naast 35 keer “Vogelzangstraat” en andere “laan” of “dreef”. 

Een ding is zeker: de 581 Belgische gemeentes, die instaan voor de toekenning van de straatnamen, hebben verbeelding in overvloed! Om nog maar te zwijgen van de gemeenten die op het lumineuze idee zijn gekomen om kruisende straten bijzonder gelijkaardige namen te geven: in Bièvre kruist de “Rue de la Violette” de “Rue de la Volette”; in veel Vlaamse gemeenten kruist de “Berkenlaan” de “Beukenlaan”; in Raeren loopt de Burgstraße in het verlengde van de Bergstraße. En als we kijken naar straten die dicht bij elkaar liggen maar elkaar niet noodzakelijkerwijs kruisen, hebben we Ange/Angle (Charleroi), Carrière/Barrière (Serain), Ateliers/Bateliers (Châtelet), Beek/Beuk (Ternat), Hekel/Herel (Aalter), enz.
Schrijf dus netjes op je enveloppen – de postbode zal je dankbaar zijn! Het is geen verrassing meer als de bezorger (of nog erger, de ziekenwagen!) af en toe in de verkeerde straat aankomt…

De richtlijn over de toewijzing van adressen vraagt echter om  “straten met namen waarvan slechts één letter verschillend is” (8§5) te vermijden.

We zien zelfs een bijzonder interessante situatie: in Charleroi heeft de rechterkant van een straat (Rue de Monseau) niet dezelfde naam als de linkerkant (Rue des chèvres)! Hoewel er een beslissing is genomen om te standaardiseren, zal het zeker nog enkele maanden of jaren duren voordat de cartografische en officiële gegevens gealigneerd zijn.

Huisnummers

Helaas is er geen standaard voor het nummeren van huizen in een straat. Er wordt vaak onderscheid gemaakt tussen het nummer van het huis (in de richtlijn het “huisnummer” genoemd, dat meestal verwijst naar de ingang van het gebouw) en het “busnummer” (dat verwijst naar de verdieping, vleugel, blok, enz.). Als een adres een “5A” bevat, is het niet mogelijk, tenzij je ter plaatse bent of de plaats kent, om te weten of het een huis is dat naast 5 is gebouwd (in welk geval, nummer = 5A), of appartement A van nummer 5 (nummer = 5, bus = A). Hetzelfde geldt voor 5/1. Met andere woorden, we weten niet of het 5, 5A of 5/1 is dat de ingang van het gebouw aanduidt. Er zijn veel situaties waarin een ommuurde ruimte is gebouwd in plaats van een huis. Hoe de nieuwe huizen worden genummerd hangt af van de welwillendheid en verbeeldingskracht van de gemeente: :

• Op Clos du Manoir 13, in Limal, hebben de nieuwe huizen de nummers 13/1, 13/2, …, 13/17.  Er is geen busnummer, de “/x” maakt integraal deel uit van het nummer en niet van de bus.
• Het nummer 1517 van de Waversesteenweg in Ouderghem koos voor letters: 1517A, 1517B…, tot 1517P
• Op Dieweg nummer 54 besloot Ukkel dat de ongeveer twintig nieuwe woningen hetzelfde huisnummer zouden krijgen, maar een busnummer tussen 1 en 20.

Merk op dat de verdeling nummer/bus die hier wordt gepresenteerd die is van BeSt Address, die de officiële informatie van de gemeenten samenbrengt (hoewel niet vrij van kwaliteitsproblemen, daar komen we in een later artikel op terug). Ze komt echter niet altijd overeen met de verdeling die wordt aangegeven door geocoders zoals OpenStreetMap, Here WeGo of Google Maps.

Maar daar houdt het gebrek aan samenhang niet op: naast nummer 10 vind je 10 A, 10/2, maar ook 10 bis. En als je 10 samenvoegt met zijn buurman 12, wordt het geheel vaak 10/12 (of 10-12) genoemd.

Het is dus niet in alle gevallen mogelijk om een ongestructureerd (of slecht gestructureerd) adres correct op te splitsen (of te parsen) in “nummer” en “bus”, tenzij je de juiste indeling van elk adres kent.

In de gegevens van BeSt Address, kunnen we het formaat van huisnummers bekijken door het ‘masker’ te bestuderen, dat bestaat uit het vervangen van elke reeks cijfers door een 0, en elke letter door een A. Het “0”-masker (1, 12, 1977, …) dekt 92,6% van de adressen en “0A” (1A, 5B, 23C …) 7%. In Brussel en Vlaanderen zijn er 5 verschillende maskers. Voor Wallonië … 73! Het is echter een veilige gok dat dit in veel gevallen ligt aan problemen met de gegevenskwaliteit.

Het gebrek aan uniformiteit in de busnummers is nog erger: er zijn meer dan 400 verschillende formaten! Waaronder 17 000 busnummers die uit een letter bestaan, moeilijk te onderscheiden van de hierboven genoemde huisnummers in het “0A”-formaat.

Volgens de richtlijn (16§4) moet een nummeruitbreiding in theorie worden aangeduid met een hoofdletter direct na het nummer (10A, niet 10/2, 10 bis of 10 A) en moet een busnummer numeriek zijn (19§6 en §7). Maar dit wordt duidelijk niet gevolgd door de feiten. We merken dat 99,6% van de BeSt Address huisnummers compatibel zijn met deze richtlijnen, maar slechts 69,8% van de busnummers.

Afgezien van het naamgevingsaspect is de plaatsing van nummers niet altijd consistent. Hoewel even nummers vaak aan de ene kant van de straat staan en oneven nummers aan de andere kant, lopen ze niet altijd allebei in dezelfde richting op.

De rue François Michoel in Jalhay heeft bijvoorbeeld alleen even nummers, met oplopende nummers aan de ene kant en aflopende nummers aan de andere kant (zie bovenstaande figuur, waar de blauwe lijn de nummers in oplopende volgorde volgt. Gebaseerd op gegevens van Best Address, met OpenStreetMap als achtergrondkaart). Deze lay-out is ook te vinden in bepaalde afgesloten gebieden, zoals de drève de Trévires in Waver of de Henri Wautierlaan in Saintes.

We kunnen ook het Dennenhof te Tessenderlo vermelden, een straat die bestaat uit verschillende ‘sectoren’, waaronder een met de nummers 2, 4, 6, …, en een andere met 2A, 4A, 6A, 8A … 8A ligt dus niet tussen de nummers 8 en 10, maar tussen de nummers 6A en 8A (idem voor de Begijnenwinning in dezelfde gemeente). 

De situatie in woningen met chalets of caravans is nog complexer: in het Tulderbos (Ravels), lijken de nummers volledig willekeurig te zijn getrokken (zie hiernaast) … arme postbode!

Postcode en gemeente

Zoals in een vorig artikel is beschreven, bestaat België op het moment van schrijven uit 581 gemeenten, die elk bestaan uit een of meer deelgemeenten. Elke deelgemeente heeft zijn eigen postcode, maar deze kan hetzelfde zijn voor elke deelgemeente van dezelfde gemeente, verschillend voor elke deelgemeente, of een mengeling van de twee.  Een postcode kan dus worden toegewezen aan een gemeente of aan haar deelgemeenten.

Het Brussels Hoofdstedelijk Gewest heeft echter enkele afwijkingen. Het bestaat uit 19 gemeenten, waarvan er 18 geen deelgemeenten hebben en één (Brussel-Stad) die er 4 heeft (Brussel, Laken, Haren en Neder-over-Hembeek). In de praktijk wordt de gemeente Sint-Gillis echter zowel “1060 Sint-Gillis” als “1060 Brussel” genoemd, net als alle andere Brusselse gemeenten. In geen enkele andere regio van België wordt een gemeente aangeduid met haar provincie of arrondissement. Elders wordt een gemeente aangeduid door de postcode te combineren met de naam van de deelgemeente (1301 Bierges) of met de naam van de gemeente (1301 Wavre).

Bovendien heeft de gemeente Brussel-Stad (of de Stad Brussel) in de loop van de 19e eeuw een aantal gebieden van naburige gemeenten geabsorbeerd, die daardoor onder het gezag van de Stad Brussel kwamen te vallen, maar waarvan de postcode die van de oorspronkelijke gemeente bleef. Zo valt het grootste deel van het gebied dat onder de Stad Brussel valt onder de postcodes 1000 (in het blauw op de kaart), 1020, 1120 en 1130 (de 4 deelgemeenten), een deel onder 1040 (Europese wijk, in het groen) en een deel onder 1050 (Louizalaan en Franklin Rooseveltlaan, in het grijs). Etterbeek bezit dus niet heel 1040 (alleen het bruine deel), en Elsene beheert niet heel 1050 (alleen het turkooizen deel, in twee gedeeld door de Louizalaan).

Conclusie

Smals Research besteedt veel tijd aan het bewustmaken van de complexiteit van het relevant houden van gegevens voor de echte wereld, zowel op deze blog als in onze projecten en opdrachten. In dit artikel illustreren we dat de werkelijkheid soms fundamenteel gecompliceerd is door het feit dat de nomenclatuur (namen van gemeenten, straten, toewijzing van nummers) wordt overgelaten aan de vrijheid van elke gemeente, met weinig beperkingen. Dit leidt tot de hier beschreven inconsistenties. Als je daar historische ontwikkelingen bij optelt, is het gemakkelijk om de brandweer naar het verkeerde adres te sturen!

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.

On pense souvent que pour localiser un bâtiment (en Belgique, mais la situation de nos voisins est très similaire), nous avons besoin d’une adresse, composée d’un nom de rue (qui commence en français par “Rue …”, “Avenue …”, “Chaussée …”, ou qui termine en néerlandais par “…straat”, “… laan”, “… steenweg”, ou un préfixe/suffixe similaire). Il faut ensuite un numéro, pair d’un côté de la rue, impair de l’autre. Si on construit un bâtiment entre le “10” et le “12”, on le numérotera “10A”, et si le 10 est un immeuble avec plusieurs appartements, on les distinguera par “10 boite 1”, “10 boite 2”, etc (ou 10/1, 10/2…). Il nous faudra également préciser une commune, associée à son code postal sur 4 chiffres (5 en France). Avec tout ceci, le facteur n’aura aucun mal à trouver votre boite aux lettres.

Malheureusement, si ceci est vrai pour une grande majorité des adresses, la réalité est parfois bien plus complexe. Nous avons déjà évoqué à plusieurs reprises le fait que les bases de données pouvaient contenir des informations en inadéquation avec la réalité, ce qui peut compliquer le géocodage. Dans cet article, nous allons montrer que la réalité est souvent en inadéquation avec le bon sens ! Et si une réalité manque de cohérence, cela compliquera clairement la gestion des données qui la représentent.

Il existe des “directives et recommandations pour la détermination et l’attribution des adresses (…)” (directive – guide), mais elles ne sont malheureusement pas toujours respectées. Par ailleurs, la plupart des rues et numéros ont été attribués avant ces directives.

Noms de rue

En Belgique francophone, les 10 principaux préfixes (dans l’ordre de fréquence : Rue, Chemin, Avenue, Place, Clos, Route, Allée, Chaussée, Ruelle, Impasse) ne couvrent que 85 % des (62.000) noms de rue. Dans les 15 % restant, on retrouve quelques grands classiques (Drève : 0,4 %, Boulevard : 0,3 %, Square : 0,2 %), mais également d’innombrables noms de rue que l’on aurait du mal à distinguer d’un lieu-dit. Un peu plus de 2000 (3 %) noms de rues ne sont composés que d’un seul mot (comme “Dries” à Watermael-Boitsfort ; à ne pas confondre avec la “Rue Dries” à Woluwé-Saint-Lambert); 1000 commencent par un déterminant (Par exemple “La Chapelle“, et non une des 160 “Rue” ou “Avenue de la Chapelle”, ou “La Chavée” au lieu d’une des 35 variantes de “Rue de la Chavée”). Ces derniers cas sont cependant fortement déconseillés par l’article 8§4 (“Les noms de voies sans type de voie sont à éviter”) de la directive évoquée plus haut.

Le constat est similaire côté néerlandophone (Flandre et dénominations néerlandophones des rues bruxelloises) : les 10 principaux suffixes (straat, laan, weg, dreef, plein, steenweg, baan, hof, veld, berg) ne concernent que 82 % des 88 000 noms de rue. On trouve ensuite une multitudes de noms à l’allure de lieux-dits (Dorp, Tuinwijk, Warande…). On aura 26 “Vogelzang” (chant d’oiseau) à côté des 35 “Vogelzangstraat” (Rue du chant d’oiseau) et autres “laan” ou “dreef”. 

Une chose est sûre : les 581 communes belges, responsables de l’attribution des noms de rues, font preuve d’une imagination sans limite ! Sans compter celles qui ont eu la délicieuse idée de donner des noms particulièrement proches à des rues qui se croisent : la “Rue de la Violette” croise, à Bièvre, la “Rue de la Volette” ; dans de nombreuses communes flamandes, la “Berkenlaan” (Avenue du bouleau) croise la “Beukenlaan” (Avenue du hêtre) ; la Burgstraße prolonge la Bergstraße à Raeren. Et si on considère des rues proches sans nécessairement se croiser, on aura des Ange/Angle (Charleroi), Carrière/Barrière (Serain), Ateliers/Bateliers (Châtelet), Beek/Beuk (Ternat), Hekel/Herel (Aalter), etc. Il s’agira de bien écrire sur vos enveloppes, le facteur vous en remerciera ! On ne sera pas surpris que le livreur (voire pire, l’ambulance !) arrive dans la mauvaise rue de temps à autre…

La directive sur l’attribution des adresses demande pourtant d’éviter (8§5) les “voies portant des noms qui ne se distinguent que par une seule lettre”.

On trouve même une situation particulièrement intéressante : à Charleroi, le côté droit d’une rue (Rue de Monseau) n’a pas le même nom que le côté gauche (Rue des chèvres) ! Une décision d’uniformisation a été prise, mais il faudra certainement quelques mois ou années avant que les données cartographiques et officielles soient alignées.

Numéros de maison

Il n’existe malheureusement aucun standard sur la façon de numéroter des maisons d’une rue. On distingue souvent le numéro de la maison (appelés “numéro de police” dans la directive, qui désigne en général l’entrée du bâtiment) et le “numéro de boite” (qui désigne l’étage, l’aile, le bloc…). Si dans une adresse on trouve un “5A”, il n’est pas possible, à moins d’être sur place ou de connaitre l’endroit, de savoir s’il s’agit d’une maison construite à côté du 5 (dans ce cas, numéro = 5A), ou de l’appartement A du numéro 5 (numéro = 5, boite = A). Il en va de même pour le 5/1. En d’autres mots, on ne sait pas si ce qui désigne l’entrée du bâtiment, c’est le 5, le 5A ou le 5/1. Il existe de nombreuses situations où un clos a été construit à la place d’une maison. La façon de numéroter les nouvelles maisons dépendra du bon-vouloir et de l’imagination de la commune :

• Au 13 du Clos du Manoir, à Limal, les nouvelles maisons ont comme numéro 13/1, 13/2, …, 13/17. Il n’y a pas de numéro de boite, les “/x” font intégralement partie du numéro et non de la boite
• Le 1517 de la chaussée de Wavre, Auderghem a plutôt choisi des lettres : 1517A, 1517B…, jusqu’à 1517P
• Au 54 de Dieweg, Uccle a décidé que la vingtaine d’habitations construites auraient le même numéro de maison, mais un numéro de boite entre 1 et 20.

Notons que la division numéro/boite présentée ici est celle que l’on retrouve dans BeSt Address, qui rassemble les informations officielles fournies par les communes (sans être toutefois exempts de problèmes de qualité, nous y reviendrons lors d’un prochain article). Mais elle ne correspond pas toujours à la répartition indiquée par les géocodeurs comme OpenStreetMap, Here WeGo ou autres Google Maps.

Mais le manque de cohérence ne s’arrête pas là : à côté du 10, on peut trouver le 10 A, le 10/2, mais également le 10 bis. Et si on fusionne le 10 et son voisin le 12, on dénommera souvent l’ensemble 10/12 (ou 10-12).

Il n’est donc pas possible, de décomposer (ou parser) correctement dans tous les cas une adresse non structurée (ou mal structurée) en “numéro” et “boite”, à moins de connaitre la décomposition correcte de chaque adresse.

Dans les données de BeSt Address, on peut s’intéresser au format des numéros de maison en étudiant le “masque”, qui consiste à remplacer toute séquence de chiffres par un 0, et toute lettre par un A. Le masque “0” (1, 12, 1977, …) couvre 92,6 % des adresses et “0A” (1A, 5B, 23C …) 7 %. À Bruxelles et en Flandre, on trouve 5 masques différents. Pour la Wallonie… 73 ! Il y a cependant fort à parier qu’il s’agit dans de nombreux cas de problèmes de qualité de données.

Le manque d’uniformité des numéros de boite est encore pire : on trouve plus de 400 formats différents ! Dont 17 000 boites composées d’une seule lettre, difficile à distinguer des numéros de maison au format “0A” évoqué ci-dessus.

En théorie, selon la directive, (16§4) une extension de numéro doit être dénommée par une lettre majuscule suivant directement le numéro (10A, pas de 10/2, 10 bis ou 10 A), et un numéro de boite doit être numérique (19§6 et §7). Mais cela n’est clairement pas suivi des faits. On observe que 99,6 % des numéros de police de BeSt Address sont compatibles avec ces directives, mais seulement 69,8 % des numéros de boite.

En dehors de l’aspect dénomination, le placement des numéros n’est pas toujours cohérent. Si on observe souvent les numéros pairs d’un côté de la rue et les numéros impairs de l’autre, ceux-ci ne sont pas toujours croissants dans la même direction.

La rue François Michoel, à Jalhay, n’a par exemple que des numéros pairs, avec les numéros croissants d’un côté, et décroissants de l’autre (voir illustration ci-dessus, où la ligne bleue suit les numéros dans l’ordre croissant. Selon les données de Best Address, avec OpenStreetMap en fond de carte). On retrouve également cette disposition dans certains clos comme la drève de Trévires à Wavre ou l’avenue Henri Wautier à Saintes.

On pourrait aussi citer la Dennenhof à Tessenderlo, rue composée de plusieurs “secteurs”, dont un avec les numéros 2, 4, 6, …, et un autre avec le 2A, 4A, 6A, 8A… Le 8A n’est donc pas entre le 8 et le 10, mais entre le 6A et le 8A (idem pour le Begijnenwinning dans la même commune). 

La situation dans les résidences à chalets ou caravanes est encore plus complexe : au Tulderbos (Ravels), les numéros semblent avoir été tirés complètement au hasard (voir ci-contre) … pauvre facteur !

Code postal et commune

Comme déjà expliqué dans un article précédent, la Belgique est composée, à l’heure d’écrire ces lignes, de 581 communes, chacune étant composée d’une ou plusieurs sous-communes, ou localité. Chaque sous-commune est associée à un code postal, mais celui-ci peut être identique pour chaque sous-commune d’une même commune, distinct pour chaque sous-commune, ou un mixe entre les deux.  On peut donc considérer qu’un code postal est attribué soit à une commune, soit à ses sous-communes.

La région de Bruxelles-Capitale comporte cependant quelques anomalies. Elle est composée de 19 communes, 18 n’ayant pas de sous-commune, et une (Bruxelles-ville) qui en a 4 (Bruxelles, Laeken, Haren et Neder-over-Hembeek). Dans la pratique, la commune de Saint-Gilles, par exemple, est dénommée indistinctement “1060 Saint-Gilles” ou “1060 Bruxelles”, comme toutes les autres communes bruxelloises. Dans aucune autre région de Belgique on ne désigne une commune par sa province ou son arrondissement. Ailleurs, on désigne une localité soit par la combinaison du code postal avec le nom de la localité (1301 Bierges), soit avec le nom de la commune (1301 Wavre).

Par ailleurs, la commune de Bruxelles-ville (ou ville de Bruxelles) a au cours du XIX^è siècle absorbé plusieurs territoires des communes voisines, qui relèvent donc de l’autorité de la ville de Bruxelles, mais dont le code postal est resté celui de la commune d’origine. Ainsi, si l’essentiel du territoire dépendant de la ville de Bruxelles est sur les codes postaux 1000 (en bleu sur la carte), 1020, 1120 et 1130 (les 4 sous-communes), une partie est sur 1040 (quartier Européen, en vert) et une partie est sur 1050 (Avenues Louise et Franklin Roosevelt, en gris). Etterbeek ne possède donc pas la totalité de 1040 (seulement la partie marron), Ixelles ne gère pas l’entièreté de 1050 (seulement la partie turquoise, coupée en deux par l’Avenue Louise).

En conclusion

Nous consacrons beaucoup de temps chez Smals Research, que ce soit sur ce blog ou lors de nos projets et missions, à sensibiliser sur la complexité de maintenir des données en adéquation avec le monde réel. Dans cet article, nous illustrons le fait que la réalité est parfois fondamentalement compliquée, à cause du fait que la nomenclature (noms des communes, des rues, attribution des numéros) est laissée à la liberté de chaque commune, sans beaucoup de contrainte. Ce qui mène aux aberrations que nous énonçons ici. Si l’on rajoute les évolutions historiques, on a vite fait, si l’on n’agit pas avec beaucoup de rigueur, d’envoyer les pompiers à la mauvaise adresse !

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.

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.

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.

Pour ce faire, nous allons récolter une série d’indicateurs à propos des 581 communes de Belgique, disponibles en open-source, sur https://statbel.fgov.be, https://data.belgium.be ou encore https://www.census2011.be.

Corrélation “classique”

Pour comprendre l’autocorrélation spatiale, il est nécessaire de d’abord bien saisir celui de corrélation statistique au sens “classique” du terme. Dans sa version de base (corrélation linéaire entre deux variables quantitatives), on peut évaluer visuellement la corrélation entre deux variables en les représentant sous forme de nuage de points (scatterplot). 

Prenons par exemple, pour chaque commune belge, d’une part le revenu brut moyen annuel (mean_income), et d’autre part, la proportion de la population avec un diplôme de l’enseignement supérieur (with_degree). Dans le graphique suivant, chaque point représente une commune, sa position sur l’axe vertical est donné par la première variable, celle sur l’axe horizontal par la seconde. 

On y observe une corrélation assez claire : plus un des indicateurs est élevé, plus l’autre a des chances de l’être également. Ceci est formalisé par le coefficient de Pearson, qui vaut ici 0.79, indicateur entre -1 et 1, valant 1 si la connaissance d’une valeur permet de déterminer exactement la valeur de l’autre, avec une relation croissante (-1 si la relation est décroissante), 0 s’il n’existe aucune corrélation (linéaire) entre les deux variables. Notons qu’il ne faut pas commettre le sophisme Cum hoc ergo propter hoc : la corrélation entre deux variables n’indique pas nécessairement une relation de causalité entre les deux.

Avant tout : visualiser

En analyse de données, une des premières choses à faire avant de se lancer dans une analyse statistique complexe, est de visualiser les données. On se concentre maintenant sur une seule variable : dans la suite de cet article, nous analyserons le revenu moyen par commune (d’autres indicateurs sont disponibles dans le notebook évoqué dans l’introduction).

Dans les deux cartes ci-dessus, celle de gauche représente une valeur aléatoire assignée à chaque commune, alors que celle de droite montre le revenu moyen. Il saute clairement aux yeux que cette dernière variable a une composante géographique forte : le nord de Bruxelles est caractérisé par des faibles revenus (couleur claire), alors que le sud et le pourtour Bruxellois, comme les communes proches du Luxembourg, offrent des salaires élevés. Mais cette approche visuelle, bien que puissante, ne permet pas, par exemple, de savoir si la composante géographique du revenu est plus forte que celle de taux de diplômés. Ni d’identifier facilement s’il existe des zones où la dépendance spatiale est plus fortes que d’autres. Les approches suivantes nous permettront de le faire.

Décalage spatial (spatial lag)

Le “spatial lag” (ou décalage spatial) d’un secteur (dans notre cas, une commune) se calcule en effectuant la moyenne de la valeur considérée sur tous les secteurs voisins. Dans la figure ci-contre, le “spatial lag” du secteur bleu sera de 5 (la moyenne de 3, 4, 6 et 7, sans tenir compte de la valeur du secteur lui-même). Notons que ceci ne peut pas se calculer simplement sur base d’une liste contenant l’indicateur pour chaque secteur : il faut également connaitre la géographie, pour savoir quels sont les voisins de chaque secteur. Les détails de ce calcul sont donnés dans le notebook joint. Une fois le spatial lag calculé pour chaque commune, on peut réaliser un nuage de point de Moran, en positionnant chaque commune selon sa valeur sur l’axe horizontal, et le décalage spatial de cette même valeur sur l’axe vertical, comme illustré ci-dessous.

Le graphique de gauche illustre une valeur aléatoire. On peut y voir que, assez naturellement, aucune corrélation ne peut être établie entre la valeur d’une commune et la valeur moyenne de son voisinage. Celle de droite concerne le revenu moyen, et une corrélation forte y apparaît, confirmant une importante dépendance spatiale pour cette métrique. La valeur centrale se rapport à la superficie d’une commune. On y voit qu’une petite commune a plutôt tendance à être entourée de petites communes (coefficient de Pearson : 0.59), bien qu’il y ait quelques “anomalies”, mais avec une corrélation moins marquée que pour le revenu moyen (coefficient de Pearson : 0.82). 

Les lignes en pointillées représentent la moyenne de la valeur (verticale) et du décalage spatial (horizontale). Elle découpe donc le graphique en quatre quadrants : celui en haut à droite reprend les communes avec un haut revenu (plus élevé que la moyenne) entourées de communes avec un haut revenu, bien plus nombreuses que celles en bas à droite, communes avec un haut revenu entourées de communes avec un bas revenu.

Autocorrélation globale

La méthode de “Join Count” vise à résumer le degré d’autocorrélation par une métrique. Celle-ci s’établit de la façon suivante : on attribue premièrement à chaque secteur une valeur binaire, valant “Black” si la valeur est supérieure à la valeur médiane, et “White” si elle est inférieure. On va ensuite compter le nombre de “jonction Black-Black”, c’est-à-dire le nombre de situations où une commune “Black” touche une autre commune “Black”. Dans le cas du revenu moyen, ce comptage vaut 646. Cette valeur est-elle élevée ? Pour le savoir, on va exécuter un grand nombre de tirages aléatoires, dans lequel on attribuera aléatoirement les valeurs “Black” et “White” à l’ensemble des secteurs, pour ensuite en compter le nombre de jonctions “Black-Black” de chacun de ces tirages.  

Ces nombreux tirages (souvent de l’ordre de 1000), permettent d’obtenir une distribution, présentée ci-contre sous forme de cloche bleue. Les lignes horizontales rouges (dont la hauteur n’a pas d’importance) représentent les comptages pour les différentes métriques que nous avons considérées : salaire moyen (mean_income) ou médian (median_income), proportion de la population avec un diplôme (with_degree), superficie (area), ou nombre moyen de voitures par ménage (car_per_hh). Plus la métrique s’éloigne de la gaussienne, plus faible est la probabilité qu’elle ait été obtenue par un tirage aléatoire, et donc plus forte est sa composante spatiale.

Autocorrélation locale

La métrique globale présentée ci-dessus caractérise l’ensemble du territoire selon sa dépendance spatiale. Mais elle ne permet pas de mettre en évidence des parties du territoire qui seraient plus spatialement dépendantes que d’autres. On peut également (nous passons les détails techniques, qui sont donnés dans le notebook associé), avec une généralisation (également due au statisticien Moran)  des techniques présentées ci-dessus, associer à chaque secteur (entre autres) deux valeurs : 

• Le “quadrant”, déjà présenté ci-dessus, qui indique que le secteur a une valeur haute ou basse, entouré de valeurs hautes ou basses ;
• Une “p-value”, qui indique à quel point la valeur a des chances d’être issue d’un tirage aléatoire. Entre d’autres mots, à quel point ce secteur est corrélé à son voisinage.

Ces deux valeurs permettent de construire la carte ci-dessous, où on retrouve : 

• En gris, les zones avec une “trop grande p-value”, c’est-à-dire où la composante spatiale n’est pas assez significative ;
• En rouge les “hot spots”, soit les communes à haut salaire, entourées de communes à haut salaire ;
• En bleu les “cold pots”, idem pour les communes à bas salaire ;
• En rose, les “diamonds”, les communes à haut salaire entourées de commune à bas salaire ;
• En bleu pâle, les “doughnuts”, les communes à bas salaire entourées de communes à haut salaire.

Conclusions

L’autocorrélation spatiale a de multiples applications. On peut par exemple évaluer la composante géographique du taux de mortalité dû à une maladie spécifique, en la comparant à la même analyse appliquée à la présence d’un polluant ou d’un certain type d’industrie ou d’infrastructure. Par ailleurs, il est aussi possible d’étendre l’analyse non plus à des polygones, mais à des points (commerces, chantiers, voire adresses d’individus) pour mettre en évidence des anomalies (“diamonds” ou “doughnuts”) selon une métrique pour laquelle on s’attend à voir une dépendance spatiale forte.

Il est également possible d’évaluer la corrélation entre deux variables, en tenant compte de leur composante géographique : ceci se fait classiquement en étudiant la corrélation (classique) entre une variable et le décalage spatial de l’autre variable (Bivariate Moran’s I).

Il est possible, comme dans le notebook joint, de faire cette analyse en Python, avec quelques librairies spécialisées (geopandas, libpysal, esda). Mais certains outils OpenSource, comme GeoDa, offrent une interface graphique permettant d’effectuer un grand nombre d’algorithmes d’analytique spatiale, dont l’autocorrélation spatiale.

Il faut cependant être attentif au fait que, tout comme la corrélation statistique en deux variables n’implique pas la causalité de l’une sur l’autre, la présence d’une forte autocorrélation spatiale ne permettra pas non plus de conclure automatiquement que la zone géographique impacte directement la variable étudiée A. Il se peut par exemple qu’une variable intermédiaire B soit, elle, impactée par la géographie, et qu’il existe une corrélation entre A et B. Établir une (auto)corrélation n’est jamais que le point de départ ; il est ensuite nécessaire d’observer les choses de façon plus globale pour établir les liens de cause à effet.

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.