Nagold - lnked_place with role=label vs role=admin_centre

[mtmail]

Hi,

In the city (or rather place=town) Nagold there's a neighborhood called Nagold (Kernstadt).

https://www.openstreetmap.org/node/36771170
Part of 3 relations

• Relation Nagold (1177445) (as label)
• Relation Nagold (1177445) (as admin_centre)
• Relation Nagold (Kernstadt) (4621503) (as label)

On a new Nominatim 4.5 (stable) installation of the area both relations get linked to the node. Is that expected? I mean 'Nagold (Kernstadt)' has no wikidata id set and the name doesn't match either.

Or is the OSM wrong? Should the neighborhood not have the city node as label and instead have it's own label (or none)?

nominatim search --query nagold --extratags | jq '.[] | [.display_name, .addresstype, .place_rank, .extratags]'
[
  "Nagold, Deutschland",
  "town",
  16,
  {
    "wikidata": "Q26344",
    "wikipedia": "de:Nagold",
    "linked_place": "town"
  }
]
[
  "Nagold (Kernstadt), Nagold, Deutschland",
  "town",
  20,
  {
    "wikidata": "Q26344",
    "wikipedia": "de:Nagold",
    "linked_place": "town"
  }
]

[lonvia]

label member and same wikidata ID are definitive indicators for linking. One of them is enough to do the linking. Nominatim can't really detect this situation of a node being label in two relations because linking is done from the relation to the node, not the other way around.

Nodes really should only be label of one relation. Doing some internet research it looks like place=town Nagold is 1177445, while 4621503 should be a place=suburb. I'd just remove the label member from there and leave it at that.

[mtmail]

Thanks a lot. I'll make OSM data changes. In my local planet installation "Nagold (Kernstadt)" became the first result for a "Nagold" search but that'll probably be fixed with local reindexing.

[lonvia]

The disadvantage of the linking in this case is that they inherit both the importance from the place node. And then it is just a matter of chance which one you get. (Although #3593 should ensure you get the larger one first.)