Score van adressen met huisletter te laag

Toepassingen LocatieServer
#1

Als je zoekt op Apollolaan, Almelo en je vraagt de eerste 20 resultaten op dan zitten daar geen adressen tussen zoals 1a en 1b. De eindgebruiker verwacht deze wel.
Ik heb dit probleem eerder met Frank per email besproken in een testcase “Langestraat, Nijkerk”.
Daar zou 1a bovenaan moeten verschijnen.
Zijn reactie in de email van 14-2-2017 was toen:

Resultaten per test case:

  • goed Langestraat 1A: het adres Langestraat 1A in Nijkerk verschijnt in de bovenste resultaten.

Hieruit concludeer ik dat het toen was opgelost.

Verder in de email staat:
Een ander heel lastig op te lossen issue is de lengte van de weergavenaam. Hierdoor krijgen adressen zonder postcode een te hoge score, terwijl adressen met huisletters en/of toevoegingen een langere score krijgen. Dit heeft met het scoringsalgoritme te maken.

Dit is een serieus probleem omdat het lijkt alsof er adressen niet zijn terwijl die er wel zijn.
Kan hier toch iets aan gedaan worden wat betreft score-berekening van adressen met huisletter?

#2

Ik zie nu dat het in de v3 acceptatie endpoint wel goed gaat:

http://acceptatie.geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?wt=xml&q=apollolaan%2Calmelo&rows=20

Ik was in de veronderstelling dat dit al in de huidige productie-omgeving was verbeterd maar dat is dus blijkbaar niet zo.

#3

Ik dacht dat ik er nu was maar dat is nog niet zo.
Bij de sortering staan nu alle adressen met huisletters bovenaan, gevolgd door adressen zonder huisletter. Als ik sorteer met “sort=weergavenaam asc” dan wordt het ook niet goed gesorteerd want dan staat Apollolaan 10 voor Apollolaan 1a.
Hoe kan dit opgelost worden?

#4

Dag Ron, je zou dit op kunnen lossen door een sortering mee te kunnen geven. Je krijgt de gewenste volgorden door de parameter “sort=sortering asc” toe te voegen. Eventueel kun je dit combineren met “typesortering asc” of “score desc”. Typesortering kun je als eerste of tweede parameter meegeven, score alleen als tweede. Bijv: “sort=sortering asc, score desc”.

