Take addr:* tags into account for computing the final address

[cliffordsnow]

When searching for an address in a US Census Designated Place (CDP) with an administrative boundary, the boundary overrides the address tag. The example is search for 7732 234th Place Northeast, Redmond, WA. Nominatim will return 0 results. However, the address is tagged with the following: addr:city=Redmond addr:housenumber=7732 addr:street=234th Place Northeast addr:postcode=98053 name=7732

Omitting the city, Nominatim returns the correct location. Short of removing the admin boundary, I don't know how to correct the problem. I've changed the admin level from city (8) to neighborhood (9) with no help.

I expected nominatim to return based on either addr:city or admin boundary. This is especially prevalent when areas are annexed by cities. Houses in annexed areas may have been using a different city name until annexed.

The boundary, in this case could be removed, but I wonder how many other area might have similar problems.

Thanks, Clifford

[ghost]

I'm also running into this same behavior.

[ToeBee]

I've had problems with this for a long time. Basically, Nominatim completely ignores addr:city tags from address objects. It adds city information to roads based on either admin boundary ways/relations or based on proximity to a place=* node. Then it associates the address points with the road but any addr:city tags are dropped in this process. It probably reduces the size of the database quite a bit to consolidate city information on the road so it may just be a performance thing.

Your search will return a result if you include the name of the CDP boundary: 7732 234th Place Northeast, Union Hill-Novelty Hill, WA but obviously this is not what you need either.

For me it is a problem where the postal city address extends a long way beyond the physical city boundary. There is a hack to get around it that I know works in my situation and might work in yours as well: Add an addr:city=Redmond tag to the 234th Place Northeast way.

An example I have played with to illustrate this problem: Cottonwood Circle

Note the addr:city=Manhattan tag on that way. If you search for one of the addresses along that road like 3706 Cottonwood Circle, Manhattan, KS it finds the address correctly. But if you search for an address along Stony Brook Drive which does not have an addr:city tag, you have to leave the city name off to find it: 6001 Stony Brook Drive, KS Or use the name of a place=hamlet node across the lake: Living Water Ranch

[TO-92]

I am currently investigating a user note on OpenStreetMap where an address is not found even though it is correctly tagged, and I think the issue fits here.

This is the query in question: https://nominatim.openstreetmap.org/search.php?q=Monningstra%C3%9Fe+126%2C+45478+M%C3%BClheim Instead of the actual address it just returns the street.

This is the object that should be returned but isn't: https://nominatim.openstreetmap.org/details.php?place_id=95202861

Nominatim ignores the addr:street tag here and attaches the building to the nearby "Steinbruchweg". From the indexing documentation in the OSM wiki ...

3. A nearby street with the name given in addr:street of the feature we are in or the feature we are part of
4. The nearest street (up to 3 miles)

... it seems that the implementation of "nearby" in step 3 is too restrictive, probably much more restrictive than the 3 miles radius in step 4 (the street is no more than 2 km away). So IMHO Nominatim should either allow a larger search radius, or - even better - consider all streets for a match that have the same addr:postcode, regardless of their distance. The latter might even be faster than searching the whole map within a given radius, depending on the index structure.

[lonvia]

@TO-92 This does not fit the issue as this issue is about matching against tags other than addr:street and addr:place. That said, please confirm that this is not a data error where Monningstr is mapped incompletely. If you can confirm that this is not the case, feel free to open a separate issue about it.

[TO-92]

Ok, sorry - I came from #617 after searching for a related issue and wasn't aware that "addr:*" in the title was supposed to mean "except addr:street" here. You may delete my comments to keep this thread clean if you like.