Everything vegan is also vegetarian. Thus from the current diet:vegan or diet:vegetarian we can add the other one based on the current map state:
Current tag
Suggested tags
Affected nodes/relations
diet:vegan=only, diet:vegetarian not set
diet:vegetarian=only, diet:vegan=only
2172
diet:vegetarian=no, diet:vegan not set
diet:vegetarian=no, diet:vegan=no
5982
diet:vegan=yes, diet:vegetarian not set
diet:vegetarian=yes, diet:vegan=yes
6154
The primary benefit is that adding these additional tags would allow for easier searching.
Since these affected nodes are quite sparse, I would create a changeset for every affected object, and run this script regularly.
What do you think?
I have created a wiki page here: Automated edits/wombotmaper - OpenStreetMap Wiki
Automated additions like this feel like data duplication to me. Most of these keys, as well as their implications, are understandable by humans, e.g., if a place offers vegan options, it implies (at least for me) it offers vegetarian options, as well as pescetarian and other sub-types.
Thereâs the implications of the various types of vegetarianism (ovo, lacto, pescetarian etc.), as well as between diet:vegetarian=*, diet:non-vegetarian=* and diet:meat=*, all of which have their own, very specific, use cases.
I frequently visit fully vegan places (yes, Iâm that kinda girl) and tag these with just diet:vegan=only, since any implied keys would be redundant. For me, itâs like adding bicycle=yes onto a cycleway. If itâs vegan, itâs also vegetarian (yes maps to yes and only to only as far as I can tell, however diet:vegan=no cannot imply any value for diet:vegetarian=*).
Further remarks (commenting on both previous posts):
You claim adding extra tags would make searching easier. However, I assume most applications support at least diet:vegan=* and diet:vegetarian=*. I feel like this is the responsibility of both the application and user performing the search, not OSM. If I would hypothetically go out with friends and we need vegetarian options, I would also tick a box for vegan options in an app, since it also fulfills our needs.
diet:meat=* has use cases very different to diet:vegetarian=*, and one can argue it shouldnât be in the diet:*=* scheme. Its wiki page has some information. I wouldnât perform any automated edits regarding this key or diet:non-vegetarian=*.
Keep in mind that there are tags outside of the diet:*=* scheme that imply or are implied by diet options, e.g. drink:*=* and my Belgian favourite: friture:oil=*.
âEverything vegan is also vegetarianâ and âdiet:vegetarian=only is not the same as diet:vegan=onlyâ: no, it is not the same, however I think most people would agree anything which is considered vegan is also considered vegetarian. If you know a place is diet:vegan=only, you should assume they donât serve toast with eggs or coffee with animal milk. Worst case, check the menu! And trust me: coffee with oat milk is pretty tasty, not everything we vegans eat tastes bad.
TL;DR: I feel like automated addition of these tags is redundant because the values are implied anyway, and, as with any automated edit, errors can be made.
So you would like âdiet:vegetarian=onlyâ to only be used for vegetarian but non vegan cafe?
Even if these cafes only have vegetarian options?
I feel like your usecase is a very small edge case that is better surved if this hypothetical user would search for âdiet:vegetarian=only AND NOT diet:vegan=onlyâ.
Far more users could use more diet:vegetarian tags to know if places have vegetarian options than those who care if those are also vegan.
I mostly focused on vegan / vegetarian for now since I know these the best and they are the most popular.
I think this makes it unnecessarily hard for vegetarians to find vegetarian food, since they would now need to search for places with diet:vegetarian=yes OR diet:vegan=yes OR diet:ovo_vegetarian=yes OR diet:lacto:vegetarian=yes (and the same thing with only). It also requires users to have special knowledge: Not everybody knows what vegan or many of these special diet types mean, and are now expected to infer what many different diet tags mean for their diet. Sadly not all tools / applications do this correctly.
I feel like in this case the slight data duplication is worth it for the ease of use. And considering that 79% of nodes with diet:vegan=yes already have diet:vegetarian=yes, this data duplication already seems to be normalised.
I agree with this, seems a bit weird to me to, was planning to avoid it.
But if youâre talking about âfar more usersâ, letâs consider how many users are impacted by this suggested edit?
looking for OSM POIs that are vegetarian or that are vegan
doing a basic search⊠writing a search query by hand?
happen upon a POI tagged with one but not the other
that POI isnât vegetarian=yes and vegan unset, which I would guess to be the most common case
I donât really think itâs that common.
OK, but how does this look in practice? How do interested data consumers actually implement this? I doubt most vegetarians are writing Overpass queries when looking for a place to eat â even one as simple as diet:vegetarian!=no. Are there any OSM-based websites or apps that target veg*n diet options? What search queries do those perform?
Aye, veggiekarte is probably the most popular. From a brief scan of the source code it seems to consider diet:vegan, but none of the other diets. osmand however does not.
And this explains where my confusion came from: (1) some details I didnât know about and (2) the requirement for a certificate. The wiki page does mention it, but Iâm simply not used to diets requiring a certificate.
I donât think I am, although I might have phrased it poorly. My point is that I agree with @wombatmaper that diet:vegan=only and diet:vegetarian=only are not the same. Indeed, the latter might include their breakfast with toast and eggs. However, the former implies the other, and yes, that might mean the place youâre looking at serves food you donât like, however that doesnât mean it canât be classified as vegetarian.
I donât think we should tag based on what applications support and donât support. It can be a good thing for newly introduced tags (e.g. when inventing a new value for crossing=*, applications need time to adapt), however the diet:*=* scheme is well established. If data consumers choose to not implement well documented tags, thatâs an issue on their side.
Remark on data consumers: MapComplete supports filtering for vegan, vegetarian, halal, organic, sugar-free, gluten-free and lactose-free places (in the restaurant theme). They consider diet:vegan=* for the vegetarian filter too.
Other general remark: apart from yes, no and only, two more values are in use for diet:*=* keys: limited and on_demand. Itâs very hard to make implications here.
Also, the wiki page for diet:vegan=* states: âBy tagging diet:vegan=yes or diet:vegan=only, the tag diet:vegetarian=yes or diet:vegetarian=only, respectively, is implied â i.e., all vegan food is vegetarian by definition (but not all vegetarian food is vegan).â
Again, I would not perform such automated edits at all, and I feel like at least some people agree with me.
I can see the benefit of separate tagging diet:vegetarian and diet:vegan. Data users do not have to interpret the diet flags and users get what they search for without having to enter two search terms if they want to eat vegetarian.
The first proposed change, diet:vegan=only without a vegetarian tag, is not correct. It should be diet:vegetarian=yes. Not âonlyâ because that would exclude the vegan. You canât have two onlyâs.
The second proposed change, diet:vegetarian=no without vegan tag, is correct. If itâs not vegetarian, it canât be vegan.
The third proposed change, diet:vegan=yes without vegetarian tag, is correct: if itâs vegan, itâs also vegetarian.
This is just about the logic, I do not really have an opinion about the mass edit I wouldnât bother, but I wouldnât oppose either (if corrected as argumented above).
(BTW I eat vegetarian, my wife tries very hard to eat vegan. So weâre in the target audience.)
I am against this mechanical edit. Any mechanical edit gives data consumer the impression that the data is more up to date than it is.
As other users mentioned, adding additional diet:*=* tags makes editing POIs more difficult â at least for those mappers who are no experts of diet tagging.
If the edit can be done completely without human supervision, any data consumer can apply the changes themselves on their dataset.
I agree that this particular automated edit isnât a good idea, but not for this reason.
The timestamp of the last change is clearly not in any way a reliable signal of how up to date a POI is. Anyone attempting to use it for that purpose is doing shoddy work. It is perfectly ok to improve one detail about an element without re-surveying all the other tags on that element at the same time.
True, but if someone modifies a âdiet:â tag on a restaurant I would be
very tempted to assume that the restaurant at least still existed when
the edit was made!
Alas I can think of examples where that wasnât the case - I believe that mass edits for âall branches in chain X offer vegetarian foodâ have happened. It might have been Wetherspoons in the UK, or I might be misremembering.
Look through the full history, ignore bot=yes changesets, limit your consideration to changes to the properties you care about. Of course, thatâs still just a best guess that doesnât really give you what check_date could, but at least it ignores the best-known sources of fake âfreshnessâ.