Proposal talk:Provides feature
We have "Site" relation
We already have proposed the relation Site. It seems to me that the Site relation does the same thing as yours, but has much more recognizable name. The Site relation represents a collection of site parts, entrances to the site and more. --Surly 15:40, 9 December 2012 (UTC)
The Site relation has a completely different description and semantics. I don't see how it could be used instead. --Snusmumriken 16:35, 9 December 2012 (UTC)
Reviving this proposal
After experimenting various ways to deal with complicated situations, typically large buildings with several entrances and several POI, I found out that this kind of relation is the most elegant way to solve the problem and avoid data duplication.
It also provides an unexpected benefit: new mappers will often delete POI when a shop has closed instead of tagging it as vacant. The problem can be easily spotted (looking for one-member relations) and solved (digging into the history of an existing relation is easier than trying to find out the id of a deleted node).
How can we push to have it accepted and endorsed by most apps? Bxl-forever (talk) 23:57, 31 May 2023 (UTC)
Good question. I don't think I've been any good at championing it. I just invented it for a need I had, documented it and started using it with the thought that if it was useful other mappers would also pick it up. But relations are quite invisible by their nature.--Snusmumriken (talk) 06:24, 15 June 2023 (UTC)
How about multiple occurrences with role "target"?
The proposal states that only one occurrence with role "target" is permitted.
Suppose the following situation: a large office building with a single housenumber. It hosts 14 different companies on various floors.
Shall we create 14 relations, one for each POI linking to the address node? (Real example here: https://www.openstreetmap.org/node/2656943187)
Or should one single relation, with one address and many targets, be considered correct? Any algorithm dealing with provides_feature relations should process like this: process each object with role "target", and each object gets the properties inherited from the "address", "entrance" or "parking" roles. Bxl-forever (talk) 00:05, 1 June 2023 (UTC)
Perhaps the restriction could be loosened such that there can be exactly one target and many features OR there can be exactly one feature and many targets. But a situation where there would be M targets and N features would be a mess and impossible to tell what's really meant to go together. --Snusmumriken (talk) 06:11, 15 June 2023 (UTC)
It seems someone has already used the relation in that fashion. https://www.openstreetmap.org/relation/15807565 --Snusmumriken (talk) 10:26, 15 June 2023 (UTC)