De berekening van de score an sich is helaas dermate complex dat het resultaat niet altijd gewenst is. Dit heeft o.a. met de vulling van het suggest-veld te maken. Een van de wijzigingen is dat op het acceptatie-endpoint het suggest-veld minder vaak gevuld wordt. Er zijn in theorie 16 verschillende combinaties van de volgorde van huisnummer, huisletter en huisnummertoevoeging, wel of geen spatie daartussen en wel of geen spatie tussen postcodecijfers en -letters. Het huisnummer staat altijd vooraan. Een adres met alleen huisnummer heeft maar twee combinaties (N 1234AB en N 1234 AB", maar een adres met huisnummer + huisletter heeft er vier nl. “NL 1234AB”, “NL 1234 AB”, “N L 1234AB” en N L 1234 AB". Het aantal combinaties is op het oude endpoint altijd maximaal (14, omdat ik eerst twee combinaties over het hoofd had gezien), maar i.v.m. de doorlooptijd van het indexeren en de indexgrootte heb ik dat teruggebracht.

Een issue met het suggest-veld is dat dit veld ook wordt gebruikt voor de highlighting, anders zou ik niet altijd een complete adresstring (zoals in de weergavenaam) toevoegen. Het zou beter zijn als de scoreberekening geen rekening zou houden met het feit dat er meerdere weergavenamen in het suggest-veld zou zijn, maar de score van iedere naam afzonderlijk zou bepalen.

De scoreberekening zie je door debug=true aan de query string toe te voegen. Onderin zie je de berekeningen per adres berekening. Bij adr-3d5528937d0003ea48e51ae8157e10f4 (Apollolaan 9a) zie je in de berekening twee keer “freq=4.0 = termFreq=4.0” staan, maar bij het volgende adres (Apollolaan 2) zie je twee keer “freq=2.0 = termFreq=2.0” staan.

Ik zou weer alle combinaties kunnen toevoegen aan het suggest-veld, maar dat heeft een behoorlijke negatieve impact van de doorlooptijd van het indexeren. Deze is nu, incl. DKK, zelfs iets minder dan voorheen, maar hij zou anders verdubbelen. Zeker met het oog op het toevoegen van meer datasets in de toekomst (o.a. NWB wegen) is dit een factor om rekening mee te houden. Mede ook omdat de index dagelijks bijgewerkt wordt.

#5

Hoi Frank,

Bedankt voor je antwoord.

Als ik “sort=sortering asc, score desc” toevoeg dan krijg ik inderdaad wat ik wil voor dit geval.
Ik kan echter niet goed inschatten of het in andere gevallen dan niet is zoals gewenst. Kun jij dat inschatten?

Uit de API documentatie kan ik niet goed halen wat het sorteren op “sortering”, “typesortering” en “weergavenaam” precies betekent. Sorteren op “score” is duidelijk. Sorteren op “weergavenaam” kan ik me ook iets bij voorstellen maar als het resultaat adressen met huisnummers is dan heb je aan die sortering niet zoveel. In welke gevallen kan dat toegevoegde waarde bieden in plaats van “sortering”?

#6

Dag Ron, ik heb de API-documentatie uitgebreid.

De “typesortering” betreft de “harde” sortering op objecttype. Gemeente = 1, woonplaats = 2, weg = 3, postcode = 3.5 (want later toegevoegd) en adres = 4.

De “sortering” is een extra veld die alleen bij adressen en (vanaf v3) bij percelen wordt gebruikt. Dit omdat het vanwege de manier waarop Solr de score berekent, je soms met een ongewenste volgorde zit. De Apollolaan is hiervan een duidelijk voorbeeld.

Voor adressen wordt het huisnummer als basis gebruikt, getal voor de komma. De huisletter wordt naar een ASCII-code omgezet (hoofdletter), dus dat wordt een waarde tussen 65 en 90. Dit wordt achter de komma geplaatst. Met de huisnummertoevoeging wordt niks gedaan, omdat hier zowel cijfers als letters in kunnen zitten. Als je hier ook nog op wilt sorteren, zou je sort=…, sortering asc, huisnummertoevoeging asc kunnen gebruiken.

Voor percelen wordt er eerst op sectie gesorteerd (ASCII-code eerste letter x 10.000.000 + ASCII-code tweede letter x 100.000) en vervolgens op perceelnummer. Hetzelfde effect kan met sort=…, kadastrale_sectie asc, perceelnummer asc worden gebruikt, dus dit is eigenlijk redundant.

Deze uitleg staat niet zo uitgebreid in de API-documentatie, omdat de wiki hier er zich niet echt goed voor leent, want het is nu één lang document. Ik zou misschien het document in hoofdstukken kunnen uitsplitsen, maar voor het voorbereiden van de documentatie voor meerdere versies wordt dat onhandig.

#7

Ik zie in de API-documentatie de uitbreiding. Ik zie daar echter niet in terug dat je op specifieke attributen kunt sorteren zoals “huisnummertoevoeging”. Het is me nog niet duidelijk wat “weergavenaam” precies is, kun je daar een voorbeeld van geven. De default sortering van V3 is nu “score desc, sortering asc, weergavenaam asc”. Als je zeker weet dat je alleen op adressen zoekt dan wil je eigenlijk altijd “sortering asc, score asc” toch? Ik vroeg me af of het mogelijk is om deze sortering (met een “bugfix”) in V2 zo aan te passen aangezien in V2 alleen op adressen gezocht wordt. Dan hoeven we namelijk geen software update te doen. Onze klanten zien de huidige sortering namelijk als een bug.

#8

Ik zie in de API-documentatie de uitbreiding. Ik zie daar echter niet in terug dat je op specifieke attributen kunt sorteren zoals “huisnummertoevoeging”. Het is me nog niet duidelijk wat “weergavenaam” precies is, kun je daar een voorbeeld van geven. De default sortering van V3 is nu “score desc, sortering asc, weergavenaam asc”. Als je zeker weet dat je alleen op adressen zoekt dan wil je eigenlijk altijd “sortering asc, score asc” toch? Ik vroeg me af of het mogelijk is om deze sortering (met een “bugfix”) in V2 zo aan te passen aangezien in V2 alleen op adressen gezocht wordt. Dan hoeven we namelijk geen software update te doen. Onze klanten zien de huidige sortering namelijk als een bug.

#9

Hi Frank,

we gebruiken de LocatieServer middels http://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q='3998wj 1’ het juiste adres en bag-id op te halen.

We merken dat de score berekening voor ons wat onvoorspelbaar is. Het exacte adres krijgt nl. een lagere score 10.9 dan het adres “Neereind 15-0001, 3998WJ Schalkwijk”

Wat kunnen we doen bij de vraagstelling om de gegevens van de exacte match terug te krijgen?

Nu post-processen we de response en matchen we zelf.

Alvast dank,

Vincent

#10

Dag Vincent,
Als je de quotes uit de query string weglaat, gaat het een stuk beter: http://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=3998wj%201

Alhoewel de quotes worden weggehaald bij het interpreteren van de data, lijken ze toch nog gebruikt te worden voor de exacte match. Voor het feit dat 15-0001 hoger scoort dan de rest, heb ik geen verklaring. Mogelijk wordt ergens in de configuratie de string “0001” als een nummer geïnterpreteerd, waardoor het lijkt dat er 2 matches zijn.

#11

We hebben ook wat interessants aan de locatieserver ontdekt:

Wanneer je ‘7361TG 1’ invult in de locatieserver, krijg je netjes een rijtje met huisnummers, beginnend bij huisnummer 1. Zie: https://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=7361TG 1
Wanneer je het adres uitgeschreven ‘Kaapbergweg 1, 7361 TG Beekbergen’ intoetst komt als tweede resultaat 45-1 bovendrijven (met zelfs dezelfde successcore als nummer 1). Zie: https://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=Kaapbergweg 1, 7361TG Beekbergen
Als je de komma weglaat en je vult in ‘Kaapbergweg 1 7361 TG Beekbergen’, dan klopt het rijtje wel weer. Zie https://geodata.nationaalgeoregister.nl/locatieserver/v3/suggest?q=Kaapbergweg 1 7361TG Beekbergen

Uiteraard is het een oplossing om de komma weg te halen om zo tot het ‘nette’ rijtje te komen, maar deze wordt juist als suggestie meegegeven vanuit de PDOK locatieserver (staat in de ‘weergavenaam’). Daarnaast staat zo’n komma natuurlijk wel zo netjes voor gebruikers. Is het mogelijk dat de locatieserver aangepast wordt zodat er met komma hetzelfde rijtje getoond wordt als zonder komma?