`recycling:*=only` for recycling containers that accept just one material

Dimitar155 · February 12, 2026, 5:39pm

Hi,

I have a tagging question about recycling containers and wanted to hear what others think.

In my area (Bulgaria), we have yellow recycling bins that look the same but differ by their sticker:

Some accept only PET drink bottles
Others accept any plastic packaging, including PET bottles

Right now, to tag a PET-only container properly, you’d have to do something like:

amenity=recycling
recycling:pet_drink_bottles=yes
recycling:plastic_packaging=no
recycling:plastic=no
recycling:glass=no
recycling:paper=no
...

Which works, but it feels a very verbose and slightly awkward when the sticker clearly says “PET bottles only”.

Using something like recycling:pet_drink_bottles=only would feel more natural to me, but I see that:

it’s not documented on the wiki
usage is very low
some if not all software (e.g. StreetComplete) treats only as invalid

So I’m wondering:

Is there a reason we should avoid only here?
Is explicitly tagging all the =no values the preferred approach?
Has this come up before in other recycling tagging discussions?

Matija_Nalis · February 12, 2026, 6:57pm

(back ref. Recycling quest ignores `recycling:*=only` · Issue #6724 · streetcomplete/StreetComplete · GitHub)

I would refer to Key:payment:* wiki for reference, as it has been having a similar issue long ago. There were two competing schemes invented:

one is similar to what is suggested here payment:visa=only. Unfortunately:
- it only would work good if all data consumers understand only value^[1], and
- it breaks down if e.g. shop accepts visa and mastercard but nothing else
another solution is separate catch-all payment:others=no which solves both of those problems (without introducing new ones )

(e.g. you can do payment:visa=yes + payment:mastercard=yes + payment:others=no; and data consumers who do not understand that :others will still show both visa and mastercard as supported).

That method is also more inline to how other popular parts of OSM work (e.g. access=no + foot=yes + bicycle=yes allows only pedestrians and bicycles are allowed, but nothing else)

Is there a reason we should avoid only here?

As noted above, unless only value is supported by majority of data consumers processing recycling:* keys (which is unlikely as that values is neither documented nor widely used), using only would create more problems than improvements.

Is explicitly tagging all the =no values the preferred approach?

At least for recycling_type=container, I’d wager that =no is implied default for most – i.e. only values specified as =yes exist, and nothing else.

TL;DR: unless people disagree, given that there already is some usage of recycling:others=no, and it is technically superior solution, I’d suggest working on documenting that usage on the wiki (like it is documented for payment:others=no) - and using it, of course.

i.e. mapper has to choose whether it is more important to them for “data consumers which support this tag will know that Visa is the only allowed payment” vs. “data consumers which do not support this tag will incorrectly claim that Visa is not supported” ↩︎

westnordost · February 12, 2026, 10:14pm

Why not simply use

amenity=recycling
recycling:pet_drink_bottles=yes

?

Dimitar155 · February 14, 2026, 7:31pm

One might see the yellow container on aerials and notice it is “missing” some tags (“I know that yellow containers in this region also accept plastic and metal packaging”) and might decide to add those tags. The same can happen when someone is on terrain and mistakenly assumes that it is a regular yellow bin without noticing it’s sticker. recycling:*=only can be a hint to map editors to not allow adding other values and it can be used for validation.

We can reach the same problem as above.

westnordost · February 14, 2026, 8:03pm

Adding recycling:*=* tags from space sounds really dubious. I hope nobody is doing that!

You can also leave a note for other mappers (e.g. note:recycling) to explain that indeed this yellow bin is just for PET bottles and nothing else, if it is a situation that could otherwise be misinterpreted.

watmildon · February 14, 2026, 10:04pm

There’s plenty of other tags that are seemingly yes|no but are extended with other values. See the very common yes|no|separate. only already has significant usage in tags and data consumers need to be aware of that. For example, the takeaway key has only as the second most common value.

As for the “consumers have to support things before we use them”. I think that argument locks us out of tag development in really unhelpful ways. Consumers have to update things sometimes. In general, we shouldn’t be locked to one scheme forever because folks don’t want/can’t update. To me, that’s a dangerous argument.

Matija_Nalis · February 18, 2026, 2:02am

I fail to see how? Can you give an example which would have a problem, and explain how recycling:xxx=yes+recycling:others=no would not solve that problem, but recycling:xxx=only would? As those have exactly the same meaning AFAICT.

Um, you’re aware that values are specific to certain key, right? Just because there exist bronze tag value for material key that some data consumers support, does not imply that somehow data consumers suddenly support bronze value for e.g. surface tag.

And actual usage of only as an (undocumented) value for recycling:* is extremely low (less then 250 usages worldwide out of more than a million keys)

Sure. But if you have an option between introducing:

fully compatible extension that fixes all problematic use cases, and in which all current data consumers continue working well without any extra work, and
incompatibile extension which breaks all current data consumers, and even when they all invest work to upgrade it still fixes only one use case while leaving all the other use cases broken

… then the choice of which extension should be introduced to change the status quo surely should be leaning toward the former rather then latter, right?

(I’m talking about recycling:others=no explained in post above)

watmildon · February 18, 2026, 3:41am

Meeting you with the (unappreciated) tone you have brought to this conversation, “do you know that OSM is a collection of keys and values that can take all kinds of values and it’s up to the data consumer to know that it’s wildly un-standardized?”

There’s basically no key in the database that has a clean set of values. Mappers are always innovating values in keys. If you don’t appreciate or desire that, that’s fine. It’s probably annoying to have to consume. But it is a fact of the map that this happens and any application that doesn’t acknowledge this and try to ride those waves is fundamentally incompatible with the spirit of the project.

If you want more examples of things a consumer may guess are yes|no but have only I suggest you spend like 2 minutes looking at TagInfo. only is an extremely well established pattern in keys of this type. You can pretend that it isn’t but that’s objectively incorrect. The ship has sailed.

Matija_Nalis · February 18, 2026, 4:48am

I apologize if you have misconstrued my earnest question as an unpoliteness. All I was trying to understand is does your opinion matches mine – i.e. that documented values of one key do not somehow automatically translate as values of other, completely unrelated keys. Would you agree with that opinion of mine, or not?

“do you know that OSM is a collection of keys and values that can take all kinds of values and it’s up to the data consumer to know that it’s wildly un-standardized?”

Depends what you mean by “up to data consumer to know”? Data consumers, in my experience, know that it is impossible to support all random (and undocumented) ATYL tags, and thus usually support only:

key=value pairs which are documented on the wiki, and/or
key=value pairs which are not documented on the wiki (if you meant that by “un-standardized”?), but are actually in widespread use

recycling:* = only matches neither of those criteria IMHO. Would you agree with that claim at least?

So IMHO, tagging data in a way which is knowingly going to break most if not all existing data consumers, and will not be implemented by other data consumers in any forseeable future is IMHO sub-optimal (to say the least).

Especially when there already exist more popular and far more effective and less problematic way to solve the same issue which doesn’t break anything and allows for graceful incremental implementations.

Of all the examples you mention, only one is relevant (i.e. uses only value on list of keys with prefixes^[1]), and that one is diet:vegetarian=only. Others are clearly not “keys of this type”.

And that one is poster child why it is even worse idea then usual in some cases (i.e. when there is value overlap): by very definition, it implies all other diet:*=* have a value of no – that is the meaning of =only, right?

But that includes diet:vegan=no, diet:gluten_free=no, diet:halal=no, diet:lacto_vegetarian=no, diet:ovo_vegetarian=no, etc – which are in many cases incorrect (or at the very least unverified) conclusions.^[2]

In any case, to lead back to actionable question of primary importance:

If changing the status quo by introducing a new extension, which of the two extensions would you @watmildon find preferable (and why)?

(I would certainly find former preferable, because is preserves compatibility and is much more versatile and thus fixes a wider range of problems, while not introducing any problems of its own – contrary to the former)

all others are standalone keys with boolean values which have been upgraded to threestate, and while they share some deficiencies, they generally have quite different needs and need different solutions (e.g. it doesn’t make much sense to have organic:others=no in addition to organic=yes, what it would even mean?) ↩︎
Also, judging by a quick look, many seem to contain positive values on other diet:* keys, leading to confusing and misleading combinations. E.g. how does this make sense: cuisine = fish + diet:vegan = yes + diet:vegetarian = only. If anything, I’d use diet:vegetarian=only mostly as an indicator of places which need to be resurveyed… ↩︎

Dimitar155 · February 18, 2026, 6:48am

What exactly does recycling:others=no imply? Anything without =yes isn’t accepted anyway, correct? But if I later add another recycling:*=yes tag, then the meaning of :others effectively changes.

Using recycling:xxx=only avoids this ambiguity. It makes it explicit that the facility accepts exclusively that specific material, without relying on a catch-all :others tag whose meaning can shift whenever additional recycling:* tags are added.

Tordanik · February 18, 2026, 8:37am

What if you have the same problem (you want to tell other mappers “yes, I’ve added all recycling types correctly, your first assumption that some are missing is wrong”), but the container accepts two types of recycling? Having two recycling types with a value of only doesn’t really make that much sense.

Jofban · February 18, 2026, 11:15am

A bit of an antipattern, but normal rules would suggest

recycling=no
recycling:*=yes

would be the way to go. Normally, the recycling=no is implicit (if not tagged otherwise, the material is likely not accepted), but we could extend the meaning to “This is really all there is if it is tagged explicitly”.

Matija_Nalis · February 20, 2026, 1:50am

I would assume the same as payment:others=no implies for payments, or language:others=no for languages, or currency:others=no for currencies etc. – that the list of prefixed values is exhaustive / complete as entered, i.e. that all other unmentioned xxx:* tags are explicitly =no (instead of =unknown).

E.g. recycling:engine_oil=yes + recycling:shoes=yes + recycling:others=no means that only engine oil and shoes can be recycling there, and absolutely nothing else (so recycling:paper=no, recycling:cans=no, recycling:asbestos=no ad infinitum for any possible recycling:*=no).

Well, it depends who you ask. It might be that this assumption is correct. But it is also likely that the mapper only mapped what they saw / had time for, instead of exhaustive search of everything (some of which might not even have recognized tagging yet), IOW it may be the case that the default value for unspecified things is not =no, but =unknown instead.

That is the case with many other things in OSM – e.g. just because some highway does not have lit=yes tag, does not necessarily imply that it is lit=no – while it might be the case, it is just as likely that nobody got around to adding lit=* tag instead.

Since OSM does not have a metadata stating “every detail on this element has been surveyed, so anything not tagged does not exist”, people have devised such tags to emulate such metadata for certain groups.

So, if a shop has payment:visa=yes + payment:mastercard=yes + payment:others=no; it means that they won’t accept your American express card, or your Diners card, or your JCB, or cash, or Bitcoin or whatever. Only Visa and Mastercard.

In any case, if everybody agreed with claim that “Anything without =yes isn’t accepted anyway”, then both recycling:xxx=only and recycling:xxx=yes + recycling:others=no would be equally useless and fully equivalent to just recycling:xxx=yes.

Ummm, yes? If anybody edits the element in any way, then then meaning of that element changes accordingly to their edits? How it could be otherwise?!

If somebody edited that recycling:xxx=only to recycling:xxx=no, the meaning would also change. As it would if they replaced amenity=recycling with amenity=waste_basket, or made literally any other change. I think I’m missing the point here

Um, how? If the editor explicitly supports either variant, it will warn the users and/or forbid adding extra recycling tags equally for both variants.

And if the editor does not support (either of) them, it will again fail to work correctly for both (e.g. StreetComplete which started this thread might result in replacing =only with =yes, or removing recycling:others=no tag; or JOSM might add recycling:yyy=yes in addition to recycling:xxx=only resulting in nonsensical combination which requires resurvey etc).

So both recycling:xxx=only and recycling:xxx=yes + recycling:others=no will fail if editors do no support them. But latter has several other advantages mentioned before so would much preferred if you wanted to explicitly indicate that nothing but the explicitly specified things can be recycled.

In any case, if you want to inform other mappers about non-obvious information about an element, the best way to do that is by using note=* tag whose purpose is exactly that (and which is most widely supported, and works for everything, not just very specific narrow case).

And it works even in StreetComplete (which started this discussion), e.g.:

Dimitar155 · February 20, 2026, 4:08pm

That is not a problem that I currently have. And the situation I’m talking about is related to specialised containers which accept only that type of waste.

That is the point. With =only any nonsensical combination will trigger a red light. The same red light won’t trigger when you have recycling:others=no.

dieterdreist · February 22, 2026, 8:54am

this would only work if real world waste types aligned 1:1 with OpenStreetMap waste types, which is probably not the case globally

Dimitar155 · February 22, 2026, 9:44am

We can always follow basic OSM principles like ATYL, and invent a new recycling:* tag for whatever specific kind of waste a container could be accepting.

Matija_Nalis · March 9, 2026, 3:41am

I think I see what you are shooting for here, but I’m of the opinion that you are assuming way too much there, and that what would actually happen depends heavily on the editor (both the app and the human using it) and only very rarely would go the way you envision . I.e.:

Some will show specific raw tag if they don’t understand it (like Vespucci), which might indeed warn the user that something is wrong (as you seem to envision) - provided they’re fluent in OSM tagging and speak English (which not all of them might be).
Some editors will just show as unknown unspecific values (i.e. default iD without expert raw tags enabled will show - instead of ) - so most users there will not see/understand that it is the “red light”,
Some (like aforementioned StreetComplete) will just silently replace that only with yes (or just remove the tag completely - depending on recycling:$type) without user even having any chance of seeing that “only”.
Some (like EveryDoor) will show that “only” the same as “yes”
Some (like MapComplete or CoMaps, also presumably OrganicMaps/MAPS.ME) will show “only” the same as “no” (I have not tried editing, but it is as likely as not that it would unintentionally further break things on saving too).
iD will also replace the only with yes if user clicks on that preset (so will JOSM, but at least with JOSM it is IMHO significantly more likely users will also have raw tags windows open, instead of fully relying of preset window, so there is a chance they might notice the issue before mangling the data)
what will happen in those various editors on related or unrelated edits is unknown - it might remain the same (with just extra conflicting =yes tags added to that =only, requiring more expert mappers to use their time troubleshooting history), or it might rewrite that =only to =yes, or it may rewrite it to =no, or it may delete that tag completely, or something else.
etc. and those are just few editors; for read-only data consumers there are even more issues.

In short, there is huge amount of problems with attempting using recycling:x=only in practice currently.

We can certainly debate whether it would be better if those problems didn’t exist and all editors and data consumer knew how to correctly handle recycling:*=only; but the fact remains that currently using that undocumented value will cause much more problems then it ever purports to be able to solve.

Thus, my suggesting of using recycling:*=yes + note=* (+ perhaps recycling:others=no) still stands as best approach IMHO; but I’m not going to try to dissuade people any more than I already did, as I have no aspirations of “ordering” people what to do.

While the list of issues with recycling:x=only is certainly nowhere near complete, I think people have been provided with enough information what to look out for and how to make an informed choice and weigh pro/contra for themselves.

So, even I personally think it is very bad idea, feel free to tag as =only if you still prefer that, just as long as you’re aware that it likely will break in various fun and innovative ways, and that you’d have to petition many data consumers for it to have a chance of becoming almost as useful as bare =yes (and significantly more effort if you intend for it to be more useful like e.g. =yes + note=* combination).