From OpenStreetMap Wiki
Jump to navigation Jump to search


These are some suggestions made before this tag was adopted into Map Features:

  • I suggest using cuisine=<value> rather than style=<value> so that it is more obvious what the tag is referring to. MikeCollinson 17:01, 7 June 2007 (BST)
    • changed that, looks better Frank 22:10, 7 June 2007 (BST)
  • FYI, I've been experimentally using a cuisine tag in mapping in Australia, Philippines and UK. I find that I either tag an ethnicity: thai, french, chinese, italian, indian, vietnamese, korean, japanese being the main ones or a particular food type: noodles, fish_and_chips, pie, sandwich, pizza, pasta. I suspect that exact tagging should be left to local country requirements, "chinese" for example, won't make much sense in Taiwan where cantonese, peking etc might be more appropriate. MikeCollinson 17:01, 7 June 2007 (BST)
  • good idea. I was just adding a couple of restaurants today and was missing exactly this tag (cuisine)! The price needs more differentiation, as expensive and really expensive is quite a difference :-) --Cdaller 23:28, 10 July 2007 (BST)
  • I'd also like to see something like provenience=italian, provenience=greek etc. to distinguish restaurant. My main interest is to be able to extract them as POIs in different categories. --SlowRider 14:14, 16 September 2007 (BST)
  • Good idea. In some rare cases a restaurant or fast food restaurant offers two or three cuisines. Then a semicolon separated value list should be used. Toralf 10:29, 5 January 2008 (UTC)
  • Proposal : Ices for ice cream, sorbets etc.. ShakespeareFan00 23:12, 21 February 2008 (UTC)
  • In germany we have small fast food restaurant to which none of the existing values fit. The closest value would be friture but I would appreciate if an international name for it could be introduced like fries. Burger doesn't really fit, because the fewest of these small fast food restaurants offer burgers. Peperkorn --Peperkorn 07:29, 4 August 2009 (UTC)
Und wenn Du mal gesagt hättest, wovon Du redest, dann hättest Du schon eine Antwort bekommen. --Lulu-Ann 21:46, 5 August 2009 (UTC)

Limit to english types of cuisine

I'm on the way to parse the planet with restaurant, fast-food, pub, etc. and I found about 800 types of cuisine. Some of them are local/regional type, some are "national" and some are really by type (pizza, burgers...). While keeping the list open (of course), I suggest to reduce to "english adjectives" words to qualify this field. --Marc 21:06, 20 December 2009 (UTC)

If you are going to have brazilian restaurants on that list, than the region names capixaba, baiana, mineira and gaucho is needed, as these regions serve very different food, and restaurants for these regions are found through all of Brazil. Outside of Brazil I guess they all come under the term "brazilian". Many of these restaurants in Brazil are only tagged regional, something that not really marks the difference between the capixaba and mineira restaurants, side by side. --Skippern 01:26, 21 December 2009 (UTC)
Of course for local food types, the only way to give a type is to use the local name of cuisine, this is also available for regional food. --Marc 08:21, 27 December 2009 (UTC)

cuisine also for amenity=cafe

