4 ms·

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

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 11y ago
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 11y ago
  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.

lobster_johnson 11y ago

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 11y ago
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.