
Mapzen Search: An open source geocoding api built on open data - riordan
https://mapzen.com/projects/search
======
andrewljohnson
MapZen Search (aka Pelias) is amazing. We're using it to auto-name routes on
gaiagps.com, and we're rolling out new search features and auto-naming to the
app too.

MapZen makes a lot of great stuff actually. We also use the Mapzen Valhalla
routing engine ([https://github.com/valhalla](https://github.com/valhalla)) to
do trail routing: [http://blog.gaiagps.com/plot-a-precise-trail-with-the-
gaia-g...](http://blog.gaiagps.com/plot-a-precise-trail-with-the-gaia-gps-
trail-finder/).

OpenStreetMap.org recently added Valhalla too - interesting to see competition
between MapBox/OSRM and MapZen/Valhalla. The best mapping tech is being
developed openly now, even competing open projects - that's a fount of
innovation.

------
SlashmanX
Worth mentioning that this is built on Pelias[0] which is an exceptional piece
of software.

[0] - [https://github.com/pelias/pelias](https://github.com/pelias/pelias)

------
jkkramer
I'm confused. The "demo" is just a screenshot? Seems promising but I would
like to try it.

~~~
superneon
There is a Pelias leaflet plugin which serves as a good demo:
[http://pelias.github.io/leaflet-
geocoder/#12/40.7258/-73.980...](http://pelias.github.io/leaflet-
geocoder/#12/40.7258/-73.9806)

Working on a better one that highlights all the levers in the API :)

------
lobster_johnson
This looks really good! We've been looking for something to run ourselves that
can replace Google.

However, I found a few flaws after a couple of minutes of testing.

1\. Neither search nor autocomplete appears to support filtering by fields
other than country? We have an app that needs to filter autocompletions by
state. A focus point might be sufficient if the autocompleter aggressively
sorts results based on distance, but I have yet to meet one that does this (or
allows a tuning of the distance function). A rectangular bounding box filter
doesn't cut it. I guess I'll have to check out the code and see if this can be
added/improved.

2\. The API only returns points, with no boundary information, for street
addresses. We have an app that uses geocoding to match street addresses to
points. But if your address is a bit imprecise and matches an _entire stretch
of highway_ (it happens a lot!), that's obviously not a valid match —
something like "Highway 66" is just wrong. Google will wisely return a bounds
object that you can compute the area for and determine if it's small enough
that it's likely a precise enough location (we use 10m2 as the maximum).
Unlike Google, Mapzen doesn't even tell you that your match is a "route" —
everything is an individual street address. Not sure how trivial this would be
to implement, as boundaries would need support from datasets; OSM has the
required data, OpenAddresses might not.

3\. Street address matching seems a bit patchy. I tried my Brooklyn street
address, and it didn't find it. The building was constructed last year,
though, so maybe it's old data. Can someone from Mapzen comment?

~~~
spectre256
Hi! I work on the Mapzen Search team. Glad to hear you like most of what
you've seen so far. Your feedback is super useful and I think at least some of
it we'll be able to address relatively soon.

1.) We do have a focus point option for autocomplete, with either a soft (will
sometimes show you results far away if we think they're really relevant) or a
hard (only stuff nearby) radius that can be set. Look at the boundary.circle
and focus.point parameters in our /v1/search endpoint docs
([https://github.com/pelias/pelias-
doc/blob/master/search.md](https://github.com/pelias/pelias-
doc/blob/master/search.md)). As you probably realized tuning this for general
use is actually quite difficult, but if you're running pelias yourself there's
nothing stopping you from tuning to your particular use case. But if you're
running your own instance you can also just add a filter by state, since we
already have a state field in all our documents.

2.) That's right, even for our datasets that have polygon data (only OSM and
Quattroshapes), we just take the center point. This is something we want to
add in the future, but it may take a few months at least, since we don't
currently have much infrastructure for handling polygon data. We also have
another awesome team at Mapzen that is working on a gazetteer project called
Who's On First([http://whosonfirst.mapzen.com](http://whosonfirst.mapzen.com))
that should really help by offering concordance between datasets.

3.) This one's interesting, we should be able to fix it right away because NYC
data is generally quite good. Can you check if your building is in
OpenStreetMap([http://openstreetmap.org](http://openstreetmap.org)) or
OpenAddresses ([http://openaddresses.io](http://openaddresses.io) has a
download for the USA, then find the file for NYC)?

~~~
lobster_johnson
Thanks for replying!

(1) Would it be easy to extend to filter by polygon? We want focus + boundary.
We never want results that aren't within the boundary, but this is impossible
with other geocoders because they will sort arbitrarily even if you specify a
focus. For example, if you only want Montana, typing "San Francisco" should
not return the city of SF.

(2) Is there a possible workaround that's easier to implement? For example, if
we can ignore routes (= long roads where no numbered addresses were matched)
that's an acceptable compromise until you support returning bounds.

(3) OSM finds it. The map doesn't have a polygon for it, so it's likely
captured through interpolation. It matches as "house". I can send you the
address privately if you want. OpenAddresses doesn't have it.

~~~
spectre256
1.) Filtering by polygon would be difficult at the moment, although we are
actually talking about creating a separate point-in-polygon service (no
promises as to when yet :P), since we use it during the process of importing
all our data, but the code isn't really generalized (it's at
[https://github.com/pelias/admin-lookup/](https://github.com/pelias/admin-
lookup/) if you did want to take a look). However, adding filtering by state
is pretty easy. It works the same way as our country lookup: at import time we
do point-in-polygon lookup for countries, states, neighborhoods, etc for
everything, and then record that as text fields with a consistent name in the
actual documents we put in Elasticsearch. Then you can just query the text
field and since the names of countries (we use ISO-3166-1 alpha2/3 codes) and
states are pretty well defined, it works quite well.

2.) Not likely for full polygon data, although we are thinking about doing
something with TIGER data which has street address ranges for the US. I'm not
quite sure what you're trying to accomplish but you're welcome to drop by our
gitter room ([https://gitter.im/pelias/api](https://gitter.im/pelias/api)) and
perhaps we can figure something out.

3.) It's probably poorly tagged data in OSM then, but again, we can chat about
it on gitter more if you'd like. We re-import data once a week, so if you
wanted to make changes to OSM, they should start showing up by Monday.

------
aembleton
I've signed up for a api key, but I can't work out how to use it. I can't find
any documentation.

I've tried using the curl example provided in
[https://github.com/pelias/pelias](https://github.com/pelias/pelias) and
appending api_key=$apikey to it but I just get an error back saying that this
is not a valid key.

Has anyone found any documentation for how to use this API?

~~~
aembleton
Just found the documentation here: [https://github.com/pelias/pelias-
doc](https://github.com/pelias/pelias-doc)

~~~
riordan
My bad, we moved the main domain over to search.mapzen.com from
pelias.mapzen.com and hadn't updated the documentation for the project
background repository!

We're super flattered over all the attention and we're listening for any
feedback.

