New Tag structure food:*

[Minh_Nguyen (Minh Nguyễn)]

@Graptemys

Just tag this as cuisine=japanese;okinawan, including a common general value and a less common but more specific value. Even if okinawan isn’t supported by many consumers now, it might be later if it gets enough usage.

This is similar to how I use alt_name: throw spaghetti at the wall in case any of it sticks well enough for a geocoder to pick it up. But applications are also using cuisine for display purposes. For example, Organic Maps displays the full list of cuisine values, pretty-printed. The list would look redundant if we allow cuisine to contain catch-all values. To a user, this Japanese fast food restaurant that’s also noted for its not-particularly-Japanese ice cream would look like some sort of Japanese ice cream parlor:

It can be difficult to design a fast food icon that doesn’t imply a particular cuisine, so some map styles like Mapbox Streets vary the icon by the primary cuisine value (the first value). But in a country that typically tags its national cuisine, where the name of the national cuisine starts with a letter toward the beginning of the alphabet, all the fast food restaurants would have the same icon.

[Graptemys]

@Minh_Nguyen

To a user, this Japanese fast food restaurant that’s also noted for its not-particularly-Japanese ice cream would look like some sort of Japanese ice cream parlor

I don’t see any problem with this? It’s known for its Japanese food, it’s known for its ice cream, and OM displays this information in a nice way. And even if the nationality and food tags were separated I would hope OM and other renderers still display them.

@Minh_Nguyen

all the fast food restaurants would have the same icon

And this seems like a renderer issue, not a cuisine issue.

[Minh_Nguyen (Minh Nguyễn)]

@Graptemys

@Minh_Nguyen

all the fast food restaurants would have the same icon

And this seems like a renderer issue, not a cuisine issue.

I forgot to elaborate on my concern. It’s not that we’d be breaking this particular use of cuisine by introducing food:*, but rather that there does seem to be a valid need for determining which cuisine/food to prioritize when there’s only room for one. Mapbox Streets was just an example, but honestly I would struggle to come up with an icon for “fast food” that doesn’t imply a particular cuisine, so some variants would be pretty useful. (Seeing osm-carto’s hamburger on KFC or Taco Bell is actually kind of amusing.) As the Italian/pizza case shows, the prioritization would vary from case to case, rather than being inherent to these values.

[SomeoneElse (Andy Townsend)]

What you’re proposing doesn’t replace the “cuisine” tag. That guides mappers towards categorisation; your “food” proposal does the opposite. Many (most) restaurants and fast food places offer a large variety beyond their core cuisine, so expecting data consumers (including just humans deciding where to eat) to work something out from dozens of menu-scraped tags seems a bad idea.

Maybe this isn’t what you are proposing at all - if not, why not give a few examples of places, how they are tagged now and how you would see them in the future? If it’d be too long for a post here, maybe a diary entry would work?

[Minh_Nguyen (Minh Nguyễn)]

In fairness, I think the food:* proposal is someone else’s – even the original poster of this thread is merely documenting what’s out there already in the database. But I think there is a real difference of opinion about whether mappers or data consumers or users expect the values in cuisine to be sorted by some order and what that order would be.

[Graptemys]

@SomeoneElse

What you’re proposing

I wasn’t proposing anything here. I don’t see much value in the food proposal this thread was originally about, and I don’t see any value in in splitting cuisine by food/nationality, or in sorting or declaring a primary cuisine as we were discussing on the wiki talk page. I think the cuisine tag is fundamentally okay, though it does need some significant cleanup on certain values, and more uptake of uncommon but specific values.

The menu thing was just a quick idea that I thought might solve some of the food proposal’s use cases while being much more straightforward to implement. I meant that a human could quickly peek at an individual restaurant’s menu if it was linked.

@Minh_Nguyen

determining which cuisine/food to prioritize when there’s only room for one

Will discuss this back on the wiki page to keep this thread on topic.

[Minh_Nguyen (Minh Nguyễn)]

@Graptemys

I don’t see much value in the food proposal this thread was originally about, and I don’t see any value in in splitting cuisine by food/nationality, or in sorting or declaring a primary cuisine as we were discussing on the wiki talk page. I think the cuisine tag is fundamentally okay, though it does need some significant cleanup on certain values, and more uptake of uncommon but specific values.

For better or worse, a rendered map is not going to mark Way: ‪Murray's Fish and Jerk Hut‬ (‪1178154930‬) | OpenStreetMap with a pair of and icons, nor will it mark Node: ‪Fusion Diner & Cakery‬ (‪5954552885‬) | OpenStreetMap with 29 different icons mashed together. To the chagrin of an SEO specialist, it’s going to pick just one. With a single, semicolon-delimited key like cuisine=*, the only reasonable, practical way to do that is to pick the first listed value. Otherwise, if it picks the first value alphabetically, the map will look a lot duller in an american neighborhood than in a vietnamese one. It could pick the first value that matches a word in the name=*, but this only works for places named in British English. Or it could pick a value at random, perfect for April Fool’s Day.

One advantage to a namespace-based scheme such as food:*=* is that a mapper can indicate that one of the values is “first among equals”, by setting its value to main instead of yes. There is precedent for this in language:*=main and the proposed health_specialty:*=main. Another advantage is that, for a restaurant that serves one cuisine at breakfast and another at lunch and dinner, conditional tagging becomes somewhat less awkward. But merely splitting out food:*=* from cuisine=* would already take enough pressure off of cuisine=* that we might not need that level of specificity.

