api

api copied to clipboard

Use-cases

Very simple. I would like to perform autocomplete requests with a focus on a country, bbox or circle with radius without completely ruling out places that are not contained by one of these.

Most users are interested in results inside of their own country but still try out bigger cities/specific addresses in other countries. Usually while specifying the ISO 2/3 country code in the search bar as well.

Attempted Solutions

Right now, I add a focuspoint to try to achieve this requirement. But I'm not satisfied with the results. Small venues/localities close to the specified focuspoint receive precedence over much bigger venues/localities that are more in the outskirts of the country.

For instance: I live in Belgium and use a focuspoint close to the center of Brussels. If I try to autocomplete 'Ledeberg', there is a hamlet called Ledeberg with a population of 1500 which is much closer to Brussels than the much larger village Ledeberg with a population of 8300.

-> With a focuspoint: the smallest Ledeberg is the top result -> Without a Focuspoint, the largest Ledeberg is the top result

https://spelunker.whosonfirst.org/id/101755495/ vs https://spelunker.whosonfirst.org/id/1260110643/

/v1/autocomplete?text=ledeberg&size=5&focus.point.lat=50.813017&focus.point.lon=4.301934 vs /v1/autocomplete?text=ledeberg&size=5

Proposal

I'm not 100% familiar with the scoring algorithm but it seems not too hard to prioritize results inside a given country/bbox/circle since the functionality of filtering results in a given country/bbox/circle is already there. Although forgive me if I'm wrong about this!

References

None that I'm aware of.

Hi @zeevogels thanks for writing up the feature requests for this.

It's actually an interesting proposal.

The 'filtering' API params (such as boundary.rect) apply what elasticsearch calls a "MUST" condition. These conditions completely remove any non-matching documents from the results, this has a hugely positive impact on performance because sorting a few million results we're not going to return is fairly pointless.

I think those params are working as expected, they are fairly intuitive in their description and function.

The focus.point param on the other hand is a bit less intuitive. Under-the-hood it's actually applying a boundary.circle too (IIRC) for similar reasons described above, namely that computing the trigonometry on every candidate is terrible for performance.

The other issue is that documents are scored by their distance from the focus point, this simulates the behaviour of reverse geocoding but this is often not exactly what you want for forward geocoding.

As you mentioned there is a valid use-case where you want to 'paint a general area as more important' rather than simply provide a point in space with a 'gravity'.

Technically, I believe all the pieces are already there, we can probably re-use the 'MUST' conditions in a 'SHOULD' context instead (which scores, but doesn't exclude).

Last thing I'll add is that Pelias is coming on 7 years old and one of the reasons it's remained popular is that we're very careful about changing the API footprint.

This change would thankfully be a non-breaking change, but the maintainers will need to know that the code is well tested and the edge cases considered (like using cumulative focus params) and performance-testing/tuning has been done before it could be merged.

Thanks @missinglink for the comprehensive response.

I'm open to help you test the code for both edge cases and performance-testing. I could possibly even review any Elasticsearch queries.