|
Here's the situation: Searching OSM (and getting Nominatim results) for "99 Railroad Ave, Albany NY" gives a number of results. Two of them relevant to this discussion, the ones in zipcodes 12204 and 12205 have virtually the same USPS mailing addresses (99 Railroad Ave, Albany NY 1220x). The problem is that 99 Railroad Ave in Menands, doesn't actually exist -- it's a figment of the US Census Bureau Tiger Data's imagination. (Many roads in the village are numbered 1-99 incorrectly in Tiger.) My question is this - trying to correct the Railroad Ave addresses in 12204 -- how do I go about updating OSM in such a way as to override the (bad) Tiger data? For reference, the only actual address on that road in Menands is 32, for which I have placed a numbered building, but it doesn't stop the other 98 bad Tiger addresses from showing up in searches. (Some background -- in the real world this Tiger data, which I've submitted a request to fix, we believe to be the cause of great confusion for those looking for the Real 99 Railroad Ave in zipcode 12205. Apparently searching in a fruit-named company's map for this address w/o the zipcode will return the Menands address first. As a result we have tractor trailers full of lumber supplies (or worse) trying to navigate turns that are near-impossible. To date we've lost count of the number of street signs run over, and a tree was even knocked into a house by one truck.) |
|
I doubt that there is any solution outside of deleting the bad data from the input TIGER dataset/from the data in the nominatim database which in principle is possible and might be interesting in other situations too (for example in places like NYC where we have complete address data). I expect that we need to let the nominatim devs sleep a bit on the issue and see if they can come up with something that scales and is maintainable. It's an interesting idea but the conundrum is if we accept that the Tiger data in a given segment is out of date, how do we propagate that fact via OSM? If a Nominatim server operator could remove the Tiger data it would help - for that server and that instance, but not necessarily all. Really throwing a wrench into this discussion is what happens should the reverse be true - Tiger gets updated faster than OSM?
(16 Apr '15, 03:54)
Daroz
1
I suspect any solution that the devs come up with will have a public black list for the TIGER data with other words anybody using TIGER data with OSM could remove the same data for their nominatim instance (or even for a different geocoder). The rest of your points are probably out of scope in the sense that our primary interest is OSM and if OSM is out of date then obviously the community in the area in question has to get its act together.
(16 Apr '15, 11:15)
SimonPoole ♦
|
So you are not referring to wrong OSM data but to additional Tiger data Nominatim is using for answering US geocoding requests?
That's correct. Think of a road segment with a small number of actual addresses (be it buildings or lots), but the Tiger data has some seemingly larger superset of addresses applying to that same range -- with the Tiger data being incorrect.
If the reverse were true (a larger number of real addresses and a small incorrect subset in Tiger) you could "fix" it in OSM by enumerating nodes/buildings for each correct address, effectively overriding the bad data.
The problem is how to override data that exists in Tiger that shouldn't be there?