[SomeoneElse (Andy Townsend)]

@Minh_Nguyen

the only reasonable, practical way to do that is to pick the first listed value

Er, no?

I don’t think that it’s that unreasonable to process keys that commonly have semicolon separated lists with at least some knowledge of what’s likely to be in there - it’s what I do for a number of keys. Usually the first-placed item before the semicolon is deemed to be “most important” but not always.

Edit: Now I’m back at a PC I can add a couple of examples - here and here.

[Graptemys]

You’re proposing to completely reinvent a tag with a million uses in order to improve one renderer’s feature affecting a minority of restaurants, when the current behavior isn’t even wrong.

[Adamant1]

It’s extremely debatable that foods like chicken or hot dogs are cuisines. As a side to that there would be a benefit to being able to sort dishes that are based on the same main ingredients but come from different cultures somehow. I don’t think you can do that with the current tagging. At least in an easy or intuitive way.

[Minh_Nguyen (Minh Nguyễn)]

@SomeoneElse

I don’t think that it’s that unreasonable to process keys that commonly have semicolon separated lists with at least some knowledge of what’s likely to be in there - it’s what I do for a number of keys. Usually the first-placed item before the semicolon is deemed to be “most important” but not always.

We’re still talking about cuisine=*, right? That’s the topic at hand and the word that immediately precedes your selective quote. And indeed, your Lua file largely prioritizes cuisine values based on order: burger;chicken;pizza becomes burger; chicken;burger;pizza becomes chicken; pizza;burger and pizza;chicken both become pizza. I take this to be a verbose way of more or less truncating the key after the first value that you have an icon for, although it does look like you’ve thrown in a few subtle editorial choices that seem appropriate to your audience, for example that fish_and_chips is always more relevant than chinese.

Anyways, my point is that, with cuisine=*, a mapper is technically capable of expressing a sorted list, whether or not that’s a good idea. But with a namespace-based scheme, that would need to be more explicit with a main value. This discussion shows the limitations of relying on an implicit sort order.

@Graptemys

You’re proposing to completely reinvent a tag with a million uses in order to improve one renderer’s feature affecting a minority of restaurants, when the current behavior isn’t even wrong.

If this is about my earlier screenshots of Organic Maps and Mapbox Streets, allow me to clear this up: I’m not saying either data consumer is behaving correctly or incorrectly. It is possible for a piece of software to behave correctly in general but still get some cases wrong compared to reality, due to disconnects between a mapper’s intent and their editor’s behavior and the data consumer’s behavior based on a wiki article edited on the fly.

But for what it’s worth, I rather like what OsmAnd does with cuisine=hawaiian;sushi;ice_cream, bucketing them into separate “Cuisine” and “Dish” lists. (The sections are collapsed by default.) OsmAnd doesn’t know which cuisine=* value is the most important, if any, but it does know that certain values represent dishes.

(I did not list all the fare offered by that restaurant. They also have a great deal on a boatload of tater tots.)

[ernsterwinwg]

@Minh_Nguyen

In fairness, I think the food:* proposal is someone else’s – even the original poster of this thread is merely documenting what’s out there already in the database.

Yes I was opening this thread with the main goal of gathering opinions and thoughts before writing a more concrete wiki proposal. To be fair, I was also adding some of those food:*=yes tag in database myself so I can query them, not sure how much this is an unrecommended behavior before a proposal is approved.

@Graptemys

As for copying every item on the menu into OSM, I don’t see the value in that at all

I also think that is a bad Idea, but this is not the intended usage of food:*= I had in mind.
I think there are various middle-ground scenario between:
1 - having only the cuisine=*;..;* tag
2 - having the list of all item in the menu or a video recording of the last week of operation of the given restaurant.

I find it excellent how in OSM a big amount of useful information is compressed and summarized in few line of text (and a wiki), I am wondering if the tag cuisine is too extreme on that.

I was thinking to use food:* to complement cuisine. I would assume cuisine list values represent the broad sets of dishes while food:* values narrower set, (maybe down to very specific dishes).
So food:* may not be used to list dished which are already part of the sets listed in cuisine with high probability, should be used instead to add uncommon dishes. Those can be a few selected most representative item from the menu. Furthermore the structured key format would allow to easily add information about those dishes. Definitely also having food:*=main would be a good usage of it.

For example: for a place tagged with cuisine=Italian, most likely there is not need to add food:pasta, while maybe only a subset should be tagged with food:lasagne=yes or food:parmigiana=yes.

What I aim for is to be able to picture as clearly as possible a place just looking at the OSM tags, and ideally to be able to convert a given idea of place in a query (i.e. with overpass) in order to match all the eventual instances of that loose picture.

Maybe whether using a structured key or not should can be a separate discussion, I personally prefer structured keys compare to list of values, especially when the values are heterogeneous or when they may deserve their own wiki page, this is not the case in my opinion for i.e. opening_hours which works well with as list value tag.
One can maybe manage to have the same amount of information of a structured key also in list valued tag with addition syntax like conditional or similar but it seems less straightforward.

@Graptemys

You’re proposing to completely reinvent a tag with a million uses in order to improve one renderer’s feature affecting a minority of restaurants, when the current behavior isn’t even wrong.

I was not thinking about reinventing anything but just adding the possibility to be more specific, and figuring out which is the best way to do it. Of course just adding more values in the cuisine tag list is also an option.

NB: I am aware that the food:* may clutter a raw display of all tags of an entity but I think that theoretically this can be handled by consumers.