I’ve been going about adding amenity=waste_baskets wherever I’ve seen them and sometimes I feel like adding in that it is on a street lamp. But that makes it invalid as we should instead use bin=yes as it is strange to have amenity and highway on the same tag. Not only that, but bin=yes is used a lot as a tag to transit platforms and similar to indicate that there is some existing there.
This does create some confusion between the tags as it’s not super clear of when to use one over the other without going to the wiki and reading up about what the differences are. A lot of places have had the same thought as me which is super clear:
I would map a waste basket attached to a street lamp by creating one node tagged highway=street_lamp and a second node tagged amenity=waste_basket + support=street_lamp next to it.
I wouldn’t consider it good data model design to use an entirely different tag just because the waste basket is attached to a street lamp rather than a wall or the ground. And using two separate nodes also makes it straightforward to add additional attributes such as height, which will have different values for the street lamp and the waste basket.
When I previously suggested this approach in a discussion in the German subforum, I included this demonstration of a 3D rendering in OSM2World (which supports the support=* tag). That’s probably one of the few use cases to even care about what, if anything, the waste basket is attached to.
But they are part of the same node, it doesn’t make sense to have two different tags. I wouldn’t create a building with an entrance node outside of the building itself just so I can specify height, type etc. in a better way
Example on how it looks like with what I mean. This is a street lamp with a bin attached
I would use bin=yes only for bigger features (areas) where you can find a waste basket.
If you mircomap a street lamp, I would use a separate object, amenity=waste_basket. However, as the waste basket is mounted on the street lamp, I would use a type=node relation for the basket:
2 points is the most ideal physically, when 2 features don’t overlap vertically. Fundamentally, =street_lamp may also be argued to not be at the same position as the pole, by considering the light itself. Besides the issue of not having a linearly referenced routable point on the highway= road, similar to =speed_camera .
If you want to use it, type=node is not supported by anyone yet. You still need something else viz bin=yes on the =street_lamp for tokenistic compatibility first.
I don’t like =node itself, as using the same word looks confusing. In accordance with the OGC standard and =multilinestring , making it type=point will be better.
Furtheremore if we want to explicitly link 2 points to show it is on the same pole, drawing a short line between them for the mount may be impractical. Could use eg =site , or invent another eg =multipoint following the industry standard.
They’re only on the same node if someone chooses to map them on the same node. I’m saying: Don’t do that. It only causes problems.
I think of those as two objects. They have two distinct purposes. They have two distinct sets of attributes (one is blue, made from plastic and about 1 m high, the other is silvery, made from metal and, say, 5 m high).
Strictly speaking, their centerpoints aren’t even in the same location. They’re a few cm apart. So placing the nodes next to each other could be argued to be more accurate. But of course, the main reason I’m advocating for it is because gives us two cleanly distinct objects, each with its own set of tags, and because it means that a waste basket which is attached to a lamp will look exactly the same as a waste basket attached to the ground to a typical data consumer (which it should, because that’s not a relevant distinction for most use cases).
I don’t quite get this comparison. We do map entrances as nodes with their own set of tags (entrance=*, door=*, width=*, etc.); we don’t just add has_an_entrance=yes to the building.
If I understand you correctly, what you’re trying to get at is that you want to preserve the semantic relationship that one object is physically attached to the other? But in my opinion, the support=* tag expresses that relationship. It’s not as explicit as a relation (so if you want to create a type=attached_to relation to explicitly link the two nodes, I’m not opposed to it), but with some processing, you can still unambiguously find the closest street lamp.
^ What Tordanik said. They are two distinct objects and should be mapped as such.
The entrance example actually illustrates that point. The entrance node is a separate entity from the building way itself and has different tags, etc… Their relation to each is implicitly expressed by the entrance node being part of the way.
Now, the problem we are facing here with the bin and the street lamp is that there is no way to express this implicit relation between two nodes like we can between a node and a way. However, that should not fundamentally change the way we map the objects themselves. We just need a different way to express the relation between them.
Consider the following: If the street lamp was mapped as a way, would you still add tags for the bin to the lamp object itself? Or would you just add the bin as a separate node joined to the way (like the entrance node on a building)? Why should this be different if the lamp was a node instead?
Ack I think overall I agree with most of the statements, I’ll start mapping it separately for now
I like the idea of Tag:type=node but I think the proposal needs to be taken up again with some examples and a vote before I start using it. Otherwise feels like it’s easy to do it wrong. So won’t use the type until it’s more established and agreed on
