Proposal talk:Node

Vending Machines

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

If it is actually one machine which disperses multiple kinds of goods I don't think this the Node relations is a good solution. Without looking deeper in this use case I'd say the prefix solutions as described in Multiple_values would be better but Tag:amenity=vending_machine mentions the semicolon solution so it might be still the most supported one. --Dreua (talk) 16:07, 10 March 2025 (UTC)

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)

As I understand Key:support it would need multiple nodes close to each other or at the same position and the support key would just be a hint regarding which close element a node is attached to. It doesn't solve the issue that you'd need multiple nodes close to or on top of each other. If you'd want to map a pole with a lot of signs on it there would be a lot of nodes close to each other, correct? I think I'd prefer the node relation if it were widely used and supported. --Dreua (talk) 16:43, 10 March 2025 (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)

Naming

I think this proposal should be renamed because it is in conflict with the Node as the basic OSM element. Maybe name it Node-Relation? --Dreua (talk) 16:38, 10 March 2025 (UTC)