Potential for Node / Support / Mast Relation

General talk
1

Hello OpenStreetMap community!

Recently, in the tagging mailing list (archives) I brought up the topic of node relations again. Essentially, this would be a way to convey a set of elements (node|way|relation) that share a common lat/long value and are related because of their common support element.

Use Cases

  • Sign posts
  • Traffic signals
  • Telecommunication towers
  • Flagpoles with multiple flags
  • Micro-mapping things like banners on a lamp or utility pole.

Some Thoughts
This aims to avoid or simplify the process of overlapping nodes. While the wiki does state to “map on the ground,” I would counter that we should map what is actually there. In the world, many things exist on grounded supports that would be beneficial or even critical for some data consumers (emergency phones, for example.)

The question of what to call this has come up, originally I went with mast to try and be generic, however quickly came to the realization this is not as generic as I originally thought. support has been suggested, however my concern is then OpenStreetMap would have support as a tag on a node|way|relation, a relation type, and (as also discussed) a relation role. The support role is particularly useful in this relation as this can apply to many types of supports, big and small.

Proposal:Node has been mentioned, and indeed where these thoughts originate, this aims to solidify consensus for a more formal proposal to come. We are in the very early stages.

How to Map
One node, tagged as support, with a support role within the relation. Within the relation, multiple elements can be added with their own tags (be it a street lamp, traffic light, sign(s), cameras, utility wire, etc…) These elements should be ordered in the relation from top to bottom as it is in real life, with the support role(s) at the top.

Example: A street sign atop a stop sign, sharing the same pole.

Relation

type=mast|support|node

Street Sign

traffic_sign=US:D3-1 [Main Street]

Stop Sign

traffic_sign=US:R1-1

In the order of street sign (top) then stop sign (bottom).

Some Suggestions brought up

  • layer key should be encouraged / required. Up for debate, but that is a duplication of the ordering on the relation and may confuse relation within the post with relation within the world as layer on a street sign and building are different heights.
  • height or ele on each element should absolutely be encouraged but that level of detail, especially precisely is a tough ask for most contributors (not everyone walks around with a measuring wheel and protractor I have come to learn.)
  • A more generic term is needed than “mast.” I am open to suggestions, giving my thoughts on “support” above.

Major Challenge & Input Strongly Needed
This relation is unique in the sense that its members are not in themselves a node. They exist in the database as an element, but not in the traditional sense as they all share the supports lat/long location. Technologically, I do not see this causing significant issue or expansion of the database any more than adding each element individually would.

The ordering of elements within a relation is currently used in route relations, but has not been applied to other relations so far as I can tell. Opinions are welcome on if this is a logical solution or if layer or some other key would better convey location in relation to the overall relation.

Thank you and I look forward to your feedback here or on the mailing list!

– GA_Kevin (everywhere)

2

I think this is too complicated for many new and intermediate mappers. To keep it simple, you can just map a single tower, mast or pole, map all the traffic signs, antennae and bird houses as separate nodes and give those a support=* tag to indicate that they’re attached to the nearest tower/mast/pole.

1 Like
3

To be fair, these are the more complicated cases. I do agree with creating them at their physical position, on different sides/angles. That’s arguably more micro and detailed.
Tagging to associate implicitly could be acceptable as a spatial relationship to be identified in proximity or clustering analysis. support= does have some issues though, for =wall vs =wall_mounted , and =suspended vs =wire , etc which are faced in lamp_mount= at the same time. https://wiki.openstreetmap.org/wiki/Talk:Key:support#Mounted_instead_of_support_?
However, this can still be considered when they are above each other vertically, for the inherent OSM limitation in 3D. Also when there are multiple poles next to each other,
They could further be considered separately. Referring to =multilinestring , one should be generic without any roles, for vertical overlap only, which I prefer to rename it to =point for consistency. Another one can be for attaching or supporting, which doesn’t need to be limited to points, that can include lines and polygons if needed.
For that matter, I can agree with drawing a short line to connect a device on a arm to a pole. But this seems silly when the device is directly mounted the touching the side of a pole.

4

I don’t necessarily consider that a downside. As I envision it, the key and the relation would essentially serve the same purpose. One would merely make the relationship explicit instead of implicit/spatial.

But as potential alternatives to the term “support”, terms such as “attachment” or “attached_to” would also be quite generic.

I believe you’re mixing two goals here, only one of which I agree with.

Using relations to express that feature A (and A2, A3, …) is attached to support element B, where A and B are themselves mapped as nodes, ways or areas, seems useful.

But because I do not inherently consider it a problem if nodes share lat/lon, I don’t believe we need to look for a solution to avoid this situation. Also, objects attached to the same support element don’t always share lat/lon – they might be large enough that placing the node at each object’s center justifies nodes next to each other. Or they might not even be a node! (Ways are sometimes used to map advertising billboards and screens, to name just one example.)

I’m therefore in favor focusing on that first goal, and avoiding taking too much inspiration from the node relation.

1 Like
5

But because I do not inherently consider it a problem if nodes share lat/lon, I don’t believe we need to look for a solution to avoid this situation.

while I agree it is less of a problem for data consumers, it is clearly error prone if the editor doesn’t implement something to make the mapper aware.