Update Pelias configuration geocoding

[jmfield2]

As discussed in the last meeting, a strange issue was discovered with the way Pelias slightly different search keywords yield very different results - despite setting focus.point.

Currently, the geocoder is setting:

• focus.point.lat=28.061062, focus.point.lon=-82.413200
• boundary.rect.min_lat=27.279, boundary.rect.min_lon=-82.851, boundary.rect.max_lat=28.375, boundary.rect.max_lon=-82.012

And the following queries:

• "subway" https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=subway&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.country=US&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012 "label": "Subway, Pleasant Dale, Tampa, FL, USA" (correct)
• "subwa" https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=subwa&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.country=US&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012 "label": "Subway, St. Petersburg, FL, USA" (incorrect)
• "burger king" https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=burger+king&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.country=US&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012 First result: "label": "Burger King, University, FL, USA" (correct)
• "burger" https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=burger&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.country=US&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012 First result: "label": "Biff Burger, St. Petersburg, FL, USA" (incorrect)

Although it isn't present in the above queries, I recall an example where a result outside of the country was returned. Setting boundary.country=US might be a solution for that problem, but would perhaps indicate an issue with the boundary.rect parameters not fully working.

[barbeau]

If you type burger k, starting with the k and all remaining letters of i, n, and g, on mobullity.forest.usf.edu we currently show this:

Are we maybe not encoding the space correctly? Or maybe it gets double-encoded? We're not hitting the Pelias API directly from the browser, so it goes from browser to OTP to Pelias to OTP and back to browser, so it's possible something gets mangled in there somewhere.

[jmfield2]

Hm, So far I'm not getting the same results for "burger k" when looking @ Pelias directly, but it does do something a little weird still:

https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=burger%20k&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.country=US&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012

(or burger+k) "label": "K, East Lake-Orient Park, FL, USA" "query": { "text": "burger k", "parsed_text": { "street": "burger", "query": "k" },

So, perhaps there is a way to force pelias not to try to parse the query like that

[jmfield2]

Looks like adding "quotes" helps, but still somehow ignores the focus point setting.

https://search.mapzen.com/v1/search?api_key=search-hAyPn56&text=%22burger%20k%22&sources=osm&focus.point.lat=28.061062&focus.point.lon=-82.413200&boundary.rect.min_lat=27.279&boundary.rect.min_lon=-82.851&boundary.rect.max_lat=28.375&boundary.rect.max_lon=-82.012

[jmfield2]

I think the issue of it ignoring the boundary parameters via the geocoder may be due to using the Stringbuilder w/o url encoding the inputs (which is why burger+k gives results outside the US), but does not explain the focus point anomaly which happens even when hitting the API directly.

[barbeau]

@jmfield2 For the Pelias results issue, could you please open an issue on the Pelias project (https://github.com/pelias/pelias) and tag me?

[barbeau]

The pelias-client-library has been updated to support the autocomplete endpoint (https://github.com/CUTR-at-USF/pelias-client-library/blob/master/src/main/java/edu/usf/cutr/pelias/AutocompleteRequest.java), so we can test with this.

[barbeau]

We get higher rate limits for the Autocomplete vs. Geocoding API (50,000 instead of 25,000), so we should switch to this, as we're currently hitting our quota.

[barbeau]

Mapzen just today announced that they are shutting down: https://mapzen.com/blog/migration/

We'll need to stop using the Pelias Search entirely, which is what we're currently using for general geocoding (i.e., not hard-coded POIs like buildings at USF).

Here's what they suggest for going forward:

Mapzen Search For search and geocoding, you may want to consider these services:

Nominatim OpenCage Data OSMNames Mapbox Search API

Mapzen Search was backed by Pelias, an open source project. Read below for how to run this service locally. ... Search | https://github.com/pelias/pelias-doc

[barbeau]

An update - Pelias lives on as an open-source project: https://github.com/pelias/pelias

It's currently maintained by Cleared for Takeoff, a consultancy formed by the engineers that worked on Pelias at Mapzen.

They host Geocode.earth, which we could use in place of the hosted Mapzen Pelias instance: https://geocode.earth

It's a paid service, so we'd need some level of funding. They do have special pricing for open-source projects.

Or, we can still host Pelias ourselves.