Waarom krijgt het juiste adres niet de hoogste score van LocatieServer?

Toepassingen LocatieServer
#1

Wanneer ik LocatieServer gebruik voor het geocoderen van adressen zónder huisletter of andere toevoeging, gaat het volgens mij niet goed wanneer er een adres is in dezelfde straat en met hetzelfde huisnummer maar mét huisletter of toevoeging.

Voorbeelden:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Doornik 1 6681KG Bemmel

https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Emminkhuizerlaan 1 3927EC Renswoude

Het juiste adres heeft niet de hoogste score, maar staat op de tweede plek.

Kan ik iets tweaken om het wel goed te laten gaan?

Groet,
Willy

#2

Letterlijk zoeken kan wel:

https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres%20AND%20bron:BAG&q="Doornik%201"%206681KG%20Bemmel

Dus “Doornik 1” waarbij de quotes als %22 gecodeerd kunnen worden (staat niet goed afgeveeld in bovenstaande url)

1 like
#3

Dankjewel voor je antwoord @Anton. Het werkt, maar bij letterlijk zoeken zijn er weer andere adressen die geen goede match hebben, omdat de opgegeven straatnaam niet exact overeenkomt met de officiële schrijfwijze.

In de API beschrijving op Github staat in paragraaf 3.2 dat je de qf=<query fields> parameter aan je request kunt toevoegen om bepaalde velden een extra ‘boost’ te geven. De default waarde zou exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5 zijn. Maar volgens mij is dit niet zo.

Query met default waarde voor qf:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Doornik 1 6681KG Bemmel
» hoogste score is Doornik 1a

Query met qf=exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Doornik 1 6681KG Bemmel&qf=exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5
» hoogste score is Doornik 1

Query met default waarde voor qf:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Emminkhuizerlaan 1 3927EC Renswoude
» hoogste score is Emminkhuizerlaan 1a

Query met qf=exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5:
https://geodata.nationaalgeoregister.nl/locatieserver/v3/free?fq=type:adres AND bron:BAG&q=Emminkhuizerlaan 1 3927EC Renswoude&qf=exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5
» hoogste score is Emminkhuizerlaan 1

Het lijkt er op dat de defaultwaarde voor qf niet overeenkomt met wat er in de API documentatie staat. Kunnen jullie dat checken @PDOKbeheer?

#4

Beste Willy,

In paragraaf 3.2 staat het qf=<query fields> omschreven voor de “suggest” API. In je voorbeelden gebruik je de “free” API. Bij de “free” API staat het qf=<query fields> niet omschreven in de documentatie, maar werkt deze wel. Er is alleen geen default waarde voor ingesteld. Je kan twee dingen doen, namelijk de “suggest” API gebruiken zonder qf=<query fields>, of wanneer de eerste optie niet voldoet, de “free” API met qf=<query fields> zoals je die in je voorbeelden al gebruikt.

#5

Duidelijk, dankjewel!

Lengtegraad, Breedtegraad achterhalen obv BAG-ID