Restaurants with multiple menus

General talk Tagging general discussion
1

I’ve encountered at least three restaurants which have multiple menus with different offerings and pricing. Two which come to mind are -

  1. Udupi Upahar, Bangalore, India. One part of it is self-service with standing tables, and the other part of it has seating and wait staff. The menu of the latter has more options and also higher prices.
  2. High Point, Lokhandwala, Mumbai, India (indoor, outdoor). This actually has three menus - a takeaway menu, an indoor menu, and an outdoor menu.

How should such establishments be tagged?

Adding multiple menus to the same feature

This is what I’ve done for Udupi Upahar.

The downside is that the presence of multiple menus is not really specified in any way, which can result in users not realizing that there are multiple menus.

Adding separate restaurants for each menu

This is what I’ve done for High Point.

The downside is that this violates one feature, one OSM element. Common keys need to be kept in sync between the two.

If you also choose to treat the two as separate establishments with different characteristics, it’s not clear to the user that it’s really one establishment with the superset of the characteristics. e.g. if you tag one with outdoor_seating=yes + indoor_seating=no and the other with indoor_seating=yes + outdoor_seating=no, it’s now not clear to the user that the restaurant really has both indoor and outdoor seating.

New keys?

MapComplete currently uses the image:menu[:N]=* key. We could introduce new keys, e.g.
image:menu:indoor[:N]=*
image:menu:outdoor[:N]=*
image:menu:takeaway[:N]=*
image:menu:self_service[:N]=*
etc.

This also allows for categorization of menus, e.g. a separate drinks or bar menu. But, when the suffixes are referring to areas, it’s not clear which areas are being referred to, nor where they are located.

Relations?

The best solution seems to be to add such areas of the restaurant as polygons and tag them with the details specific to them - image:menu[:N]=*, air_conditioning=*, self_service=*, weather_protection=*, etc.

Then, a multipolygon relation could be created, and tagged with name=* + amenity={fast_food|restaurant} and other keys which apply to all the sub-areas.

When displaying menus, consumers should use all the menus specified by the sub-areas.

Thoughts?

2

I’m not convinced it does need adding to OSM. Pricing data changes too much to warrant adding it.

I certainly would not map them as separate restaurants unless they are run by different companies.

P.s. I’ve never seen those image menu tags before and have no idea what image:menu=41073199-c6ca-4d38-9883-3607bf24c8e8 means.

4 Likes
3

I would have generally thought of a semicolon as a separator.

Hot guessing: This looks like a Panoramax ID (e.g.: https://panoramax.openstreetmap.fr/?pic=c77fd268-93d7-44de-a572-97edc06d3043) However, the IDs stored in the OSM object do not work. (https://panoramax.openstreetmap.fr/?pic=41073199-c6ca-4d38-9883-3607bf24c8e8)

1 Like
4

Hmm, I’m wondering whether I did the wrong thing here now. In this situation there’s a single building, a single company, a single website, and a shared naming prefix (“Boatshed”).

I went with separate POIs though because it felt like there were three quite distinct parts to it:

  • A kiosk.
  • A cafe.
  • A restaurant.

They have different menus, different opening hours, different parts of the website dedicated to them, different seating options, different price points, different service levels, different booking requirements, etc.

Surely trying to wrangle that into a single POI would not work well?

Unsure how similar this is to the OP’s situation though.

1 Like
5

if single restaurant has two menus then it must be mapped as a single restaurant

3 Likes
6

Respectfully, I think the idea of mapping things as you’ve described begs the question: is this the sort of information that ought to be conveyed on the map in the first place?

You’re framing this as the restaurant having “different menus”. You could look at it that way, but to me I would reframe this as “one menu with differing availability”. It’s really no different in my mind than a restaurant having a “breakfast menu”, “lunch menu” and “dinner menu”; you could conceivably call these all “separate menus”, sure. But what is that information really expressing, at the heart of it? Simply that some dishes can be ordered in the morning, some dishes can be ordered around noon, and some dishes can be ordered in the evening.

The granularity with which you’re trying to express these “different menus” is so fine that I think it’s exceeding reasonableness. Almost all restaurants in my experience list their food and beverages separately, and most will close the kitchen (thus not allowing patrons to order food) some time before the restaurant itself closes (to allow the back-of-house staff to clean), but they’ll still take drink orders; are we going to strive to tag separate “food” and “drink” menus? What about time-of-day menus; “breakfast”, “lunch” and “dinner”? What about “Happy Hour”?

I think this is venturing outside the scope of what anyone would reasonably expect to be tagged on OSM.

2 Likes
7

This feels more distinct than what the OP implied with their examples. Maybe I should have written “… unless run by different companies or having clearly distinct branding”. I don’t think a reduced takeaway menu (or outside menu) is enough to map it as multiple restaurants.

4 Likes