I suggest to use cuisine also for cafes, like it was discussed on the proposal (but it's not shown in Map Features now).
Most needed tags are: coffee_shop (that's the default), tea or tea_house, ice_cream, bagel, donut, cake (for sweets). --Walter 18:12 15 January 2010 (UTC)

  • Coffee_shop is a special term in the Netherlands, which has only sparse relation to coffee. I propose to use coffee, tee and your other suggestions. --EvanE 18:38, 15 January 2010 (UTC)

Suggested Corrections

  • seafood is used more than sea_food, according to Tagwatch. English dictionary confirms that it is a single, non-hyphenated word.
  • Cantonese is normally transliterated with a leading "C", not a "K". Tagwatch confirms no usage of Kantonese or kantonese.

AM909 22:36, 5 May 2010 (UTC)

  • steakhouse instead of steak_house; most places spell it the first way, and it is listed as a word in the dictionary

BigPeteB 05:39, 22 June 2010 (UTC)

What do you call it?

I'd like to propose the following:

  • bar&grill - typically burgers, steaks, and the like, with a few other menu choices for variety. Usually has full bar and sometimes TVs showing sports. Most are chain restaurants (T.G.I. Friday's, Applebees, O'Charley's, Chili's, etc)

I'm not sure what to call it, though. "Bar & grill" is the most common name, although not very descriptive (but then the restaurants themselves are usually pretty generic).

We could probably also call it "casual". If you take every "casual restaurant", remove the ones that are specific enough to get another value, everything you'd be left with would be these bar & grill places. BigPeteB 05:30, 22 June 2010 (UTC)

I don't think we should have a "&" in any value... this might mess up urls. --Lulu-Ann 14:52, 2 September 2011 (BST)


I'd like to add cuisine=canteen to the list. The distinguishing feature of canteen food is usually not some specific "type" or ethnicity, but a limited choice of menus, changing daily (often with a rotation period of a few weeks), and, unfortunately, also a "specific" food quality (especially at university canteens, also dubbed "mensa" in some countries); so a user seeing a "canteen" tag would know what to expect. Any opinions on that?-- Oli-Wan 11:16, 25 October 2010 (BST)

This fit's to the restaurant=* (See talk of amenity=restaurant) --Lulu-Ann 14:35, 16 November 2010 (UTC)
See also lunch=* for a menu offering that has a weekly rotation. We usually do not map subjective qualities of things, see stars=*. Bkil (talk) 15:24, 3 March 2018 (UTC)
I think you should use the established tagging of amenity=fast_food + fast_food=cafeteria instead. -Bkil (talk) 08:44, 30 August 2021 (UTC)

religious requirements

to account for the identification of religious requirements for the preparation of food, I recommend the inclusion of the key

Feel free to add other keys. -- User 5359 09:43, 30 August 2011 (BST)

Missing cuisine types

  • cuisine=teriaki or something like that, not sure actually how to spell it, as I have seen varios spellings, and not entirely sure if this is to be sorted as food type or etnicity or regional. I just know that if there is one close when I am travelling with my familly, I would drop by so my wife could experience a real Teriaki grill :) --Skippern (talk) 15:07, 2 February 2013 (UTC) Bkil (talk) 15:21, 3 March 2018 (UTC)
Also Please add cuisine=soul food for Southern United States and African-American cooking and cuisine=cajun/creole for food from Louisiana. Koavf (talk) 22:24, 7 August 2014 (UTC)

adding the possibility of separating the values via semicolon to the wiki

I would explicitly state this possibility in the wiki if this is ok!? As there are restaurants that offer different kinds of cuisine this seems to be very useful to me. --Mojo Dodo (talk) 20:38, 15 August 2014 (UTC)
I am also interested in multi-values for cuisine. does it exist?

  • punctuation separated values?
  • create as many key:cuisine as values?

--Hellopierre (talk) 12:27, 14 December 2016 (UTC)
I have found a dedicated page Semi-colon value separator but no real answer
--Hellopierre (talk) 13:13, 28 December 2016 (UTC)

+1 to use this. Or one of the alternatives (it requires some kind of consensus to have such a change)
But at least this page should be explicit that we can have multiple values. Tuxayo (talk) 11:43, 9 May 2018 (UTC)
From looking at it is in us and appears to mean that all listed values are true. So it is impossible to mark "seafood served in a regional Swedish tradition" as cuisine=seafood;swedish or cuisine=seafood;regional rather means "seafood cuisine and more general Swedish/regional cuisine is primarily served here" Mateusz Konieczny (talk) 15:15, 19 December 2021 (UTC)

Tex Mex food

How do you tag a place where they serve Tex Mex food? Most Mexican restaurants in the US are actually Tex Mex restaurants. (See also: ) --ALE! (talk) 14:49, 6 January 2016 (UTC)

Should we add the "grill" value?

It's use 600 times

I would say that it's relevant as many restaurants display this information. So thats help to define their cuisine. Tuxayo (talk) 11:40, 9 May 2018 (UTC)

Mass convert vegan and vegetarian values


According to taginfo, there are ~2500 elements with cuisine=vegetarian or cuisine=vegan. These values are deprecated and should use a diet: tag instead. (Also, this prevents displaying these elements in application like OpenVegeMap.)

Do you think it would be possible to do a mass-edit to replace cuisine=vegetarian with diet:vegetarian=yes and cuisine=vegan with diet:vegan=yes? --Rudloff (talk) 15:47, 28 December 2018 (UTC)

I agree, it will improve the quality of services like OpenVegeMap. These elements should be retagged with diet:vegetarian=only and diet:vegan=only to avoid having to go through this process manually and maybe a FIXME tag with the mention : "This place was edited to replace the deprecated cuisine:vegan to diet:vegan=only, please confirm if all the options are vegan or change the tag value to yes" and the same message with <vegetarian> instead of <vegan> for the other part of the batch --Rouelibre (talk) 09:59, 13 November 2020 (UTC)

It is possible, see Should be doable with JOSM, but needs acceptance from a community Mateusz Konieczny (talk) 10:39, 13 November 2020 (UTC)

I disagree. Vegetarian restaurants are a distinct style of restaurant (vegan very much less so) and quite distinct from a a generic I can get vegetarian food here which is what "diet:vegetarian" says. Just because the dietary requirements and the style of restaurant are aligned does not mean that the tags mean exactly the same thing. For instance in Paris in the 1970s/1980s/1990s finding places which did diet:vegetarian largely meant a few specific cuisines perhaps with a limited number of suitable menu items (e.g., pizza, greek, mexican, indian), and actual restaurants with a full vegetarian meny were very few & far between & specialised (I had a friend who's brother owned one). SK53 (talk) 21:10, 27 December 2020 (UTC)

Separate cuisine from food type

Of the established values for this tag, many are cuisines (that is, cultural cuisines, typically corresponding to geographies or ethnicities) while many others are categories of dishes that transcend cuisines. This creates consistency problems as well as a potential for bias against certain cultures.

For example, Sbarro is most commonly tagged cuisine=pizza based on food type, despite their Italian tricolor branding. By contrast, Taco Bell is most commonly tagged cuisine=mexican, a cultural cuisine tag, while this wiki page recommends a much less common cuisine=tex-mex, even though neither Texas nor Mexico figure prominently in their branding (or, frankly, their fare).

cuisine count
pasta;italian;pizza 1
italian 24
pizza 37
Taco Bell
cuisine count
Mexican-American 1
mexican;fast_food 2
american;mexican 3
Mexican 4
burger 5
american 8
tacos 9
tex-mex 11
taco 22
mexican 2295

Consistency aside, the dual purpose of the cuisine=* tag means some cuisines are subordinated to others. (One proposal above would do so explicitly.) The "Type of food" and "Type of dessert" sections currently make plenty of distinctions between European and American dishes but few distinctions between the dishes of other cultures.

In Vietnam, should the vast majority of restaurants be cuisine=vietnamese, or should mappers there invent new values for the major distinctions in that market? If a restaurant in Vietnam is tagged, say, cuisine=broken_rice because it specializes in cơm tấm, shouldn't a restaurant with a similar menu in the U.S. be tagged cuisine=broken_rice as well?

One possibility would be to say that cuisine=* should be based on the distinctions in each country, ignoring consistency between similar menus in different countries. But what happens in ethnic enclaves that are also frequented by the general population? Most Americans would expect the cơm tấm restaurant to come up in a search for "Vietnamese restaurants", but Vietnamese-Americans might perform a more specific search, because the restaurant is located in a neighborhood chock full of Vietnamese restaurants. Right next door might be a Vietnamese sandwich shop. Two adjacent Vietnamese restaurants might specialize in soups that, to the ethnic community, might be considered completely unrelated (such as phở versus bánh canh).

So another possibility would be to expect ethnic restaurants to always be tagged with two cuisines: a type of food and a culture. But at that point, why not introduce separate keys for the two kinds of cuisines? This post from 2015 proposes culture=*. Similarly, cuisine:region=* was suggested in OSMUS Slack, though it would be a poor fit for cuisines that aren't tied to a specific region, like cuisine=jewish. Alternatively, we could shunt the food-type values over to a new key, perhaps food_type=*, dish=*, or food=* (by analogy with drink=*). We could then deprecate the food-type values of cuisine=* and limit the key to cultural cuisines, reflecting the conventional meaning of "cuisine" outside OSM.

 – Minh Nguyễn 💬 03:12, 8 January 2019 (UTC)

Hhhmmm, tough questions. To me there should be a difference in tagging between the cuisine of a restaurant (American) and the ingredient of the main dish served there (burger, or maybe even something like pancakes or tacos. Or for a great example see the entry for "friture"). There's clearly a need for it and it would allow for another level of categorization if nothing else. But it shouldn't then lead to micro-tagging of every style of food or ingredient a place serves or doesn't (there's kind of a related argument going on in the Talk:Tag:shop=car page about how tagging every possibility of what a "car shop" can or doesn't provide with a yes or no key is tedious and micro-tagging. Personally I'm extremely against that type of tagging). Really, there's three things here that could have their own tags whatever we go with cuisine or region or whatever (I.E. American), style (I.E. burger), and ingredient (meat? I really don't know. There's probably a better example for a different style of food, but you get my point).
As a side to that, there's also diet:, which I was surprised to see "vegan" a part of. It could be either a diet choice if the its a normal restaurant that has a vegan side menu or a category of cuisine if its solely a vegan restaurant (where meat eaters like me go sometimes to try something new and to feel hip). --Adamant1 (talk) 05:03, 8 January 2019 (UTC)
I'm also wary of the slippery slope where mappers end up having to tag each item on the menu. In my opinion, the goal should be a holistic categorization, suitable for geocoders that might let the user enter a cuisine or pick from a selection, and also suitable for renderers that might give certain cuisines or food types their own icons. I increasingly think a new key should answer "what kind of dishes does the restaurant specialize in?" (emphasis on "specialize") and cuisine=* should answer "what culture inspired these dishes?" It's also worth noting that cuisine=* is currently tagged on hundreds of shop=supermarket features, where food-type values would make little sense. (A pizza-and-ice-cream supermarket would delight any child, incidentally.) – Minh Nguyễn 💬 06:12, 8 January 2019 (UTC)
@Minh Nguyen: So I put some thought into this and I really like the idea of going with the food tag. Since its already established with food=yes and goes with drink=*. So its more intuitive. The I think it should be done though is with a food:*=* tagging style. Where the first * is the type of food and then =* refines it. As an example the current cuisine=barbecue tag would become food:barbecue=chicken (or whatever meat it is), cuisine=noodle could become food:noodle=ramen. It would also work well for something like cuisine=desert, which could become food:desert=donut or food:desert=cookie. As it is desert doesn't fit well as a cuisine tag in my opinion. There's a lot of tags that doing it this way would make redundant also. So I think it would ultimately help reduce the number of food related tags overall. Plus then we could introduce more key values for more specific things, like currently there's a bunch of bread styles that don't have tags for them that id like to add, but they don't qualify as cuisine in my opinion. Tags like cuisine=wings that couldn't be classified well with a food:* tag could just be either food=wings or maybe food:barbecue=wings (there's probably better examples).
Also, freeing up the cuisine tag just for regions would help make it easier to add more specific regions to the list. There's a lot of places that either aren't on the list, but still have a lot of tag usage (like cuisine=german) or there's sub-regional food that could use tags. Eventually when there's a lot of regions it could be further refined to a similar tagging scheme to food. With something like cuisine:american=creole or cuisine:german=bavarian. I don't think other tags like culture or region will work in these situations. As I don't think sub regions are cultures necessarily (for example Bavarian is more German then in its own distinct culture) and its not how people are tagging them in the first place. Culture only has 82 uses and regional only has 106, despite both being around for a fairly long time. Keeping food region under the cuisine tag also is a lot less re-tagging work. Plus, ultimately I feel like its unnecessary to move it. Whereas food badly needs its own tagging scheme.
or an alternative is something like dish=barbecue + food=chicken or dish=noodle + food=ramen. That would work to and allow for shorter tagging and not necessarily needing a food type key, but it could also possibly lead to people over tagging everything with multiple food=* tags. Which I don't want to see. I think either scheme is an improvement from how it currently is though. --Adamant1 (talk) 09:11, 22 February 2019 (UTC)
Would food:noodle=ramen be a refinement of food=noodle or food:noodle=yes? The latter could be controversial with folks who already dislike the proliferation of service:* tags. – Minh Nguyễn 💬 23:58, 24 February 2019 (UTC)
Id say it would be a refinement food:noodle=yes. That's how it currently is with the drink: tag isn't it? Maybe it would be better to just go with cuisine=*, dish=*, and food=* instead though. --Adamant1 (talk) 05:55, 5 March 2019 (UTC)
"If a restaurant in Vietnam is tagged, say, cuisine=broken_rice because it specializes in cơm tấm, shouldn't a restaurant with a similar menu in the U.S. be tagged cuisine=broken_rice as well?" - I would say yes, but not really sure. Though marking it as cuisine=vietnamese is not wrong Mateusz Konieczny (talk) 15:20, 19 December 2021 (UTC)
"Most Americans would expect the cơm tấm restaurant to come up in a search for "Vietnamese restaurants", but Vietnamese-Americans might perform a more specific search, because the restaurant is located in a neighborhood chock full of Vietnamese restaurants. Right next door might be a Vietnamese sandwich shop." solution (1) maintain some sort of tree (with cuisine=broken_rice as subset of cuisine=vietnamese) (2) have cuisine:region/cuisine:culture for polish/mexican/russian or cuisine:subtype for super detailed classification (@Minh Nguyen:) Mateusz Konieczny (talk) 15:20, 19 December 2021 (UTC)
@Mateusz Konieczny: I used broken rice as an example of how separating the dish from the cuisine would avoid unclear some unclear situations when dishes travel to other parts of the world. My suggestion is similar to your (2) but in reverse: the word "cuisine" already means "region/culture". Overloading this key for individual dishes is problematic, so we should move those values to a new key. – Minh Nguyễn 💬 08:42, 1 January 2022 (UTC)
To bad this never went anywhere :( --Adamant1 (talk) 14:26, 16 November 2022 (UTC)


Anyone care if juice is added as a cuisine. I noticed it's not listed, but it has 400ish uses and is being used as a cuisine key in iD Editor. Usage aside, I think it makes sense for juice bars and other things like that. So it would be worth adding IMHO. --Adamant1 (talk) 09:16, 19 February 2019 (UTC)

@Adamant1:: If you like, you can take a look at my juice bar proposal if you’re interested :). — EzekielT (talk) 10:00, 19 February 2019 (UTC)
Thanks for bringing it to my attention. I actually stumbled on it right after asking here about cuisine=juice. It looks like a good proposal. Feel free to ping me when you do a vote on it and I won't request it be deleted in the meantime ;) What do you think about adding juice to the cuisine list while we wait for it to get adopted though? I think it might be useful even if your tag gets accepted. Either one is better then something like amenity=bar + drink:juice=yes for these types of things. --Adamant1 (talk) 07:49, 21 February 2019 (UTC)

Hot dog

Anyone object to hot_dog being added to the list? It has roughly 184 uses with hot_dog, hot_dogs, Hot_Dogs, and Hot_dogs combined. a good portion of the entries are hot_dog. I'd like that to be the default that the other entries are unified under. I'm aware that the entry for sausage suggests it can be used for hot dogs, but that's clearly not whats happening and to me they are different enough types of food for their own entries anyway. --Adamant1 (talk) 23:36, 21 February 2019 (UTC)

In Hungary, these two are completely different. Cooked/fried sausages ("sült kolbász") are firm and grainy and may contain rice and other stuff, purchased and stored smoked and raw, made in a pan or in the oven, are high in fat, they are eaten with bread, cabbage and pickles, mashed potatoes or even with chips. Hot dog meat is Vienna sausage (so called "virsli") that is soft, smooth and gelatin-like, and cooked in water, then wrap it up in a kifli. See classification here. It is very common to eat cooked/fried sausages at a brick and mortar butcher, while finding places selling hot dogs is much more difficult - their vendors usually operate from mobile vans around events. -Bkil (talk) 20:39, 3 November 2020 (UTC)

Templates for Food and Dessert

Hi, new contributor here, I've been translating the cuisine key and I can't understand the reason behind the need for two templates. Wouldn't it be more logical for them to be in one big "Food" template instead of a "Food" and "Dessert with Apetizers" ? --lejun (talk) 21:04, 20 July 2019 (UTC)

Purpose of tables

@Rtfm: (but also anyone else) is the purpose of the tables to be an exhaustive list of every single kind of food and cuisine out there even ones with zero uses in OSM? Or is the purpose of the tables to highlight "widely" used food and cuisine tags only? --Adamant1 (talk) 03:41, 22 January 2020 (UTC)

I am dubious about adding values that have 0 uses. I would not restrict it to solely to very popular ones but I support removal of ones that are completely unused Mateusz Konieczny (talk) 10:02, 22 January 2020 (UTC)
I'd say the above question should be discussed in a wider format (I don't necessarily mean the mailing list, but a "publicly accessible" place like a new page about "OSM Wiki documentation philosophies / standards"). You could probably create a page with your point of view, then promote it on the mailing list. Generally I think everything which is in wide use in "real life" should be documented, as otherwise everyone invents a new way to tag it, which leads to a big mess (and later to the argumentation that one which is probably less practicable but in wider use is more "established", which then avoids a consolidation). By the way, why got "fish and chips" an own tag, while fish is consumed all over the world, just with different side dishes like couscous, fufu, injera and others (also as filling in empanada, not as a sweet...). Is there probably some old colonialism left as OSM originated in the UK ? rtfm Rtfm (talk) 19:06, 22 January 2020 (UTC)
Nah, I'm good. Also, I'm extremely sick of your repeated hypocrisy about everything. You go off about how doing things through "channels" is bad and refuse to discuss anything things you want to do, but then when someone wants to do something you disagree with your answer is always "take it to the mailing list." I'm good with that one sided none sense. Anyway, it's already been discussed and mostly agreed on, except by you apparently, that policy related to the wiki is decided here. There is no "wiki mailing list" to take things to and for good reason. Ultimately, you got decided against and your wrong here. Move on and accept it. It's ridiculous anyway to treat a tagging table as an exhaustive list of every kind of food or cuisine out there. It wouldn't be manageable after a certain point. It hardly is now. There's nothing wrong with having inclusion/exclusion standards. Making the standard that we don't include things that are in the low or no numbers is perfectly reasonable. There's zero benefit at all to including everything under the sun just for the sake of it. Everyone except you would agree. If you don't like it create a page about it, take it up in the mailing list, blah blah blah blah. Like I said before, go do a mapping party so fufu or whatever cuisine you to be included gets the tagging numbers to justify adding them. I'm totally fine with that. Until then though, I'm deleting your zero (almost zero) use entries. If you revert me again I'll report you to an admin. --Adamant1 (talk) 05:35, 23 January 2020 (UTC)
"I'd say the above question should be discussed in a wider format" - feel free to start such discussion and link to it here. ""publicly accessible" place" - this talk page is publicly accessible. Mateusz Konieczny (talk) 18:59, 23 January 2020 (UTC)
Do you think I should extend this one or create another with more topics ? "Remember that OpenStreetMap does not have any content restrictions on tags that can be assigned to nodes, ways or areas. You can use any tags you like, but please document them here on the OpenStreetMap wiki, even if self-explanatory." Any proposal about the bullet points ? rtfm Rtfm (talk) 17:22, 24 January 2020 (UTC)
Draft created : Wiki_documentation_howto When adding topics, please consider the part with the  KISS principle ("keep it simple, stupid"), otherwise it's hard to  RTFM, see Any_tags_you_like#Style_Guide.3F rtfm Rtfm (talk) 17:50, 24 January 2020 (UTC)
This is a chicken and egg problem. I agree that we should not list every possible food found in the dictionary, but if certain kinds are anticipated to be very common, it can be an advantage if a canonical writing, explanation and photo is available. When I last extended the table with dozens of entries, I went through taginfo and made sure to include ones that are used very often (and did some regularization along the way as well). I then did add a few related items based on some typical menu items, though, so I'm a little guilty here. We haven't yet started mass mapping of cukrászda yet around the country, but after we do, that should bump many kinds of desserts found in Central Europe for example. I can't speak for other nationalities. -Bkil (talk) 20:45, 3 November 2020 (UTC)
"anticipated to be very common." Sure, but by who though? "Rubs chin." --Adamant1 (talk) 14:28, 16 November 2022 (UTC)

Cleanup Request


In the last edit, User:TheAdventurer64 inlined the separate pages with the visual editor. I haven't checked the huge diff, so I'm not sure what changed. The separate pages had remained in place. What is the goal and what are the steps to get there? I think originally the idea behind partitioning this huge page into smaller ones was to improve load time and caching, but I can't be sure. -Bkil (talk) 20:18, 3 November 2020 (UTC)

@Bkil: VisualEditor has a bug that automatically inlined {{Map Features:Cuisine (type of dessert)}} when placed after a transclusion of {{Map Features:Cuisine (type of food)}} on the same page. I worked around this issue in Special:Diff/2231732, Special:Diff/2231733, and Special:Diff/2231734, so we shouldn't see this page get bloated by accident anymore. Additionally, in Special:Diff/2231425, Special:Diff/2231416, and Special:Diff/2231418, I fixed the headings so that they come with working edit buttons when transcluded into Key:cuisine. Hopefully this will help users find the right page to edit. Vivienmic, TheAdventurer64, Jemily1, Aharvey, please take another look at this page and see if your edits need to be redone in the right template. – Minh Nguyễn 💬 22:22, 17 December 2021 (UTC)

Is those 2 parts the same?

Resolved: Per #Cleanup Request.



If so, what should we do to cleanup it?

If not, how to show the different between those 2 parts?

快乐的老鼠宝宝 (talk) 11:15, 29 August 2021 (UTC)(事后补全签名)

@快乐的老鼠宝宝 and Bkil: They are duplicates; see #Cleanup Request. It's clear that TheAdventurer64 intended to make improvements to the dessert section, but the template got inlined either intentionally or unintentionally. It's problematic because the template is also being transcluded on translations of Key:cuisine, apparently all in the name of keeping the translations in sync, but it is complicated. As far as I can tell, most of the changes are minor grammatical changes or clarifications. Since the duplicate tables are causing visual editor to get confused and multiply the table even more, I've removed it in favor of Template:Map Features:Cuisine (type of dessert) for now. I think we should consider unifying the sections and migrating to {{Taglist}} for much easier maintenance. If the separate sections are important, then I think actually splitting up this key would be the better long-term approach. – Minh Nguyễn 💬 07:38, 30 August 2021 (UTC)
Split Key:cuisine may cause a large change to exist OSM data, I think we should consider it more before split.快乐的老鼠宝宝 (talk) 07:43, 30 August 2021 (UTC)
@快乐的老鼠宝宝: Yes, I agree it would be a disruptive change, but in my opinion it's probably necessary sooner or later. In the meantime, {{Taglist}} would be easier to maintain, but first we have to create a separate page about each of the cuisines listed in the article, to avoid losing anything. – Minh Nguyễn 💬 07:47, 30 August 2021 (UTC)

How to create new tags for Main 8 Chinese Great Traditions?

We can find 8 Great Traditions in China's daily life, and I noticed cuisine=american have a more refined type to describe.

"A place that mainly sells American cuisine. Use more specific tags if possible such as cuisine=hawaiian, cuisine=new_mexican, cuisine=texan, or cuisine=tex-mex. "

So how should we tag 8 kinds of Chinese food? Which tag you prefer to use?

---[en ↑][zh ↓]---


--快乐的老鼠宝宝 (talk) 11:14, 29 August 2021 (UTC)

  • Yes, if a restaurant specializes in some of the regional cuisines but it isn't a "generic" Chinese restaurant, use a more specific tag like cuisine=sichuan. (We have plenty of Sichuan Chinese restaurants in the U.S. too. People who don't like spicy food know they should stay away from them. Most of the cuisine=chinese in the U.S. are actually American Chinese cuisine.) Some of these regional cuisines are already mentioned in the article, but you are welcome to add any others that are already in use.
    – Minh Nguyễn 💬 07:45, 30 August 2021 (UTC)
  • @快乐的老鼠宝宝: For better or worse, the cuisine=* values are all English terms rather than terms in the native language, as long as English has a word for the cuisine. In English, it's only known as "Sichuan cuisine" (sometimes spelled differently like "Szechuan"), never as "Chuan cuisine". It would be important for an editor or data consumer to provide the appropriate translation for this tag. In Chinese, that translation would be 川菜/川菜 rather than 四川菜/四川菜. – Minh Nguyễn 💬 18:26, 30 August 2021 (UTC)

