-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Demo assumes "U" is abbreviation for unit #163
Comments
libpostal seems to expand it this way:
I'm not sure why both variants are not being saved in the database:
If we were to save both, I'm not sure how we could know to pick the second one for label generation. The good news is the conflation matching is working great! :) ... so searching for The bad news is the result is returning the wrong label :( For Pelias specifically, this issue can be avoided by using the name returned from the |
looks like we already do this for Pelias:
https://github.com/pelias/api/blob/master/middleware/interpolate.js |
Just found another funny and confusing case of this: apparently libpostal always expands In the Portland metro area, lots of streets start with |
This is the same issue as #234 In Germany I'm seeing this issue as compound street names such as We should revisit this and make sure all versions are indexed and the original form is preserved for display. |
IIRC the original assumption was that since the analysis was symmetrical (ie. libpostal for both indexing and search) that it would be ok, seems that assumption might not be true, or we're not using libpostal at search-time? |
Here's a fun one. It looks like some possibly too naive abbreviation handling is used, at least in the demo. Here, Washington, D.C.'s U street is written incorrectly as "unit street" in the upper left
The text was updated successfully, but these errors were encountered: