Version en français

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.

	Cloud solutions	On-premise solutions
In te voeren complexiteit	🙂	🙁
Infrakosten	🙂	🙁
GDPR, Vertrouwelijkheid	🙁	🙂
Kosten voor grote volumes (tijd, €)	🙁	🙂
Internettoegang	🙁	🙂
Kwaliteit	🙂	😐
Wereldwijde dekking	🙂	🙁

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.