Full disclosure: I'm not an expert on cuisines. We usually prefer to use either the most common British term that applies. Lacking that, the canonical page name should be used. When wikipedians name their articles, they exercise due diligence to find out the most often cited and referenced spelling alternative. I also recommend that after you have a set of names that you would like to use, it would be great to send it in a proposal so others could vote on it. Just blindly looking at the wikipedia page, I'd probably go for those listed in the heading, i.e.: cantonese, sichuan, anhui, shandong, fujian, jiangsu, hunan, zhejiang. It should be tagged together with the more common term, like: cuisine=sichuan;chinese -Bkil (talk) 19:10, 30 August 2021 (UTC)

@Bkil: For restaurants in China, I think it would be unfortunate to expect every Sichuan restaurant to be tagged with sichuan;chinese, just because Sichuan cuisine is part of Chinese cuisine. It would be rather like tagging every Taco Bell in the U.S. with cuisine=tex-mex;american, making it more difficult to distinguish a restaurant that serves a variety of "classic American" fare. On the other hand, a restaurant in an ethnic enclave may naturally have that sort of double-tagging: for example, a Sichuan restaurant in the U.S. may carry some non-Sichuan, (American) Chinese fare like lo mein and fortune cookies because customers expect it. – Minh Nguyễn 💬 19:30, 30 August 2021 (UTC)

