Wij gebruiken de suggestieservice voor het gebruikers laten zoeken van locaties. Dat werkt goed, maar we zien dat als gebuikers een zes cijferige postcode ingevoerd met een spatie tussen de cijfers en de letters, dat het dan niet volgens verwachting gaat. De letters worden dan gezien als het begin van de straatnaam, en niet als onderdeel van de postcode. Een postcode invoeren zonder tussenspatie werkt uiteraard wel beter.
Bij een postcode als ‘1234 HE’ worden de cijfers vervolgens ook als huisnummer gezien.
De vraag is nu, is er een mogelijkheid om dit gedrag te beïnvloeden, gezien het feit dat de officiële schrijfwijze van een postcode de spatie wel bevat, en gebruikers deze ook invoeren.
“4567DE” (zonder spatie) geeft inderdaad een beter resultaat dan “4567 DE” (met spatie).
De locatieserver ziet de postcode met spatie waarschijnlijk niet als één term, vandaar dit gedrag. Heb nog even geprobeerd of het met boosting of sortering te verbeteren is, maar dat heeft in dit geval onvoldoende effect.
Ik heb een ticket op onze backlog geplaatst om te bespreken of we dit willen/kunnen aanpassen. Wijzigingen aan gedrag van de locatieserver worden echter niet lichtzinnig doorgevoerd dus verwacht niet op korte termijn een aanpassing. Wil je snel een oplossing, dan kan je overwegen om zelf postcodes (PC6) te herkennen en de spatie eruit te filteren alvorens deze naar de locatieserver te sturen.
Wij hadden inderdaad zelf ook al gekeken naar de oplossing om de postcodes zelf te herkennen en te modificeren, maar gezien het feit dat we de gebruikers de vrijheid willen geven om zelf input in te voeren wilden we eerst kijken of er opties waren om dit met bijv. extra parameters te kunnen beïnvloeden, zodat postcodes beter herkend worden.
Nu duidelijk is dat dat niet kan willen we eerst kijken wat we hiermee gaan doen, aangezien in onze use-case de gebruikers onmiddelijk terugkoppeling krijgen lijkt het een minder groot probleem te zijn. Maar het zelf kunnen verwijderen van de spatie zou inderdaad een oplossing kunnen zijn.
Kunnen wij ergens zien wat de status van deze change aan de locatieserver is? Of kunnen we ergens zien als deze change is opgeleverd (of rejected)?
@Carlo , we willen de Free service niet gebruiken omdat de querystring gebruikersinput is, en we die liefst niet willen aanpassen. En een gebruiker kan bijv ook terecht op plaats, of straatnaam zoeken en we willen gebruikers niet een querytaal leren.
Waar baseer je dat op? In de Wet basisregistratie adressen en gebouwen komt de term ‘postcode’ niet eens voor… (en het is ook geen verplicht attribuut - er zijn zat adressen zonder postcode).
We hebben nog eens naar dit issue gekeken. Het probleem lijkt voornamelijk te spelen als in de postcode specifiek de letters DE los staan van de nummers. Al sluit ik niet uit dat er ook andere scenario’s zijn waarin dit mis gaat. Extra complicerende factor is dat er voor DE ook synoniemen zijn. De zoekopdracht wordt daardoor onder water 4567 (den der d de). Dit maakt het matchen van resultaten wat ambigu. De locatieserver is een vrije tekst zoekmachine. Het is hierdoor erg lastig om te bepalen wat de gebruiker precies bedoelt met een bepaalde zoekterm. Je kan bij het implementeren van de locatieserver het gedrag echter wel beïnvloeden, door meer waarde te hechten aan matches op bepaalde velden. Dit kan met de qf parameter. De default waarde van deze parameter is exacte_match^1 suggest^0.5 huisnummer^0.5 huisletter^0.5 huisnummertoevoeging^0.5. Je kan hier het veld postcode_alternatieven aan toevoegen. Dit veld bevat de postcode met een spatie. Je request komt er dan als volgt uit te zien:
Dit zou ook goed moeten gaan als een gebruiker op bijvoorbeeld een adres zoekt. Het is daardoor niet nodig om eerst te kijken of iemand op een postcode zoekt om daarop de request aan te passen.
De langste straat is niet die zij noemen maar deze: