Incorrect result order for autocomplete

[Joxit]

I found an inconsistent result for autocomplete (I think it's since 3.58.0).

When I search 160 avenue aristide briand bagneux, the exact match is on second position instead of the first one.

1. 160 Avenue Marx Dormoy, Bagneux, France
2. 160 Avenue Aristide Briand, Bagneux, France
3. 152/160 Avenue Aristide Briand - CS 80013, Bagneux, France
4. 160th Avenue, Prairie Creek Township, IL, USA
5. 160th Avenue, Rapid City East, SD, USA
6. 160th Avenue, Winnebago, IA, USA
7. 160th Avenue, comté de Warren, IA, USA
8. 160th Avenue, Ringgold, IA, USA
9. 160th Avenue, comté de Des Moines, IA, USA
10. 160th Avenue, Eliza Township, IL,

It works well for 3.57.0

Should we re sort results before sending them ?

[orangejulius]

Hey @Joxit,
This is a good test case.

I think this is more caused by addressit, which thinks that avenue always comes at the end of a street name. This behavior has been in there for a while as far as I know, so I don't think this is new.

Here's the parser output:

"parsed_text": {
  "street": "160 avenue",
  "regions": [
    "aristide briand bagneux"
  ]
},

It's therefore trying to use aristide briand as part of the admin area boosts, which doesn't do anything. If you put a comma in the right place to help the address parsing out, everything works:

/v1/autocomplete?text=160 avenue aristide briand, bagneux

I'd rather not go down the re-sorting path for autocomplete, but I do think it's time for revisiting what parsing logic (if any) the autocomplete endpoint uses so that we can fix this case

[Joxit]

In fact, this works well in our production server (result here) which is in v3.53.0.

160 Avenue Aristide Briand, Bagneux, France is still in first position on our server and Marx Dormoy in second even if aristide briand bagneux is in the region part with addressit.

👍 for the parsing logic 😄

[orangejulius]

This is (finally) fixed as of #1287 and the new Pelias parser!! 🎉

/v1/autocomplete?text=160 avenue aristide briand bagneux