Could you please elaborate your concerns? Do you view cuisine=chinese as an alias for "American Chinese" cuisine, or do you have issue with listing multiple values on the right? I only added "chinese" to potentially cope with old data consumers or mappers who really can't differentiate between the different cuisines (should that perhaps be "unknown_chinese"?). Note that if the issue is solely with the multiple values, it is not unheard of to tag a (better) cukrászda with cuisine=cake;pastry;ice_cream;petit_four;custard;strudel;cookies;pogacha;pretzel for example (as per User:Bkil/amenity=dessert#Dessert_taxonomy). -Bkil (talk) 20:53, 30 August 2021 (UTC)

@Bkil: No, my concern is that regional Chinese cuisines would be somehow treated differently than regional cuisines of Western cultures, in particular American cuisine (which has a similar geographic scope). To borrow a concept from navigation mapping, I don't think we should be tagging regional defaults.

I don't think the type-of-food or type-of-dessert values are relevant to this discussion, and there doesn't seem to be an analogy for Hungarian cuisine, unless someone has begun more specifically tagging Danuban and Tiszan cuisines. I share your concern for backwards compatibility, but let's consider the practical consequences. Most of the restaurants in any given Chinese city serve some kind of Chinese food. If a renderer doesn't have a special icon for Sichuan restaurants, that's OK. But it would be unfortunate if we were to tag all the restaurants in that city with chinese. Any renderer that has cuisine-specific tags would associate chinese with an icon that emphasizes "Chineseness", particularly for parts of the world where the distinction would matter more. So now we've got a city full of fortune cookie or oyster pail icons.

