Automated addition of diet:vegan/diet:vegetarian

General talk
1

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

In the future a similar approach could also be used for some the following tags:
diet:meat diet:lactose_free diet:pescetarian

2

I disagree with the automatic edit:
‘Everything vegan is also vegetarian.’
That is not the same thing! A café with diet:vegan=only offers me only vegan dishes, but not the selection of vegetarian dishes that I might expect. I might want a vegetarian breakfast: a toast with scrambled eggs and chives and a latte. I might not want egg substitute and coffee with soya or oat milk. vegetarian=only is not the same as vegan=only.
Conversely, if there are no vegetarian dishes, you can’t automatically conclude that there are no vegan dishes either. It may be unusual, but I wouldn’t want to rule it out completely.
So please, if a diet:vegetarian=* or a diet:vegan=* is not set, then please leave it as it is.

Translated with DeepL.com (free version)

6 Likes
3

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.

8 Likes
4

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.

Ehh what? How would this be the case?

2 Likes
5

Then you clearly need to do more research :wink:

I think you’re contradicting yourself further down your own post?

6

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.

1 Like
7

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?

2 Likes
8

I dont undestand what you mean here?

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.

9

This really should be handled on application side.

I am against such automated edit introducing not needed duplication that just makes harder to edit things.

1 Like
10

I would recommend filling an issue or sending a PR

11

AFAIK not really. See say Do foods that are certified vegan require hashgacha? Since these foods cannot contain meat, fowl or fish, can it be assumed they are kosher? – Halacha Yomis | OU Kosher Certification – OU Kosher Certification

1 Like
12

Apologies then, I edited the original post.

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.

13

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.)

14

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.

6 Likes
15

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.

4 Likes
16

(this would probably benefit from moving to a new thread, but)

What would you suggest instead - in the absence of any previous check_date field of any sort, of course?

17

It seems like consensus it clearly against this proposal, thus I will not go ahead with it.
As suggested I have created a issue for osmand here: Vegetarian filter does not find vegan restaurants · Issue #21241 · osmandapp/OsmAnd · GitHub

8 Likes
18

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!

1 Like
19

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.

20

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”.

1 Like