Address rank confusion when changing place type

[DiogoConstantino]

I searched for a building

The search link URL is:
https://nominatim.openstreetmap.org/ui/search.html?q=Pavilh%C3%A3o+Paz+e+Amizade

What result did you get?

I did get the build I was expecting to get, however de details displayed are incorrect and different from those displayed on OSM.

What result did you expect?

I didn't expected to see any reference to to some details like node 267932729, or node 3089482423, as they don't exist on OSM, and are incorrect. Resulting on Nominatim, building a confusing address that is also incorrect.

I also note that the postal code that appears is a postal code for a specific part of a street, and on OSM doesn't appear to be associated with this building, or the street associated with the building.

The resulting address is: Pavilhão Paz e Amizade, Rua da República, Loures, Santo António dos Cavaleiros, Lisboa, 2670-469, Portugal

The address should be: Pavilhão Paz e Amizade, Rua da República, Loures, 2670, Lisboa, Portugal

This issue is not exclusive for this building I'm seeing it everywhere on the city where the building is located, other users have told me they're seeing the same problem elsewhere.

[lonvia]

Looks like an update problem. After forcing a recomputation of Loures all is well again. I need to look a bit closer into the root cause but I suspect that a change of the address rank (due to linking with place nodes) requires more invalidation then is currently done.

I've left the old state on some of the servers for further investigation.

[lonvia]

The original problem here is Loures being changed from place=town to place=city. What happens is the following:

• a node place=city is added and the node place=town marked for deletion
• indexing now a) removes the town node and marks the linked administrative boundary for reindexing, b) adds the city node with an address rank of 18 (city district) because it finds itself in a city boundary and is not linked
• next round of indexing updates the boundary, which now again links itself to the city node and takes over the address rank of 18

The result is a total confusion of address ranks.

I have now reindexed all of Portugal on the servers which should fix the output for you. Let me know, if there are still odd results.

The update process still needs to be fixed to prevent the same from happening in the future.

[DiogoConstantino]

I still see some odd things, I'm not sure if they're related:
Here's an example of an address that is still, getting some data from the wrong places, and that it's located on the same city (Loures):

https://nominatim.openstreetmap.org/ui/details.html?osmtype=W&osmid=140335205&class=highway

The W140335205, has multiple relations with entities of the same type, which are impossible, and some also incorrect, and some duplicatedt:

1. place:city Loures (node 25611744) is correct, but duplicated;
2. place:city Sacavém (node 3089482423), is both impossible, that street is fully contained within the same city boundaries, and while Sacavem is located on the same municipality (Loures Municipality), it doesn't share a boundary with the City of Loures, or even the Parish of Loures;
3. place:town Santo António dos Cavaleiros (node 267932729), which doesn't share a boundary with the City of Loures, and while it's nearby, is actually only close to the opposite side of the City of Loures, and this street has only a few hundred meters.
4. place:hamlet Barro (node 283981171), which is very nearby, the street in question is a few meters (maybe even less than 100) from the Loures city limit with Barro, but it's very clearly still within the city of Loures (official signage on location supports this).

[lonvia]

Another example of a boundary changing its address rank and causing trouble: https://help.openstreetmap.org/questions/84693/city-detail-is-missin-in-nomiantin-query-responses-in-helsinki-finland