Loading…
Tilbage

Profilbillede

Bug i autocomplete api?

Adam Læssøe

Jeg er ved at bygge et inputfelt ovenpå jeres autocomplete api.

Det virker nogenlunde, men:

Når jeg skifter fra `startFra: vejnavn` til `adgangsAdresse` får jeg ikke adressesser med fra København. Det kunne ligne en off-by-one fejl.

Logger jeg vejnavn-resultaterne og følger `href`'en, kan jeg se at den københavnske vej er med der. Det eneste tidspunkt hvor den ikke er med er når der søges på kun det komplette vejnavn uden nummer. Se screen grab her.

Hej Adam,

Årsagen til at du ikke får adresser med fra København i den søgning er, at ranking-algoritmen placerer københavn lavere i prioriteringen end de andre adresser, så den ikke når at komme med i svaret. Det skyldes, at rankingen blandt andet baseres på hvor stor en del af adresseteksten der matcher det der står i autocomplete-feltet, og "københavn V" er længere end de andre postnumre og får derfor lavere ranking.

Vi tager det med som input, det ville give god mening at København var med i svaret. 

Hej Anders

Tak for forklaringen. Men jeg er nu ikke helt sikker på at jeg køber den:

Hvis jeg taster "Straussvej 1" kommer København-versionen som første element.

Her er screen grabs fra jeres egen implementering.

 

 

 

Hej Adam,

Den er nu god nok ;-)

Forklaringen er, at der sker to sorteringer af svaret.

Den første sortering udføres af databasens (PostgreSQL) rankingalgoritme. Det er den der placerer København sidst i resultatet i den første søgning, så København ikke kommer med der.

I anden søgning er der tilstrækkeligt få resultater til at København kommer med, selvom København rankes sidst af databasen. Men vi foretager også en sortering i applikationslaget, og i den sortering ranker de lige godt, hvorved sorteringen ender med at blive efter postnummer.

Hmm... ok. If you say so :)

Nu ved jeg ikke lige hvordan PG ranker her, men: "...2A, 9200 Aalborg" har næsten samme Levenshtein Distance fra Straussvej som "...2, 2450 København SV" og er med i svaret på "Straussvej".

Either way virker det.. overraskende.

Re. "Vi tager det med som input, det ville give god mening at København var med i svaret."

Er der en ticket man kan følge på jeres github eller huboard?

Flere af vores brugere har bemærket problemet. Eneste workaround jeg kan få øje på er at lave kald både med og uden kommune-constraint og selv klippe svarene sammen. Det ville være rart at undgå det besvær.

Hej Adam,

Der er ikke umiddelbart nogen simpel løsning på problemet. I dag anvender vi som nævnt Postgres' indbyggede ranking-algoritme, ts_rank, som du kan læse om her:

https://www.postgresql.org/docs/current/textsearch-controls.html 

Helt konkret, så laver vi først en søgning, der finder op til 1000 matchende adresser i en uspecificeret ordning. Disse adresser sorteres med ts_rank, hvorefter de bedst matchende sendes til vores applikationslag, som foretager endnu en sortering af resultatet.

Det er ikke helt ligetil at ændre i algoritmen, og det er ikke klart hvilken metode der giver den bedste løsning. Det er et vanskeligt område at lave om i, for en ændring der umiddelbart ser fornuftig ud i forhold til at løse ét problem godt kan vise sig at give problemer med andre søgninger. Derudover er der selvfølgelig også performancehensyn.

Den simple løsning kunne være at lade være med at vise nogen adresser før der er indtastet midst et tal fra husnummeret. Spørgsmålet er bare, hvad der så skal vises, når brugeren vælger et vejnavn.

En anden løsning kunne måske være at lave en customiseret ranking-algoritme.

En tredje mulighed kunne være, at der først fremsøges kombinationer af vejnavne og postnumre, hvorefter der så fremsøges et antal adresser fra hver af disse, så det sikres, at hver kombination af vejnavn og postnummer er repræsenteret i svaret. Det er heller ikke helt simpelt.

En fjerde mulighed kunne være at indsætte et mellemtrin mellem vejnavnsøgningen og adgangsadressesøgningen, hvor der vises vejnavn/postnummer kombinationer i autocomplete. Hvis man vælger en af dem, så udfyldes vejnavn og postnummer, og cursoren placeres således man er klar til at indtaste husnummeret. 

Der er måske også andre løsningsmuligheder.

Vi er glade for feedback. Det er interessant for os, og ret overraskende, at i ligefrem har brugere der har henvendt sig omkring det. Vi har egentlig altid opfattet autocomplete sådan, at det er en hjælp - man taster, indtil adressen dukker op. I praksis vil man næsten altid skulle taste noget af husnummeret, før man kan vælge den rigtige adresse, så vi har ikke opfattet det som et problem, at nogle postnummre ikke altid vises umiddelbart efter indtastning af vejnavnet. Det er heller ikke noget der altid vil kunne opfyldes, da nogle vejnavne optræder over 200 forskellige postnumre.

Jeg har oprettet et issue: https://huboard.com/DanmarksAdresser/Dawa#/issues/430290561

Vi kan p.t. ikke sige om der bliver lavet om i den nuværende opførsel, eller hvad løsningen i givet fald bliver.

Hej Anders

Tak for grundigt svar. Jeg synes fjerde mulighed lyder fornuftig, hvis mellemtrinnet springes over i fald der er netop et eksakt match på vejnavn.

Du har sikkert ret i, at vores brugere skal taste et ciffer før den rigtige adresse figurerer på listen. Men vi har mange mobile brugere, der taster et par bogstaver, og så vælger vejen fra listen. Der bliver det ret forvirrende, at man først ser en liste, hvor København er ekskluderet. Det føles som om der er noget galt.

Hej Adam,

Det er bestemt meningen at brugerne vælger vejen på listen, så de slipper for at taste hele vejnavnet, men der vil uundgåeligt være mange tilfælde, hvor det postnummer som brugeren søger ikke er med i svaret, af den årsag at det i mange tilfælde slet ikke vil være muligt at vise alle postnumrene. Men måske det vil være mindre forvirrende, hvis det altid er de første postnumre der vises, når nu postnumrene er sorteret numerisk.

Ulempen ved løsning nummer 4 er, at det kan være forvirrende for nogle brugere at der forudfyldes noget efter cursorens placering. Derudover er det ikke helt klart at den kan implementeres på en bagudkompatibel måde, hvilket øger implementations- og vedligeholdelsesomkostningerne for os.