No house numbers found in part of interpolator bug all tags seem correct #4925
Comments
|
Author: fernando.trebien[at]gmail.com A correction: the range 555-1855 has never really worked, not even when the interpolator was split. Maybe the range is failing some sanity check because it is so wide? |
|
Author: lonvia The sanity check ensures that the difference between two house numbers is less than 1000, see [https://github.com/twain47/Nominatim/blob/master/sql/functions.sql#L854 here]. So adding support points with their house number every now and then is the right thing to do. It will also ensure that the error between the real house numbers and the interpolated one remains small. |
|
Author: fernando.trebien[at]gmail.com Thank you. In Brazil this is quite likely to happen because house numbers are assigned based on the distance from the beginning of the way (we always expect about 1 house number for every 1 meter of length). One could simply assign the first and the last number and draw the interpolator next to the way and the result would still be quite accurate over 99% of the time (and definitely not "wrong"). But I understand this is an incentive to improving the accuracy of interpolators globally. I'll let the community know so that we can adjust our import/conversion tools. |
Reporter: fernando.trebien[at]gmail.com
[Submitted to the original trac issue database at 7.20am, Tuesday, 30th July 2013]
Hello,
A Brazilian user is reporting that the following interpolator works only for the highest numbers but not for the initial range (555-1855): http://www.openstreetmap.org/browse/way/217367683
I've checked all tags and they all seem correct: all nodes in the interpolator have exactly the same value in the "addr:street" tag, all numbers are odd (matching the way's "addr:interpolation" tag), and all numbers are placed in an increasing sequence.
I also believe that Nominatim's sanity checks are unlikely to cause this since there is about 1 house number for every 1 meter of length throughout the whole interpolator, which seems quite acceptable.
The user has also reported that initially no numbers yielded results. Then he split the interpolator into segments (one per range) and this made all ranges yield results, but combining the ranges back brought this problem back partially. We decided not to split it again so that you can verify the issue and perhaps tell us if we're doing anything wrong.
The text was updated successfully, but these errors were encountered: