Veel te veel resultaten

Toepassingen LocatieServer
#1

De nieuwe locatieserver bevat veel meer zoekbare informatie dan de geocoder. Dit maakt het gebruik veel lastiger. Om 2 voorbeelden te geven bij zoeken met free op locatieserver en strict=false bij geocoder.

Zoeken op Utrecht:
geocoder: 3 resultaten
locatieserver: 189300 resultaten

Zoeken op 3513AA:
geocoder: 1 resultaat
locatieserver: 30 resultaten
(Waarbij postcode zoeken bij locatieserver niet 1 specifiek resultaat op levert dat verwijst naar de straat, het zijn losse adressen)

In praktijk zullen dus allerlei filter opties moeten meegegeven worden en mogelijk context analyse, dus als het op een postcode lijkt andere filter opties om bruikbare resultaten op te leveren.

Ik weet zo niet wat een oplossing hiervoor zou kunnen zijn.

#2

Beste Hilbrand, het is eenvoudig om een filter mee te geven op objecttype. Dit kan door het toevoegen van de string “and type:{type}” aan de query string. Voorbeeld als je alleen een postcode-object wilt terugkrijgen: http://geodata.nationaalgeoregister.nl/locatieserver/free?wt=xml&q=3513AA%20and%20type:postcode

De reden dat er veel meer resultaten worden teruggegeven, is omdat de onderliggende index nu heel anders wordt opgezet, wat veel meer verschillende zoekmogelijkheden geeft, en dus ook resultaten.

#3

Ik begrijp de index anders is. Mijn bezwaar was dat juist hierdoor ik zelf eerst logica moet bouwen om het bruikbaar te maken. Als een gebruiker zoekt op postcode moet ik dus eerst herkennen dat er op postcode gezocht wordt en dan de query doen met als extra argument type:postcode. In feite moet ik om het zinvol te maken dan elke query met elk type doen en dan te filteren.

Om zinvol te zijn zou het zoeken beperkt moeten zijn op relevante velden en niet op alle data velden. Bv. Als ik op utrecht zoek zou niet in velden moeten worden die niet direct relevant zijn. Dat wil zeggen ik wil niet elke straat in de hele provincie utrecht als resultaat. Het zelfde voor idee bij postcode.

Dus de dienst zou zelf al het filter moet toepassen. Dus bij data met type:postcode alleen in het veld postcode zoeken, bij type:gemeente alleen in het veld gemeentenaam (en misschien ook gemeentecode). type:weg in straatnaam, etc. adres is dan nog een uitdaging: is straatnaam + huisnr en dat is niet triviaal. Verder zou nog op id velden gezocht kunnen worden.

#4

Beste Hilbrand, Locatieserver is een generieke dienst. Voor ons is het ook niet mogelijk om te bepalen waar een gebruiker naar op zoek is, zonder context. Dit is ook afhankelijk van hoe de clientapplicatie geschreven is. Als de clientapplicatie ook generiek is opgezet, dan is onbekend wat de context is en moeten we een “best guess” doen.

Hiervoor wordt op dit moment de sortering op type gebruikt, waardoor resultaten altijd in de volgorde gemeente, woonplaats, weg, postcode, adres worden teruggegeven. Niet ideaal. Solr biedt de mogelijkheid om boosting toe te passen, waardoor “grotere” / meer belangrijke objecten naar boven komen drijven. Bij de Politie, waar we de code en configuratie van overgenomen hebben, was dit niet bevredigend. En wat “belangrijk” is, voor de een is dat heel wat anders dan voor de ander. Dit is subjectief, zeker als de context niet duidelijk is. Wanneer na de feestdagen alle betrokkenen weer terug zijn, zouden we dit tegen het licht kunnen houden.

Wat het zoeken betreft: wat is het relevante veld? Als een gebruiker begint te typen, begint hij of met een letter of met een cijfer. In het eerste geval zou het een gemeente, woonplaats, straatnaam of adres kunnen zijn. In het tweede geval een postcode of adres (adres als postcode + huisnummer).

Wat de werking van de suggest-service betreft: als input wordt het veld weergavenaam gebruikt. Dit wordt samengesteld uit verschillende soorten velden. Deze tekst is zodanig opgezet dat het herkenbaar is om wat voor type object het gaat (gemeente, woonplaats, weg, postcode of adres). Het is onvermijdelijk meerdere velden te gebruiken. De opzet van de weergavenaam is als volgt:

  • gemeente: ‘Gemeente’ + gemeentenaam
  • woonplaats: woonplaatsnaam, gemeentenaam, provincienaam (om ze uniek te maken)
  • weg: straatnaam, woonplaatsnaam (NB: deze zijn niet uniek)
  • postcode: straatnaam, postcode, woonplaatsnaam
  • adres: straatnaam, huisnummer (+ letter, toevoeging), postcode, woonplaatsnaam

Verder is het goed om te weten dat we iteratief werken. We zullen regelmatig een nieuwe release van Locatieserver uitbrengen, waarbij we zoveel mogelijk backwards compatible zullen blijven. We staan open voor input en suggesties van gebruikers, maar we zullen wel continu keuzes moeten maken. Blijf dus vooral feedback geven.

#5

Voor ID-velden kan het lookup-endpoint gebruikt worden: …/lookup?id={id}.
Je kunt ook het free-endpoint gebruiken: …/free?q=id:{id}