So what I'm suggesting is that, in China, a restaurant serving fare from across China would be cuisine=chinese, while one specializing in Sichuan cuisine would be tagged cuisine=sichuan but not cuisine=sichuan;chinese. Meanwhile, in Hungary, a Chinese restaurant could reasonably be tagged cuisine=sichuan;chinese or just cuisine=chinese if it isn't known to specialize in one region. This is already how cuisine=american is used. An ideal search engine would recognize that a search for "Chinese restaurants" should include Sichuan restaurants too.

 – Minh Nguyễn 💬 21:13, 30 August 2021 (UTC)


cuisine=kebab is used for wide variety of kebabs. Maybe more specific cuisine=doner_kebab or kebab=doner_kebab would be a good idea for ones like ? Mateusz Konieczny (talk) 00:06, 2 April 2022 (UTC)

Element column in template

The "Element" column in the tables with tags seems a bit redundant, as it's the same for every cuisine=* tag, it duplicates info that is already present in the KeyDescription template and it makes the tables difficult to read on small screens. Would anyone object to the removal of this column? --501ghost (talk) 15:40, 4 April 2022 (UTC)

The same goes for the unused "rendering" column. 501ghost (talk) 08:17, 5 April 2022 (UTC)

Rewrite (November 2022)

I just rewrote the page and the tables to clean up old and misleading information and rarely-used values (There were even some tags with 0 uses!). I hope that the page can be more useful to current mappers wondering what tags to use now. Also I hope it is more useful to third party tool makers or data consumers wondering what tags to include in their software.

