[Tagging] Tagging of food declarations in restaurants

Toggenburger Lukas Lukas.Toggenburger at fhgr.ch
Sat Nov 6 20:40:01 UTC 2021


Hi Minh!

Thank you for having a detailed look at my draft!

> However, I do want to point out that we don't yet
> have a detailed tagging scheme for menu items of a restaurant, which
> would seem to be a prerequisite to tagging origins of ingredients of
> menu items.

I disagree: Have a look at the bottom page, most right column of https://www.cochinchin.ch/doc/co-chin-chin-cuisine-menukarte-englisch.pdf This is a typical declaration in Switzerland. This can already give you a good hint to decide if you would like to eat there if you are picky about food origins.

> On the other hand, it would be a lot of work to maintain menus in OSM.

I agree with that statement. I am not convinced that it would be a good idea to maintain whole menus, e.g. because of the size limit in keys and values. I came up with the tagging scheme for custom food names mostly because of allergens and because they sometimes are stated along the meat declaration. What I primarily had in mind was e.g. a fast food shop vending doner kebab (i.e. with a very small number of menu items) and you would want to know about certain allergens that some doner kebabs would have while others don't (maybe sesame?).

> If you'd prefer to stick to standardized codes, rather than names that 
> would differ depending on the local language, the United Nations 
> maintains a standard called M49 [2] that's often used in conjunction 
> with ISO 3166-1 alpha-2 country codes. For example, most operating 
> systems represent the Latin American Spanish locale as "es-419" (compare 
> to "es-MX" for Mexican Spanish). The downside is that these codes are 
> even less intuitive than ISO country codes at a glance.

Ah, interesting to read about it... So that would result in something like

    food:salmon:fao:es-419=Océano Atlántico, Nordeste

?

Hmm, are these used anywhere in OSM already? That indeed may feel weird for people to use. I thought suffixes as described at https://wiki.openstreetmap.org/wiki/Multilingual_names would be the OSM-way to go...

> If you need more flexibility, a *:wikidata key is probably the way to 
> go. Wikidata already has items for the FAO's Major Fishing Areas [3], 
> and you can always create additional items for subareas as needed.

Also interesting!

So in summary, we could have different keys with very distinct meanings:

    food:salmon:fao (for FAO codes)
    food:salmon:fao:es-419 (for local language)
    food:salmon:fao:wikidata (for Wikidata identifiers)

> Tagging schemes that rely on arbitrary keys are very unlikely to be 
> supported by data consumers of any kind. Putting the country code in the 
> key and the foodstuff in the value would at least close the set of 
> possible keys to some extent, making it similar in difficulty to 
> processing localized name tags.

So you are saying that having local names in keys is more difficult to handle than in values? 🤔
Wouldn't we need to a have custom-written data consumer for this tagging anyway?

Best regards

Lukas


More information about the Tagging mailing list