Do you think the complementary tags like Cuisine with all its values should be added to the Map Features page? I consider them complementary as address, surface or usage, and these other tags are already in that wiki page.
I think we should add them, because it is a set of “in use” tags, commonly used in OSM. This page should display all the OSM possible and commonly used tags.
Yes, perhaps Key:cousine should be added; if so, it probably should go under section 2.4 Properties
I’m not quite sure what you mean by:
I would definitely be against counting all possible cousine=* values directly on Map Features page. I.e. If added, I’d handle it like other many-valued keys, e.g. like clothes=* or rental=* - just provide link to key wiki for details (especially as many of its values are ATYL, it sounds too messy and prone to falling out of sync by mentioning them on Map Features directly) .
note that this page already operates at its technical limits or even beyond it
anyone proposing significantly expanding it should first fix this issues or arrange to fix it, otherwise part of entries will be broken
Note [[ Too many Data Items entities accessed. | max_age ]] error appearing near the end.
What options are there that might fix this? Is generating a static page somehow an option, rather than trying to process lots of stuff on the fly?
I didn’t know about this page, but some tables don’t make much sense IMO. Why keep a table explaining each of addr:*? Or the most common values of shop, or tourism, or …? There are dedicated pages for those already. It’s unnecessary duplicated work that may lead to problems (if one page is updated but not the other for example).
no idea
I never really used or maintained this part of wiki
Asking on its talk page or https://wiki.openstreetmap.org/wiki/Talk:Wiki may be a better idea
Maybe it is sufficient to simplify this page so that it will just contain a list of tags (similar to Nominatim/Special Phrases/EN - OpenStreetMap Wiki) that are linked to the corresponding wiki pages. So essentially drop the templates (or make it one large but simple template instead), don’t use images or taginfo statistics.
Alternatively, try to identify the main reasons why this page is so slow. Maybe there are other options for improving page loading speed by reducing CPU/memory usage and number of server queries.
I believe that moving forward with the project to migrate the Map Features tables to the Taginfo-based Taglist template could address the performance issues because the template bypasses the normal MediaWiki mechanisms.
I agree that this would be a sensible approach. It always rubbed me the wrong way that we were trying to cram the whole wiki on a single wiki page. Now I have a technical explanation for why that felt wrong to me.
One of the concerns raised on the talk page was that, unlike the wiki’s own 404 pages, taglists can’t fall back to data item descriptions and images because taginfo intentionally does not integrate with data items. This is not a problem for the English version of the page, but some language communities have prioritized maintaining data items over the full-fledged articles that taginfo scrapes.
As a completely different approach, I suggest taking a step back and considering the main audience of this page: less experienced mappers who are unfamiliar with the wiki’s organization of tagging pages by raw key, who find it more intuitive to search by lay terminology (the built-in search engine is little help here). This is the same audience whom iD’s presets are designed for, so why not make a standalone tag browser based on the same presets that points to the relevant documentation on the wiki?
Conceptually, this tool would be closer to “How to map a” than “Map features”, but I think that’s closer to what most people use the latter page for anyways. The id-tagging-schema project has the advantage that it already collects names of features in each language, not just descriptions, and images can vary by country, not just by language.
As it happens, many of the cuisines have top-level presets, so you’d be able to search for “Japanese” and get “Japanese Restaurant”, leading you to cuisine=japanese.
I already did it in Spanish; however, some tags were expanded to list all values.
For this reason I created a ticket in Taginfo’s GitHub - Taglist for only inuse, defacto and approved tags · Issue #366 · taginfo/taginfo · GitHub to show all “approved”, “in use” and “de facto” automatically from Taglist, without specifying them. That’s reduce the administration for Map Features page and its Templates.