I tried to reflect current usages and tried not to make any decisions of what should or should not be used. One unfortunate side effect of this is that by using current usage statistics, there is a clear bias towards places that are already well mapped. Notably, Japanese and European foods seem to be over-represented.

This work was done by building a spreadsheet of the values appearing on the wiki before my changes along with the most-used values scraped from taginfo. Then I sorted them into categories, removed duplicates, and rebuilt the tables.

Anyways, here are some specific pieces of data:

There is some more work to be done:

  • I only used solo tags in my counts. The analysis could be redone while looking at values in longer lists. For example, almost half of the uses of cuisine=lunch appear as cuisine=breakfast;lunch. This might turn up other cuisines that should be included.
    • Update: I did this analysis. The differences are larger than I thought. Some values are almost always used on their own and some are almost always used in a list. For example, cuisine=tea appears in a list 89% of the time while cuisine=tex-mex appears in a list just 3% of the time.
    • I added 8 new tags to the wiki that I had previously missed: brunch, lunch, bar&grill, fusion, beer, wine, savory_pancakes, and gyoza. All have 300-700 uses but I had missed 70-90% of them my previous analysis.
    • This data took quite a bit of effort to acquire and calculate, so here is a copy of the spreadsheet I used in case anyone wants to do their own analysis later: File:Cuisine counts.ods
  • The translations need to be updated. I unfortunately don't speak any languages other than English well enough to do this work.
  • The wiki pages for each tag need to be updated. I'm not sure this is really necessary, since most pages won't provide more information than a description of the cuisine and some automatically collected data. However there is some cleanup that could be done, for example dealing with now orphaned pages.
  • Now that there is better information about what tags are commonly used and which are duplicates, it would be nice to clean up tag values on the map.
  • I think we need to have some bigger discussion about which tags *should* be used, which are officially approved and which are deprecated or not recommended. (Again, my work in this rewrite was just about documenting what is currently used). This could be combined with thinking about the differences between ethnicity and food based values, and whether the food=* and drink=* keys should be used.

-- Graptemys (talk) 19:10, 2 November 2022 (UTC)

Make tables sortable

I think having the tables sortable by the number in the tag usage column would be a nice feature helping readers to find most common tags easily. I'm not sure though if this is realistic to implement!? --Marsupium (talk) 11:09, 16 November 2022 (UTC)

I tried this, but couldn't get it to work. The numbers get sorted as text (1, 10, 11, 2, 3, ...) instead of numerically. There is a way to add a data-sort-value to a table cell but the count information is not in the Taginfo template and I can't figure out how to get it directly from the Taginfo API. If someone can get that number somehow this could be possible. --Graptemys (talk) 15:11, 16 November 2022 (UTC)

