Closed jguo317 closed 6 years ago
The original centroids have been computed as simple mean centroids over the postcodes that are found in the Tiger data. That goes wrong if there are some outliers due to errors or creative assignment of postcodes. A possible solution might be to compute a median centroid. Need to check that.
Another TIGER postcode error, possibly with the same cause: 12345, which should be in Schenectady, NY (see https://trac.openstreetmap.org/ticket/4113)
The 2017 Tiger Nominatim import hasn't fixed it. Nominatim imports it into separate database tables and during a search considers both OSM data (table) and Tiger data (table).
Turns out the issue is in OSM data, but caused by a Tiger->OSM import from 6 years ago. 5 digit numbers got imported into the ref
tag which gets treated as name and has preference over postcode search.
It needs OSM data cleanup and check how many places are affected.
Examples: https://www.openstreetmap.org/way/9261792#map=16/31.1418/-81.4844 https://www.openstreetmap.org/way/286996246#map=16/31.1384/-81.4848
I cleaned up 130 streets. https://www.openstreetmap.org/changeset/56459989
Next problem: Now the query returns no result. https://nominatim.openstreetmap.org/search?q=45401&format=json&polygon=0&addressdetails=1&limit=3&countrycodes=us,ca
The supplemental US postcodes hadn't been updated yet on osm.org. I've done that now and the new postcodes should appear with next night's update of postcodes.
Also needed an update of the word table. Now the postcode is correctly in Dayton, OH.
When I use nominatim to search for the zip code 45401, it returns Brunswick, but it should be Dayton, OH. It seems this zipcode returns incorrect latitude and longitude. The lat and lon for 45401 should be (39.750471,-84.268593), not 31.1319976, -81.4859267)
The url is http://nominatim.openstreetmap.org/search?q=45401&format=json&polygon=0&addressdetails=1&limit=3&countrycodes=us,ca.