[Tagging] Tagging of food declarations in restaurants

[Minh Nguyen]

Vào lúc 13:21 2021-11-05, Toggenburger Lukas đã viết:
> I live in Switzerland where there is a legal requirement for restaurants, hospitals, etc. to declare the country of production for most types of meat in written form (either on the menu or on a poster visible to customers). Furthermore, certain kinds of production methods need to be declared, e.g. the stimulation of growth using hormones or antibiotics. There are further food properties for which a declaration is only required in some cases, e.g. the type of husbandry for chicken eggs: Declaration is required if the chickens had to live in cages, but not if they had access to the ground and the ability to roam around. I assume there are similar rules for other countries as well.

My home country is seemingly on the opposite end of the spectrum when it 
comes to food regulations, so I'll defer to others on the merits of the 
proposal's details. 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.

The current frontier for food service tagging is the cuisine=* key, 
which is often used to indicate menu items. For example, an Italian 
restaurant might be tagged 
cuisine=italian;pizza;pasta;salad;burger;sandwich. [1] Ideally, cuisine 
would be reserved for actual cuisines and notable fare that help to 
categorize a restaurant.

If your proposal gains traction, it could take away some of the 
incentive to overload the cuisine=* key with less notable menu items. On 
the other hand, it would be a lot of work to maintain menus in OSM. 
(Around here, I'm having a hard enough time just keeping track of 
opening hours amid this pandemic!)

> ## Example 3: Origin: Regions larger than a country
> 
> Honey from South America:
> 
>      food:honey:country=South America
> 
> Since Swiss law allows to specify regions larger than one country ( https://www.fedlex.admin.ch/eli/cc/2017/158/de#art_15 (Abs. 4)) for some food, I propose to allow to write out these regions, but would still require/recommend to use the ISO codes for countries.
> 
> 
> ## Example 4: Specifying the FAO fishing area
> 
> Salmon from the Baltic Sea:
> 
>      food:salmon:fao=27.3.d
> 
> The example references the fishing area by code. This syntax is used on the FAO website. (Swiss law uses another syntax using roman numerals (e.g. `27 III d`), see https://www.fedlex.admin.ch/eli/oc/2017/158/de (Anhang 4), but without further objections I would give preference to the FAO style.)
> 
> Another variant could be referencing by english (or local) FAO name (e.g. `Baltic Sea`).
> 
> I would say that the desired tagging should be by code, since it probably has the least chance of getting misunderstood and won't change often. (But it may be harder to map these on the go.) I would still allow english and local names but propose to provide a lookup table and encourage mappers to convert existing (i.e. mapped) entries to FAO codes.

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.

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.

[1] https://www.openstreetmap.org/node/689156294
[2] https://en.wikipedia.org/wiki/UN_M49
[3] For example: https://www.wikidata.org/wiki/Q18783379

> ## Example 6: Custom food names
> 
> Chicken legs and nuggets from different countries:
> 
>      food:Chicken leg:country=BR
>      food:Chicken nugget:country=US
> 
> Both foods are made from chicken. This notation allows to assign the given chicken-made foods to their origin countries.
> 
> There can be arbitrary food/meal names such as `food:Mike's Mega Burger:<something>=<something>`. This will be useful when tagging allergens.
> 
> This style has the disadvantage that it will produce a large number of keys. This might make it difficult for editors (e.g. JOSM, Vespucci) to add tagging presets. Theoretically, we could switch roles of key and value, leading to something like:
> 
>      food:origin:BR=Chicken leg
>      food:origin:US=Chicken nugget
> 
> But this would have disadvantages as well:
> 
> - It would need reordering when tagging, because usually a declaration says "food X is coming from country Y" and not the other way around. This gets more difficult when there are longer lists of food items. The longest I recently saw had 21 different foods coming from 10 countries.
> 
> - The problem we try to solve persists, if one food is coming from multiple countries: `food:origin:BR;US=chicken` (or identical: `food:origin:US;BR=chicken`)

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.

-- 
minh at nguyen.cincinnati.oh.us