Add static count column

The taginfo count is not accurate (cuisine=pizza;italian does not get counted with cuisine=pizza), and is also not sortable. In order to fix both of these problems, I am considering adding another column with a static count to each table. I have a script that can parse the values with semicolons and add them all up, getting a real count of how often each value is used, and if it's in a separate column as regular text it can be sorted numerically.

This would be nigh impossible to maintain. The data would be from a snapshot of taginfo on a single day, it takes considerable effort to download and run and review the results, and then it would be typed directly into the text of the templates. I'm willing to do this once now, and maybe once a year or so as long as I still have interest, but I doubt that anyone else would want to do it. I suppose I could document the process but that would be more effort from me and only be useful if someone else might use it.

However, I think there would be huge benefits. First is that it would be much more useful than the current taginfo2 box, which is not accurate and not consistent across cuisines. For example, cuisine=tex-mex is used alone 97% of the time, so the taginfo2 box is pretty accurate. But cuisine=tea is only used alone 10% of the time, and so the taginfo2 box under-represents its usage by 90%. Anyone making decisions about which cuisines to support in their product would probably benefit from knowing the true usage. That information is not even available on taginfo. Also, being able to sort makes it much easier to find the most popular values, which is valuable for all sorts of use cases, like searching for likely values for a restaurant being mapped, knowing which values to support in a product, or just curiosity.

Do you think this column is worth adding to the tables? Graptemys (talk) 16:08, 19 July 2023 (UTC)

Significance of value order

@JesseFW, Graptemys, and Mateusz Konieczny: We seem to have a difference in understanding about what it means for one value to appear before another when cuisine=* is set to multiple values separated by semicolons, particularly when one value is a national cuisine and another is a dish or food type. Does the order correspond to specificity, signage, importance, the alphabet, or nothing at all? Personally, I think it would be problematic for this article to say it means nothing at all, after mappers have apparently put effort into emphasizing, for instance, an Italian restaurant that serves pizza (as opposed to other Italian fare) and a pizza parlor that serves Italian fare (as opposed to different pizzas, very different pizzas). Needless to say, this problem wouldn't come up if we had split the cuisine values across multiple keys. – Minh Nguyễn 💬 17:50, 17 July 2023 (UTC)

I don't think people are currently putting any order to the values. I tested this by looking at three pairs: american/burger italian/pizza and vietnamese/sandwich, checking the websites for a random sample of restaurants with these tags in the US and making my own determination about which way I would have tagged it. I found that just about half of them I would have tagged the other way. So if some people are putting meaning into the order it's not showing in the data and I wouldn't suggest using or relying on it. It's less problematic to say it means nothing and throw away some work than it would be to say it means something when very few people have been mapping it that way.
Also, having just looked at several dozen restaurants and tried to make a decision about which value is more important, I can say it's a really tiring decision to make. I don't think we should force people try to do that. For most objects you could add detail later, say by adding the restaurant and then someone else can go through and add the website to any restaurants missing it. But with ordered cuisines, there's no way to split that; the person who adds the cuisines would also have to think about the order. Having a cuisine at all is so so so much more important and I bet that requiring people to order them, or even telling them that the order might matter sometimes, would result in mappers skipping the field altogether. There's also no way to know for which restaurants that decision was made and which have an arbitrary order, so you can forget about maintaining the information without redoing basically all the work.
-Graptemys (talk) 21:12, 17 July 2023 (UTC)
I expect that some people put various meanings into order but it is overall hard to distinguish from random order. Basically, case like forest but with even lower chance of extracting any meaning from it. So I would advise mappers to not agonise over order here as it has no real meaning Mateusz Konieczny (talk) 07:15, 18 July 2023 (UTC)
I only added the text about order to try and describe what people might have meant. I'm fine with forgrounding "it probably doesn't mean anything" and leaving the possible meanings as an aside. As for figuring out what to tag, I think we should focus on what is advertised (i.e. on signs outside, or the front page of the website) and lean hard towards using the actual words used -- if a restaurant describes itself "Tex-Mex" rather than "Mexican", tag it as such. JesseFW (talk) 12:24, 18 July 2023 (UTC)
I mapped a lot of restaurant and fast_foods with the cuisine key. The order I use is importance. For sure is not alphabet or signage. Sometimes is just random. So if the restaurant is pizzeria but they sell also some italian dishes, I would tag it as cuisine=pizza;italian. But for an ITALIAN restaurant that main dishes are typical italian dishes and they also sell pizza, I tag as cuisine=italian;pizza. I saw people who are changing my tags to alphabetical order. Although I would agree that the order is of little importance. maro21 20:23, 18 July 2023 (UTC)

@Graptemys, Mateusz Konieczny, JesseFW, and Maro21: Thanks for the quick responses! I suspect we're all right and none of us are right at the same time. :^P

The impetus for this discussion is that there's a proposal to standardize name-suggestion-index on alphabetical order. This means anyone who did imply a particular meaning will likely see that information disappear without a replacement. Eventually, unbranded restaurants may get the same treatment for consistency, for example this proudly Salvadoran pupusería that added Mexican food and sushi as secondary offerings (because not enough customers were willing to wait for a fresh-grilled pupusa to sustain the restaurant). If we say that the order doesn't matter, then the push for alphabetization is inevitable, because people want to see tidy taginfo listings. Call it tagging for the tag statistics, if you will.

Anyways, it sounds like there's some agreement here that an order can't be reliably inferred, but an order might be implied fairly often (if inconsistently). Maybe a broader discussion is needed to make sure the community is comfortable with this outcome, perhaps in relation to this proposal for a food:*=* namespace.

– Minh Nguyễn 💬 01:08, 19 July 2023 (UTC)

