The other day, I got in touch with a highly productive mapper who, among other things, added nearly 800 objects tagged as amenity=waste_basket;recycling (there were also others who did the same, but not as many as he did).
I stumbled upon these objects accidentally, while browsing the Greater Toronto Area, because they were not rendered as waste baskets or recycling nodes in JOSM or iD, and they didn’t appear on OSM Carto at all.
The mapper has been using this tagging approach for many years, and the reason for it, as he explained, is that these objects represent combined garbage/recycling bins, which are quite common in Toronto. Typically, one side of the bin is designated for garbage, while the other side is for recycling.
The mapper was uncertain about the most appropriate way to tag them and settled on amenity=waste_basket;recycling.
I’m curious if there might be a more suitable method to denote these objects, or if the current tagging is the best approach available.
Well, then because of the amenity=* key, one of its potential values (recycling) has been chosen, to the exclusion of the other value (waste_basket) which actually is relevant to tag on the node. In short, OSM “loses the ability” to express that this is (also) a waste_basket.
The “semicolon syntax” seems correct (to “denote these objects,” or more properly stated, to correctly “denote this dual-purpose object”). What seems incorrect is what downstream use cases (“consumers” of OSM data, like renderers) actually do with this object that has a semicolon-denoted tag. It seems that a particular rendering is what isn’t “liked” in this case, even though amenity=waste_basket;recycling is perfectly correct tagging.
This is an old, ongoing issue in OSM: another case of “aw, too bad: the renderer didn’t render quite to my liking, even though the tagging is OK.”
I agree that our tagging isn’t meant to be “liked” by renderers. It just caught my attention. I noticed this combination isn’t shown as a waste basket or recycling location. It made me curious if there could be something better.
When I said “liked,” I meant “liked” by a human, not necessarily “liked” by a renderer.
Actually, I believe our tagging is distinctly meant to be “liked by renderers.” I mean, not by design (that would be backwards in the OSM-tagging-and-rendering toolchain of “first-design, then-express-as-image in visual display”), but rather “we create a tag, we render it.” (Say, amenity=wastebasket and a renderer designing a small icon of a wastebasket to render, and rendering with when that tag is encountered: that’s normal / typical OSM data and OSM renderer behavior that happens all the time).
The problem comes in as / when renderers (any “downstream use case” of OSM data) doesn’t parse semicolon-delineated values “properly.” In this case, there are two of them (waste_basket and recycling) and a renderer simply “throws up its hands” and gives up, rendering neither of them. That’s not poor tagging in OSM (the tagging is just fine), it is the renderer not parsing-and-displaying in a way that you (as a human) likes very much: the object is effectively rendered invisibly! (It should be one or both icons, not zero of neither of them).
“Something better”? Mmmm, as far as rendering goes, unless you contact the renderer author and suggest and/or help elucidate a fix, that isn’t likely. So the very best thing is to “tag accurately.” Rendering might or will eventually “catch up,” and that’s the best OSM can do right now.
It’s a little unorthodox, as OSM has two important tenets that would be blurred by doing this: 1) is “one object in the real world, one object in OSM” and 2) is “don’t tag for the renderer.”
You could simply make two nodes right next to each other (in geographical space) one tagged amenity=waste_basket the other tagged amenity=recycling. And you’d likely “get rendered what you’d like to see.” But you’d also be (somewhat) violating those two OSM tenets. It’s up to you, but that’s the basic equation going on.
So in fact there are two objects, the waste container and the container for recycling. Mapping those separately would be fine, I think. I have seen fancy street cabinets with 3 and 4 openings for different waste/recycling streams.
Yes, thanks for offering additional input to this, Peter. That’s why I hedged a bit, saying “somewhat” violating the “one object” tenet.
Personally, I’d be OK with multiple objects. But with 800 of them, are you going to do a mechanical edit (and all that entails), or are you going to leave the data as they are, knowing that they are “technically correct,” but they just don’t quite render as you like? Again, “up to you.”
I would probably mass edit the ones I did myself, without too much fuss about what it entails. I would consider that a correction of my own mistake.
Mapping fo the renderer, that it is, in the sense that we map to make a map, so it’s mainly for the renderer. Nothing wrong with that. It’s only wrong if you map in error, to achieve a specific effect on a particular map.
Yes, thanks for offering additional input to this, Peter. That’s why I hedged a bit, saying “somewhat” violating the “one object” tenet.
one could argue that these are 2 objects, a recycling bin and a waste bin. The outer container which puts them together is not currently mapped.
Historically, the semicolon was always avoided, at least for “features” (opposed to properties).
Personally, I’d be OK with multiple objects. But with 800 of them, are you going to do a mechanical edit (and all that entails), or are you going to leave the data as they are, knowing that they are “technically correct,” but they just don’t quite render as you like? Again, “up to you.”
I just had a try at combining them both in one as amenity + amenity_1: Node: 11065888150 | OpenStreetMap & Node: 11065888149 | OpenStreetMap to see what happens? Nothing rendering yet so will check again later / tmw & report back, but I think it should render as the “amenity”?
Have done that in the past as well, where the “double bins” are frequently located in parks Query Features | OpenStreetMap & it seems like recycling usually wins?
I’ve never seen the amenity_1 convention before; that’s new to me and maybe I’m learning something new (nothing wrong with that, and something I hope to do each day of my life!)
AFAIK it is generally frowned upon, because it indicates a violation of the one feature one element rule: something tagged with “amenity” (or some other tags) is generally considered a “feature”, and if you have to put more than one amenity tag on the same object it means you are mixing several things that are considered “features” by the osm tagging system, into the same element.
iD may be suggesting such tags, but afaik it is contested behaviour
From what I’ve heard, using the _1 suffix to specify multiple values for the same key is considered to be a dated practice, and inferior to using ; separators. This is because it is somewhat arbitrary, making it even harder for data consumers to process. This is demonstrated by the graph of its usage over time:
As you can see, it is now rarely added to new objects, and it looks like there have been mass removals of the tag recently. (I have no idea what happened at the start of the graph! )
In addition, as mentioned above, requiring a second amenity value is often a sign that it actually needs to be mapped as two separate objects, although since amenity describes a service provided by the feature instead of a physical characteristic, I’m sure that there are valid cases where one feature would need multiple amenity values.
The reason iD suggested it to you is that it autocompletes values based on the tags that already exist in the database (i.e. features that have already been mapped). Since the key has been used a few thousand times (even if it has plateaued), iD suggests it – besides, I can’t think of many other keys that start with amenity!
TLDR amenity_1 is suggested because it used to be quite widely-used, not because of any adopted convention.
In my area, I’ve tagged very similar combined bins as follows:
amenity=waste_basket (“this is physically a rubbish bin”) waste=trash;recycling (“you can put general waste and recycling in here”)
And then I’ll add colour=*, material=* and operator=* – I think of these tags as corresponding to the whole (outer) bin, so it wouldn’t really make sense to me to map it as two features.
I reserve amenity=recycling for dedicated recycling containers (they are often designed differently), or anywhere that accepts separated recycling (one hole for glass, another for paper, etc).
Although I now understand that amenity=waste_basket;recycling may be considered a valid option (disregarding the renderers for now), @TwistedSnake’s approach makes complete sense to me.
Physically, it’s still a relatively small container that is easily accessible for pedestrians, and this mapping reflects the dual purpose of the waste basket, catering to both general trash and recycling materials.
Can picture how a recycling_container node already being tagged with multiple waste products, a recycling_bin could have same. Along the riviera here, stuck to sides of bus shelters, in parks and picnic sites and in streets you see many, usually plastic, paper, , cans/bottles, general (3 or 4 way). Found tag used the generalised recycling:waste=yes, no detailing out.
| 
)