Ik probeer het adres “Avebe-Weg 1, 9607 PT FOXHOL” met de suggest API (via de FME PDOKGeocodeerder) te geocoderen. Voor dit topic even meerdere opties in de url, maar normaal neem ik de hoogste score.
Hoogste score heeft:
“weergavenaam”:“Avebe-Weg 1a-10, 9607PT Foxhol” met score 20.93158
Het identieke adres als de zoekterm geocodeert naar:
“weergavenaam”:“Avebe-Weg 1, 9607PT Foxhol” en heeft een lagere score: “score”:20.422703
Dit voelt niet logisch. Kan iemand de ratio duiden?
Harm Olthof
Hoi Harm,
Ik heb me ook wel eens afgevraagd waar die score op is gebaseerd en wat die waarde van 20 betekent. Ik vermoed dat de geocoder niet zo slim is als die lijkt en gewoon wat statistiek loslaat op de strings. In jouw geval, de ‘A’ van de straatnaam en de ‘1’ van het huisnummer komen nog een keer voor in ‘1a-10’ en scoort daarmee een paar extra puntjes.
Voor ‘9607PT 1’ gaat het trouwens wel goed.
Ik vroeg me ook af vanaf welke score je er van uit kunt gaan dat je de juiste lokatie hebt gevonden, bijvoorbeeld bij het geocoderen van een hele lijst adressen.
Benieuwd of iemand van PDOK hier meer over kan vertellen!
Groet,
Raymond
1 like
Dit is wel een aparte inderdaad. Een suggest met alleen een q=Avebe-Weg 1, 9607PT Foxhol levert dat resultaat als 36e op. Er staat in de Github documentatie wel een (heeeel) kort stukje over de scoreberekening, maar daar word het niet echt duidelijker van:
Wanneer er meerdere zoektermen opgegeven zijn (gescheiden door spaties), wordt de score hoger naarmate er meer matches zijn.
Het lijkt er haast op dat de
huisletter/huisnummer toevoeging leeg == huisletter/huisnummer toevoeging leeg
een lagere score krijgt dan
huisletter/huisnummer toevoeging leeg == huisletter/huisnummer toevoeging gevuld
terwijl je andersom zou verwachten…
1 like
Ik vermoed dat er een soort Bayes statistiek wordt toegepast: er zijn idd een groot aantal adressen met hetzelfde patroon: Avebe-Weg 1a-xx
Maar het zou mooi zijn als de systematiek ergens (uitgebreid) gedocumenteerd wordt.
Groeten,
Harm
Volgens mij is het antwoord: heel veel 2.
Zie namelijk 2.2 bulletpoint 2 in de handleiding: API Locatieserver · PDOK/locatieserver Wiki · GitHub
Dus ipv:
q=abc, def
wil je waarschijnlijk:
q=“abc, def”
met http encoding wordt dat:
q=%22abc%2C%20def%22
heel veel 2 dus.
1 like
Hallo Oscar,
Dank, dat is scherp opgemerkt! Dus het ligt aan de komma in de vraag-locatie: “Avebe-Weg 1, 9607 PT FOXHOL”. En idd “Avebe-Weg 1 9607 PT FOXHOL” geocodeert meteen goed. Dus ik ga of , verwijderen uit de vraag-locatie of idd een boel 2-en toevoegen…
Groeten,
Harm
Nou, nee, het ligt aan de spaties en het ontbreken van double-quotes in je URL achter de q parameter.
q=abc, def
betekent:
q=“abc,” OR “def”
Maar je wilt “abc, def” als één geheel zoeken. Dan moet je dat geheel tussen double-quotes zetten in de URL achter de q parameter.
q=“abc, def”
zoeken op Avebe-Weg 1,9607 PT FOXHOL of Avebe-Weg 1, 9607 PT FOXHOL (zonder dubbele aanhalingstekens eromheen) levert hetzelfde op. Dus het lijkt er op dat puur de komma de oorzaak is.
Maar dubbele aanhalingtekens lost het iig op.
Nogmaals dank
Haha, tja, maar hoeveel spaties zie je in beide query’s?
Als je schrijft:
q=Avebe-weg 1,9607 PT FOXHOL
dan denkt de computer alsnog dat je dit bedoelt:
q=“Avebe-weg” OR “1,9607” OR “PT” OR “FOXHOL”
Vandaar de noodzaak voor quotes om het geheel (om o.a. de spaties in te sluiten).
1 like
Voor de goede orde: die Haha was niet bedoelt richting jou, maar naar het idee dat we met alle beloftes van AI en wat niet, nog steeds met dit soort totaal autistische computerproblemen te maken hebben terwijl het voor ieder mens volkomen duidelijk is wat je bedoelt. Nou ben ik zelf ook autistisch dus ik snap die computer wel, maar toch…
1 like