Proposal talk:Node

Vending Machines

Cleaned up Vending these days and I guess you could get around these semicolon combinations for vending=*?

Possible uses

I found one more example for this proposal. A relief (tourism=artwork, artwork_type=relief) directly over a door needs two nodes one over the other to map. Janko (talk) 22:41, 19 July 2014 (UTC)

Why this relation isn't a good idea

I believe this relation is not useful, because there would be a better solution for each use case:

1. Nodes that have the same lat/lon but are otherwise unrelated should just be mapped as that: two nodes.
2. Multiple traffic signs on the same pole are already covered by the traffic_sign=* syntax, and it even lets you distinguish between related and unrelated traffic signs.
3. Things attached to some other object – a pole, tree, wall, building etc. - could be represented with an "attached_to" relation. This would actually express that they are attached, not just related in some unspecified way. It would also be usable for ways and areas, not just nodes.

--Tordanik 16:10, 18 August 2014 (UTC)

I'll reply to your points and have numbered them to make the relation more clear:

1. Nodes with the same "lat/lon" that are completely unrelated are hard to find anyway. For pratical reasons it will be almost impossible to map this that way (because the common editors will reuse the existing node when you click there, you'll have to enter the coordinates manually to do this). You could see this proposal as a convenience method to create and edit these situations (where there is a weak relation, i.e. cases where you'd likely want to move all those objects in case you'd move one of them).
2. the traffic_sign syntax is interesting and covers most usecases for traffic signs, even if it doesn't have syntax to tell which object is above which, and can't handle signs with different operators or similar cases where you'd have some tags that don't apply to all of them.
3. While the "attached_to" indeed seems to be a promising concept, I haven't found any documentation about it. Are you planning to document this? --Dieterdreist (talk) 09:33, 11 November 2014 (UTC)

I have integrated attached_to as a role, it makes a lot of sense. --Dieterdreist (talk) 12:31, 27 June 2018 (UTC)

Saw this, but find support bit cleaner, i. e. the JOSM list of relations for the node lists it's role as support, not attached_to - logically preferred to me. ---Hasienda (talk) 19:51, 10 June 2024 (UTC)

A topic for current OSM model refinement

To me, using relations to combine objets isn't always necessary. It's not so convenient to work with relations in editors and it may imply more processing for consumers.
We should discuss such flaws during the current OSM data model refinement. It could be an opportunity to get better support for various solutions that would ease the distinction between merged features.
To be clear I'm not so keen on increase the amount of relation for millions of merged features.
In France, solution we found for antennas for instance is to link OSM data with external database, as antennas are difficult to describe, even with node relations. Fanfouer (talk) 15:23, 31 October 2022 (UTC)