No, I would say that no order can inferred or implied at all. I checked when I rewrote the page, because I wanted to make sure the wiki described what mappers are actually doing, and I checked again two days ago. I found it's indistinguishable from random. If you want to add and maintain importance information to the point that it can be useful you'd either have to remap hundreds of thousands of restaurants or try to drum up support for some most_important_cuisine=* tag.
Why do you think it's important to define an order of importance? Most uses I can think of work just fine with lists (searching, descriptions, statistics, etc). The only case I can think of that would require choosing a single item is creating icons for labeling a map, and while maybe it would be nice to label pizza places with a pizza icon and Italian places with a flag icon, that's not really that compelling to me and would probably count as tagging for the renderer.
Anyways, I don't think a most important value can even be defined for most places. Who's to say whether the ethnic origin or type of food matters more? It probably depends more on who you are and what you're craving at that moment than on what the restaurant serves. And for sorting individual foods (like burritos vs tacos) it's theoretically possible but only on arbitrary criteria like which item appears first on the menu or which sells better.
Regarding alphabetization, the quest for neat taginfo statistics is honorable but misguided because in order to get accurate statistics you'd have to parse out the semicolon anyways. (I have a tool that does this and I was actually considering adding another column to the tables here in the wiki with an accurate count. That discussion is in the section about sorting, above this one.) Ultimately I don't care if someone goes through the effort to sort tags alphabetically (or by importance, for that matter), but I don't think it will have any measurable impact.
-Graptemys (talk) 15:38, 19 July 2023 (UTC)

────────────────────────────────────────────────────────────────────────────────────────────────────@Graptemys: There's a difference between saying that no order can be inferred and saying that no order is ever implied. It is at least sometimes implied – and usually implied when it comes to any tagging assisted by name-suggestion-index. You're right that in the case of, say, a "Japanese noodle bar", one mapper may gravitate toward cuisine=japanese;noodle while another will gravitate toward noodle;japanese, and this might be influenced by the UI of the editor they're using. However, for non-orthogonal cases like all-ethnicities, I think JesseFW was onto something by suggesting that some mappers probably do just list the cuisines in the same order as on the signs. It's actually very easy to order the cuisines like this if you're already adhering to the on-the-ground rule by checking imagery. Here are some examples around North America where I strongly suspect the order was not arbitrary:

Note that I'm not saying this is happening anywhere near 100% of the time. But to conclude that mappers are going out of their way to record the cuisines in a different order than importance or sign order in the cases where they think that order would make a difference? I think that would only describe one of the mappers pushing for alphabetization, which does sound somewhat pointless. So where does that leave us? If we don't alphabetize, why not allow mappers to put the values in some priority order, with the understanding that some data consumers will need to truncate the list in some contexts like icon selection?

 – Minh Nguyễn 💬 22:29, 20 July 2023 (UTC)

For something like icon selection (and I assume other features that need to select a single cuisine, though I can't think of any), selecting ANY of the listed cuisines should be okay. For a restaurant called "Pizza & Grill", a burger icon would be just as reasonable as a pizza icon. For "Peruvian and Japanese", either flag could work as an icon. And listing one first in the restaurant name or in the cuisine tag doesn't mean it's more important. So if the restaurant is known for a type of food or a specific food, and if it's in the cuisine list, and if the map has an icon for it, it's not wrong to display it using that icon. Now getting into implementation but a renderer could easily select the first value they have an icon for, or pick one randomly, or make up their own priority order (like always show a pizza icon). And if a place isn't known for a food such that it would have been wrong to use that icon, well maybe it shouldn't be in the cuisine list (like a pizza restaurant that has one mediocre salad).
Since I'm saying the order is currently and should continue to be unimportant, I guess I don't really care if someone wastes their own time to sort things, since the result is still a list of cuisines. The reason I'm pushing back is that I don't think we should put a statement on the wiki that encourages mappers, especially new mappers reading the wiki for the first time, to put that extra effort in themselves. And I definitely don't think we should give data consumers the impression that they can get any additional information out of what is likely to be an unsorted or arbitrarily sorted list.
-Graptemys (talk) 02:23, 21 July 2023 (UTC)
@Graptemys: The status quo before the edits I've cited is that the wiki neither encouraged nor discouraged mappers from implying some priority order in the list, but now it discourages mappers from doing so. (I quibble with the "extra effort" part; the examples above would require more effort to tag otherwise.) The fact of the matter is that some data consumers, not all of them, do infer a priority order by truncating the list at the first value, and NSI is also applying a priority order to some brands based on existing usage. I think these points are worth mentioning in the article, but that would inaccurately suggest that these projects are intentionally imposing their will against the community's expectations. How did that become an expectation? Certainly not by consensus. If the goal is to avoid taking sides, then the solution is to explain that there are differing practices, or at least to water down the language, but not to state definitively that the order doesn't matter. – Minh Nguyễn 💬 18:13, 21 July 2023 (UTC)
FWIW, I think the overall solution is to switch to a key-prefix (I like "food:") which prevents order from being (easily) considered, and discourage semicolon-separated multiple values in the cuisine key. But as for the right language currently in the page, I'm happy with a strong statement to the effect: "some people put values in an intentional order, but many people don't, so don't assume anything particular about the meaning of the order". How exactly to phrase that is something we can work out. JesseFW (talk) 20:29, 21 July 2023 (UTC)
Maybe better solution is splitting cuisine origin and kind of dish, for example cuisine=italian and (food=pizza or sells=pizza). Something B (talk) 15:28, 28 August 2023 (UTC)

Which values should be included in the tables

Since we have some discussion on this and I was looking at the statistics again and considering redoing the tables: Which values should be included?

I propose that we include any an all values that are currently used, i.e. that have usage above some strict threshold (I would say 100 uses worldwide (including in lists)). When I rebuilt the tables last year I included only values I thought would be useful to mappers, which means some commonly used duplicates were excluded (e.g. italian_pizza, coffee, and noodles). However these values might be useful to data consumers so I think it may be useful to include them in the tables with a note saying to map with the other values (pizza, coffee_shop, noodle) instead. What do you think of including duplicates? What do you think of a strict threshold? What do you think of drawing the line at 100 uses (~250 items)? -Graptemys (talk) 03:29, 23 July 2023 (UTC)