Venue popularity additions #531
Conversation
|
I've done some testing on this PR, and while we will have a lot more work to do to really take advantage of these changes, I believe it's more than good enough to merge. It makes a big difference in a good number of cases. Some observations: Improved: San Francisco Zoo/v1/autocomplete?focus.point.lat=37.743618&focus.point.lon=-122.426117&text=zoo This query has given us trouble for a long time. Even with proximity boosts, there's not much to prefer a nearby Zoo over places with a technically better text match. Improved: Statue of LibertyThis one is truly a classic, and returns much better results now. Very frustratingly, for search, the ferry terminal on Liberty Island is the first result. This is because only the ferry terminal is part of the Liberty Island /v1/search?boundary.country=USA&text=statue of liberty The difference for autocomplete is quite good, however: Surprise Improvement: Structured requests for venuesIt looks like some long-failing structured geocoding requests are now passing because the venue being returned has just enough boosting to be ranked higher than an address for the same location: /v1/search/structured?venue=police&address=1090 N Charlotte Street&locality=Lancaster®ion=PA
I'm actually a little unclear on how we want the Less than expected (if any) improvement: POI test casesWhile there are some improvements here, it looks like most POI result improvements will require scoring fixes (like pelias/pelias#862) to solve. Testing dataHere are some complete acceptance test logs used for comparison: ConclusionWhile there are places where we'd prefer better results, this PR doesn't seem to break anything, and includes quite a few solid improvements! It creates a solid foundation for adding popularity to venue records (meaning I consider it to solve a 5 year old issue: pelias/pelias#171). I'm sure we'll be tweaking this sort of thing forever, but I think we should merge this PR to start us out! |
orangejulius
force-pushed
the
venue_popularity_additions
branch
from
6cef34c
to
fed13ee
Compare
| // only map venues | ||
| if( doc.getLayer() !== 'venue' ){ | ||
| return next(null, doc); | ||
| } |
There was a problem hiding this comment.
I was thinking we could remove this. Famous addresses such as for the Sydney Opera House may not always appear first
There was a problem hiding this comment.
On second thought let's definitely either solve this separately, or at least enable popularity for addresses in a separate PR.
orangejulius
force-pushed
the
venue_popularity_additions
branch
from
fed13ee
to
c22bd5a
Compare
These are now passing thanks to OSM venue popularity: pelias/openstreetmap#531
Appears to have been fixed by OSM venue popularity pelias/openstreetmap#531 pelias/pelias#183
This PR builds on #493 with a couple additions I think might help our existing set of test cases. I'm sure we could think of more to add!
Closes pelias/pelias#171
Closes #493