Some buildings are wrongfully highlighted with "Street not found"
Closed this issue · 11 comments
This doesn't only affect buildings. I have a lot of nodes around here that aren't being associated with the street even though everything seems to match.
Here is an example of a whole row of address nodes that are incorrectly marked as street not found:
http://tools.geofabrik.de/osmi/?view=addresses&lon=-96.76354&lat=39.26177&zoom=16&overlays=buildings,buildings_with_addresses,postal_code,no_addr_street,street_not_found,nodes_with_addresses_defined,nodes_with_addresses_interpolated,interpolation,interpolation_errors,connection_lines,nearest_points,nearest_roads
Thanks for reporting.
I noticed that connection lines aren't drawn for those nodes, but that doesn't tell me much at the moment.
I'll add a screenshot for reference.
We're probably dealing with two separate issues here...
The case with Anderson Avenue/North 52nd Street is probably caused by a problem with a heuristic we're using: To search for streets to draw a connection onto, we only consider streets which are located "close" (< 0.02° for both latitude and longitude) to the address. The position of a street is approximated by averaging the position of its first and last node. For long streets this may result in missing this street when the address doesn't lie close to the "middle" of the street.
This still doesn't explain the case "Konradstrasse"...
We solved the case "Konradstrasse"... To reduce the RAM usage on the server we split the planet into smaller (slightly overlapping) parts. What we see is an artifact of this process: The left part only contains the buildings on the left side of the street and the belonging street cannot found (on the left part). A connection line is drawn anyway because the right part contains both the buildings and the street. (The data for these buildings is actually stored twice in the SQLite file.)
The way simplification could explain the Anderson Avenue problem but North 52nd Street is pretty straight. The biggest difference between the actual way and a straight line from the first to the last node is ~43 meters. The bend towards the north at the western end is a different street. And it isn't just 52nd Street. If you zoom out in the area there are a lot of false positives all over the county along very straight roads. Some are valid errors but a lot aren't. Maybe this is a separate issue though?
Oh I didn't quite read that right. You're not doing a straight line between the endpoints, you're averaging them to a single point. Yeah, that's going to cause problems out in the country where there is no reason to split most ways.
It wasn't really on my mind that roads could be that long when I was programming this. Roads in Switzerland are usually shorter...
You can BTW see how only addresses on the east and west of North 52nd Street are concerned by this issue. Here is the same street but more to the center and the connection lines are drawn and no error is given.
FYI, the longest road where the tagging was clearly right that I was able to find in OSM was 8.1 degrees long. I found a couple longer in the 10 degree range, but they may have had tagging errors.
@pnorman: Thanks for the hint. On the equator that would be around 900km... I'm assuming this was somewhere close to the poles?
I'm not sure if it's a good idea to increase the threshold to such high values. We better should make the comparison smarter, but currently resources are a bit scarce to do so. A small increase could be a good idea anyway...
I think they were mainly somewhere near 60 degrees in sparsely populated areas of Russia. I saw a few ice roads in there too.
I wouldn't consider either of http://www.openstreetmap.org/way/13226182 or or http://www.openstreetmap.org/way/109030753 to be particularly long ways, so an increase is probably in order.
Both issues raised here have now been fixed; one by a code change, and one by changing the definition of the areas by which OSMI does the processing.