Location Preference does not appear to be honored

[dan-castle-rock]

I am evaluating photon for use as an open source alternative and am not seeing the results I would expect with location biasing for a geocode request. The URL is passing in a latitude/longitude centered on Portland Oregon USA. When I enter a query such as 'bois', I would expect the results to include Boise, Idaho (which is nearby) to appear in the search results, but instead am receiving results from around the globe. Being new to this library, I could be doing something incorrectly.

The URL I am passing in is: http://photon.komoot.de/api/?q=bois&lat=45.52&lon=-122.6819

[christophlingg]

Our location bias fosters results nearby but does not skip results that are far away. Exact matches (in this case with the french city Bois) are more important than partial matches (Boise). In the end the exact match overweights the benefit of the location bias and the french city appears first.

if you type the entire name it works: http://photon.komoot.de/api/?q=boise&lat=45.52&lon=-122.6819

[karussell]

I find this problematic too. It might related to #193

[dan-castle-rock]

Thank you for the reply. I agree with Peter. For our application, location
biasing is more important than exact matching (as I suspect is true with a
lot of applications). As suggested in issue 193, are there any plans to add
a filter that would give more weight to location than exact name?

On Fri, Oct 16, 2015 at 1:44 AM, Peter notifications@github.com wrote:

I find this problematic too. It might related to #193
#193

—
Reply to this email directly or view it on GitHub
#198 (comment).

---

Dan Nichols
Mobile Software Developer
Castle Rock Associates

[christophlingg]

Different uses cases require different location biases. I think it would make sense to have

• a location bias that is controlled by an additional request parameter
• an additional endpoint that returns entries only within a given radius. That's cool if you want to search for stuff that is nearby / in my city

[karussell]

maybe a new parameter like distance_filter=5km which directly filters instead of scores the results, would be sufficient and also usable in other situations.

[amnesia7]

Or proximity.
Maybe it could apply extra weighting to those within the proximity requested but still allow global ones.

[amnesia7]

Alternatively, what about following nominatim's design (http://wiki.openstreetmap.org/wiki/Nominatim#Parameters) that doesn't use lat,lng but instead uses viewbox (the preferred area to find search results) and bounded (restrict the results to only items contained with the bounding box).

[silberjan]

any clue when this will be implemented? for us the location biasing is also much more important than exact matches.

[christophlingg]

I have it on my list, but there is a lot of other stuff too ;-( Can you help out?

[stephanebastian]

Hello,

I just stumbled across this issue and I am wondering if ElasticSearch function scoring would help here, adding more weight to result that are close to a specified location
just my 2 cents

[dmitry]

@stephane-bastian it could based on the distance and few other parameters.

[imadk]

Hi Has this been implemented?

[karussell]

This should work now with #254

[kurko]

Nope, that doesn't seem to be working after #254.

http://photon.komoot.de/api/?q=bois&lat=45.52&lon=-122.6819 doesn't return Boise, Idaho (not even with &limit=1000). I tried adding location_bias_scale=2 which returned:

{
  "message": "unknown query parameter 'location_bias_scale'. Allowed parameters are: [q, limit, distance_sort, osm_tag, lon, lang, lat]"
}

#254 was definitely deployed to photon.komoot.de (according to #295). Was location_bias_scale dropped but still documented in the README? Is lat/lon working at all?

[soualid]

+1

[lonvia]

With #580 the example returns Boise in Oregon as expected.

[lonvia]

Addressed in #580.