Add field 'website:menu'

[tognee]

This MR adds the 'website:menu' field and adds it into the sustenance amenity moreFields section.

[tyrasd]

I'm not quite convinced it is a good idea to map this information in OSM. To me it seems like an extremely volatile information: many restaurants change their menu in a seasonal rhythm. So, linking to a pdf or photograph of a menu is of little use for OSM. I think linking to the website of the restaurant is generally sufficient and a more robust way for finding the respective menu.

Also, I've noticed that more than two thirds of all features with the website:menu tag have been contributed by a single user using a (closed source?) tool called website-menu (//cc @wielandb – maybe you can give us some insight about that?). Since only a small number of features with this tag were mapped organically, and the fact that usage is extremely low relative to the number of potential features it affect, I'm tending towards not including the field in iD for now.

I think this would be best discussed with the broader OSM community before continuing here.

[tognee]

My idea for adding this field to iD is:

A lot of restaurants are using online tools to provide a menu on hosts separate from the main website. Usually they print QR codes sticker and stick them to the table, and the QR doesn't change often as they would need to reprint them.

This field could be used to link to those QR code URLs or for restaurant that are on delivery apps (like JustEat, Deliveroo, Glovoo, UberEats etc..) link to their public pages on there.

Adding the option on the most used editor would incentivize users to tag that info, making it more widespread and used.

[1ec5]

I'm not quite convinced it is a good idea to map this information in OSM. To me it seems like an extremely volatile information: many restaurants change their menu in a seasonal rhythm. So, linking to a pdf or photograph of a menu is of little use for OSM. I think linking to the website of the restaurant is generally sufficient and a more robust way for finding the respective menu.

It depends. Some restaurants pay the website to host their menu (and perhaps an online ordering option). Others “claim” a listing on a crowdsourced menu website. In both cases, the menu would be trustworthy enough to tag in OSM. I’ve encountered many restaurants that actively maintain their hosted menu and Facebook page but has allowed their main domain to lapse and get snapped up by a squatter. Apparently there have been debates in Discord about whether website is the right key for a hosted menu or Facebook page in that situation.

On the other hand, some menu aggregator sites allow diners to post menus with absolutely no fact-checking or followup with the restaurant owner. Maybe this is what you had in mind. Indeed, the menu could be quite misleading in this case, but website already suffers from this problem.

On the bright side, at least it isn’t being tagged as contact:menu, diluting the meaning of “contact”. 🤦

This field could be used to link to those QR code URLs or for restaurant that are on delivery apps (like JustEat, Deliveroo, Glovoo, UberEats etc..) link to their public pages on there.

By the way, delivery:partner is sometimes used to indicate these applications more directly. That key is also documented but not as common as website:menu. To be sure, not all the menu sites belong to delivery apps – for example, many restaurants depend on Yelp, Zmenu, or more niche sites to host their menus.

[wielandb]

Hey :)

I will gladly try to give some insight into my tagging of website:menu.

It all started as a community action that the DACH community starts every month regarding different topics (See OSM Wiki: Schwerpunkt der Woche ) with the goal of concentrating our efforts in one specific aspect of mapping. In March 2022, the theme of the community action was "Add website:menu". I am always glad to participate in the monthly community action, but usually, it requires on-the-ground survey, so my efforts stay limited in scope and only through the mass of the community are significant results visible.

But I realized that adding website:menu for restaurants that have a website-Tag is a rare instance of an armchair-mapping friendly task. So I quickly spun together an app on a no-code platform (It got the creative name website-menu)

The basic workflow is that the app will present me with a website in a WebView. I then try to find and navigate to the menu. When I have navigated there, I press a button in the app labled "This is the menu", which then triggers an update where the current URL of the WebView is written into the website:menu Tag of the OSM object.

So, while the app makes it extremely fast and easy to add website:menu-Tags, every datapoint is still hand-researched and verified by me. And I also want to add: I do not "search" for the menus on third-party websites or via google, I only tag them if the restaurants own website links to them.

Because, as I said, the app was made with a no-code platform, there isn't really any source code I could make open source, so yes, it is technically a proprietary app. I could make the apk free to download, but as I hacked it together to get to work on the community action asap, the UI and UX are complete trash. I am playing with the idea to make a new version (for the web?) which then would be open source.

But now for my opinions on website:menu beeing included in the ID tagging scheme.

• I would be in favor of website:menu beeing added to the translated objects (a.k.a. so that the tag gets a human-readable translation)
• I would be against website:menu beeing a "recommended field" for restaurants, as many restaurants will not have a menu online

On the topic if the tag is organically mapped or not, I would say that yes, a large chunk of current mapping of website:menu is through me, but I only started tagging it because I saw the tag as already established in the community because I was able to vote for it.

On the topic for what this information is useful, I primarily see it as a convienience information, so that (like google does for example) there can be a Button "menu" additionally to the button "website" in a POI info box. I personally think it's really convienient.

Of course, I have seen many many restaurant websites over the past year and can give some insight on how the "restaurant-website" landscape looks. :D

For example, it's indeed true that many restaurants websites get snatched up by domain parking services, so much that I added a "The website is offline" button to my app so that if I press it, the website-Tag is removed from the restaurant. And there is a small but significant amount of websites that pay other hosting services to host their menu, but in the overwhelming majority of cases the menu is just a PDF on the restaurant's website.

In conlusion, I can only say that I would be very sad if my explicit attempt to make the website:menu tag more known and more established in the osm database and community would now become an argument against accepting it.

[tyrasd]

Thanks for the additional background @wielandb, @tognee and @1ec5. I do see now that there actually is a real practical use for this information and tag.

Having the field included as an optional "moreFields" field (as proposed in this PR) seems reasonable to me. It also has the benefit that mappers are more likely to update this information in case it was already mapped, but the owner/name (and therefor also the menu) of the restaurant changes.