Het valt me op dat de scores van verder identieke resultaten in de nieuwe locatieserver (api.pdok.nl) veel lager zijn dan in de oude versie. Is daar een reden voor?
Een voorbeeld, het eerste resultaat in nieuw heeft score 6.953095, terwijl de oude versie 15.299182 heeft.
Aha, bedankt voor de link. Had ik dit van tevoren ergens kunnen lezen? Wij filteren in sommige gevallen de resultaten op een bepaalde minimum score, en die waarde klopt nu niet meer.
Overigens, met dat het voor de volgorde niet (veel) uit zou moeten maken ben ik het niet helemaal eens. Wat in onze applicatie gebeurt is dat er max 100 resultaten worden opgehaald, en deze worden gegroepeerd naar type. Bij zoeken op bijvoorbeeld Austerlitz zagen we dat van die 100 resultaten er eerst 33 van het type postcode waren, en nu nog maar 28. Het totale aantal resultaten is wel gelijk, namelijk 962.
Ik snap de oorzaak, maar vind het opvallend dat door de nieuwe scoreberekening de sortering toch aardig anders is.
Niet voor zover ik weet, dat kun je ook opmaken uit de rest van dat draadje.
Hmmm. Ik mag hopen dat dat geen magic number is, want dat zou ik knap gevaarlijk vinden…
Voor de rest: ik weet niet exact wat er aan de achterkant veranderd is, dus vanwaar die andere getallen zou ik niet kunnen zeggen.
Ik weet niet waarom een minimum score gevaarlijk is? Wij hebben ooit een waarde bepaald waarvan we vinden dat resultaten met een lagere score niet relevant genoeg zijn.
Wat ik veel gevaarlijker vindt is dat scores opeens een factor 2 kleiner worden, zonder dat we daarvan op de hoogte worden gesteld. Bij de aankondiging van de nieuwe URL’s had daar best iets over vermeld kunnen worden, in plaats van dat ik forum berichten moet gaan doorspittten.
De locatieserver is gebaseerd op Solr. Feitelijk is de locatieserver Solr met specifieke configuratie. De onderliggende Solr instantie is geüpgraded naar een nieuwe versie. Hierbij is ook de scoreberekening veranderd. Tussen Solr versies worden er wijzigingen gedaan in het algoritme die de score berekend, wat veranderingen in de score kan betekenen. De hoogte van de score is in context van een resultatenlijst belangrijk voor de volgorde van de resultaten, maar is in isolatie betekenisloos. Het toepassen van een constante op deze score is daarom gevoelig voor fouten. We kunnen ook met toekomstige upgrades van de locatieserver niet garanderen dat de score berekening gelijk blijft. Ook de volgorde van de resultaten in een resultatenlijst zal in de toekomst niet altijd hetzelfde zijn. De locatieserver is bedoeld als organische zoekmachine. Een gebruiker moet altijd uit een resultatenlijst zelf het resultaat selecteren die past bij de zoekopdracht. Gelijk aan hoe dat bij internet zoekmachines zoals Google werkt. Een implementatie op basis van de locatieserver waar geen gebruiker de resultaten interpreteert is tevens gevoelig voor fouten.
Bij het opstellen van de berichtgeving rondom de nieuwe locatieserver zijn we wat betreft het gebruik van de locatieserver te naïef geweest. We hebben voorgesorteerd op de primaire use case van de locatieserver en te weinig rekening gehouden met de complexere implementaties. Voor laatst genoemde was het inderdaad beter geweest als we wat dieper in waren gegaan op de verschillen.
Tsja. Wat je hiermee feitelijk doet, is een relatieve waarde beschouwen als een absolute waarde. De scores worden berekend aan de hand van de zoekvraag, en zijn daarmee dus relatief ten opzichte van die zoekvraag. Het is dus geen absolute waarde. Maar als je zegt: alles kleiner dan 25 vind ik niet meer relatief, dan behandel je die score dus alsof dat een absolute waarde is. En dat vind ik gevaarlijk.
Bovendien: het is mij wel gebeurd dat ik op zoek was naar een straat waarvan ik de naam ruwweg kende, maar de schrijfwijze niet exact. Op dat moment ben ik dus geinteresseerd in alle zoekresultaten, ook die met een lage score, want die zouden voor mij best wel eens heel relevant kunnen zijn. In jouw applicatie zou ik die resultaten dus niet gezien hebben, terwijl ik er misschien wel naar op zoek was. Naar mijn mening is het niet aan de zoekmachine om de relevantie van resultaten te bepalen, maar aan de eindgebruiker. Is ook 1 van de redenen dat ik een hekel heb aan de zoek-algoritmes van de grote softwarejongens: die denken ook dat ze weten wat ik interessant vind, maar daar klopt nooit iets van…
Dat ben ik met je eens. Het zou erg prettig zijn als er, bij de aankondiging van dit soort migraties, een korte release-note beschikbaar zou zijn met de wijzigingen tussen een oude versie en een nieuwe (liefst zonder dat je daarvoor Capabilities moet gaan vergelijken 
). In veel gevallen kan die heel kort zijn, maar ik heb bijvoorbeeld ook wel wijzigingen in FeatureType-namen langs zien komen.
En ik zie dit soort draadjes ook best vaak langs komen hier. Ik was zelf al begonnen om een Capabilities-vergelijker te gaan schrijven, maar die had hier niet veel geholpen 