Relation:multifeature

This page has been labelled for deletion.
The given reason is:

this type of relation is pretty much unused. As of a couple weeks ago, there were 3 examples left: [1] [2] [3], of which I deleted the first two. The third one could probably also be represented differently. The documentation here provides examples mostly in the form of multiple shops in the same building. There are already several common ways of tagging this: If two shops are in the same building, but at different positions (even if just the registers are different), then one can place two distinct nodes. Another option is to use semicolon separated values. For shop=*, taginfo lists >4000 occurrences of semicolon separated values. It is not clear what advantage this "multifeature" relation offers over Proposal:Node or other strategies for Multiple values..

This normally means the page title is a bad one, and the content has been moved somewhere better. If a page title is vaguely meaningful, the page should perhaps be a redirect, or hold a small summary for historical interest instead. If you disagree with its deletion, please explain why on its talk page.
The page should now be empty apart from this message (as per procedure). The page history shows what used to be on this page, and allows people to rescue an old revision. We may decide to do this, but otherwise a wiki sysop user can delete this page more permanently at some point. In the meantime we should fix any pages linking to here.
Administrators: check links, talk, history (last), and logs before deletion
This page was last edited by Zimtschnecke at 10:16, 11 June 2026 (UTC) (40 days ago)

Relation type as an container for mapping and linking more then one logical feature at the same physical place, e.g. on the same node.

At the moment there is no possibility to map only one physical place/object e.g. a combined café and restaurant, as café and restaurant. Even if the used keys don't overlap, you may have a problem to decide, which additional keys belong to which feature, maybe throwing away information belonging only to one of the features.

The alternative is to make another node for the same feature, which is physically not there at this place, maybe only linked by the same name, but not logical in the data. The additional shop may have no own name, as shop B is inside of shop A and the name of shop A is linked to the type of business of shop A, so it is misleading for shop B.

See also

• Proposal:Node