Template talk:ValueDescription

From OpenStreetMap Wiki
Jump to navigation Jump to search

This template is used to get a well designed structure into the available tags that exist to describe a map feature.

There is no need to change the template itself if you just want to create a new Tag:somekey=whatever page or translate a existing page into your language!
Please read the template documentation to get a clue about how to use this template.

Template talk:Description/Archive 1 archives content from this page.

Translating an existing page

If you like to translate a page into your language you just need to create a page for it for example De:Tag:highway=track. Once the page exist the link to this side will be seen on every *:Tag:highway=track site.

Do not edit this template to add the link to your translated page!

Why don't we put the "Other Languages" table into another template (allowing parameter 1 to overwrite the title), so that all the different templates use the same block? It could be used 1.) in other languages and 2.) on other templates… -- MapFlea 15:36, 12 November 2008 (UTC)
Yes, I also think it would be better to have a generic Template:Language! And like in Template:Language-mp (which should also be replaced) there should be no ifexist-tests. Whenever a translation-page exists can be seen by the color of the link. Parameters are not needed as we can use the {{PAGENAME}} variable. See mediawiki:Help:Magic_words --Phobie 15:58, 13 November 2008 (UTC)


Any thoughts on adding "wikidata=" to the template, similar to the recent changes adding it to Template:KeyDescription and Template:Description? --Frankthetankk (talk) 21:22, 29 August 2014 (UTC)

If we support the parameter there, it should be supported here, too. But first it would be advisable to actually document the new wikidata parameter properly. Currently an explanation is missing from the template description, only its existence is noted. And while I find the idea interesting in general, I would also like to see some examples on how to use it (and how not to use it). I don't think this is self-evident. (I also dislike the complete lack of discussion preceding its introduction, by the way.) --Tordanik 01:49, 30 August 2014 (UTC)
It’s been added to Key:bridge. The icon for missing translations can be fixed if it’s worth keeping. I can’t say I’m convinced yet.--Andrew (talk) 08:04, 30 August 2014 (UTC)
Indeed. That example already points to a problem: While it is sometimes possible to state that all OSM elements with that tag are an instance of some Wikidata item, it is not possible in other situations. For example, roads with bridge=yes crossing a man_made=bridge are not instances of "bridge". Furthermore, a lot of OSM tags don't represent an instance relationship with some class of objects at all, but are properties instead. So I doubt that mapping Wikidata onto OSM tags in that manner is feasible. --Tordanik 21:47, 1 September 2014 (UTC)
So far I do not see any new value of this new wikidata feature. Maybe someone could try to explain its purpose in better example than is Key:bridge. Chrabros (talk) 07:39, 3 September 2014 (UTC)
What is purpose of this parameter? I see plenty of edits adding it and I missing any use for it. At this point I recommend removing it. Mateusz Konieczny (talk) 12:28, 4 November 2017 (UTC)
I plan on removing this parameter. Is anybody opposed and able to explain purpose of this parameter? What is purpose of linking Wikidata entries from tag pages? How it can be used to improve OSM? Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)
I am opposed to removing the wikidata parameter. Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about, at least it should be used in way that this is the case.
Wiki_Translation#Community_cohesion: "Unlike Wikipedia, we are not aiming to capture vast amounts of knowledge in the wiki." So what else than links do you want to use? I assume that most people who have added wikidata IDs here thought that this would be helpful for other users, so that not everyone has to search by himself.
There is not always a corresponding wikidata item available or there may be other problems in some or perhaps in many cases, then the parameter can be omitted (and I think the "Search Wikidata" link is dispensable in this case), but that's no reason to remove the parameter in general (like it would also not be great to remove the "Available languages" bar everywhere just because there are sometimes contradictory statements in different languages).
Please make more clear what exactly you are planning to remove: The link if "wikidata = Q..." is set, or the link to the wikidata query window if it is not set ("Search Wikidata"), or both? --Hufkratzer (talk) 17:52, 4 January 2018 (UTC)
"Its purpose is that by clicking on the link one can quickly find more information that explains what the tag is about" - note that wikidata entries and OSM tags rarely match perfectly. I would not rely on this kind of links to explain how tags should be used Mateusz Konieczny (talk) 20:55, 10 November 2018 (UTC)
"Please make more clear what exactly you are planning to remove" - link, "search wikidata" link and all "wikidata" parametres added on Wiki pages Mateusz Konieczny (talk) 20:56, 10 November 2018 (UTC)
I asked Geozeisig who is often adding this parameter for help as I am still unaware how and why this parameter is added and used Mateusz Konieczny (talk) 15:56, 2 January 2018 (UTC)
Geozeisig replied in https://wiki.openstreetmap.org/w/index.php?title=User_talk:Geozeisig&diff=1542792&oldid=1542485&rcid=&curid=50235 "Sorry, I do not know the purpose of this parameter". Mateusz Konieczny (talk) 08:35, 3 January 2018 (UTC)
I asked Pigsonthewing who added this parameter Mateusz Konieczny (talk) 09:58, 3 January 2018 (UTC)
Thank you, Mateusz. I would, of course, be opposed to removing this very useful feature. I'm not clear what the objection to it, other than "I don't understand it", is. Perhaps the lack of understanding is caused by the poorly-chosen examples ("cheescake"?!?). The example for "power = generator" is slightly better, because the Wikidata search returns a real item, Q131502. But even that seems to be conflated with Tag:power=plant. A far better example (one of many correct uses) is Tag:landuse=cemetery; where there is an explicit link to Wikidata's Q39614 item. There, once can see machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries (or of sub-classes or super-classes thereof), which can be cross-referenced with those in OSM to check for matches and discrepancies. The use of links (URIs) to such data ("linked data") both on thsi direction and the reverse (from Wikidata to OSM pages) is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web, calls for (video, with text transcript). It is vital that OSM is part of the web of linked data, if its full potential is to be realised. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:24, 3 January 2018 (UTC)
Could we please leave politics (and religion so to speak) out of this? Mateusz asked for the specific purpose of the parameter. 'Linking' in itself is not a purpose. The question is what kind of relationship this reference indicates. How is this reference used/supposed to be used? As the meaning and use of tags change how do you determine if a certain value of this parameter is correct of not? landuse=cemetery and amenity=grave_yard have the same wikidata value. Is this correct? waterway=river references Q4022 but waterway=stream does not. Is this correct? How does the mapper editing the wiki determine if it is or not? What would be the wikidata value for something like access=* or opening_hours=*? See also Tordanik's remarks above. --Imagico (talk) 15:17, 3 January 2018 (UTC)
I don't know about "politics and religion", because I used neither. I did though explain the purpose of including the links to Wikidata. What about you leaving out the snark and the assumption of bad faith? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
I referred to "is exactly what Sir Tim Berners Lee, the inventor of the World Wide Web" - claiming that some authority supports it, without decent confirmation is a poor argument. I am pretty sure that he would not support useless linking not giving any clear benefits Mateusz Konieczny (talk) 20:54, 10 November 2018 (UTC)
"what the objection to it" - iff it is not clearly useful then there is no reason to keep it in infobox Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)
Fortunately, it is clearly useful, as I explained. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
Are you claiming that "machine-readable metadata about cemeteries, and query Wikidata for items about cemeteries" is needed so often by users of OSM Wiki that it deserves to prominently displayed in the infobox? Because it seems to me that such things will be done rarely, and it is as relevant as linking relevant Wikimedia Commons category, Wiktionary item, Flickr category etc. I see no reason to elevate Wikidata so high, it is not like OSM Wiki is about promoting this project Mateusz Konieczny (talk) 19:05, 9 May 2020 (UTC)
"machine-readable metadata about cemeteries" - how it helps doing anything in OSM? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)
Not everything in OSM, or the OSM wiki, has to "help doing anything in OSM". The purpose is to "help OSM's users". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:38, 3 January 2018 (UTC)
"help OSM's users" for me is included in "help doing anything in OSM". So how this kind of "machine-readable metadata about cemeteries" (only sort-of related to OSM tagging scheme) helps doing this? Mateusz Konieczny (talk) 20:50, 10 November 2018 (UTC)
"query Wikidata for items about cemeteries" - how this link from infobox is helpful in making queries? In my experience main obstacle in making queries is figuring out syntax of SPARQL and searching for identifiers is easy. Also, https://www.wikidata.org/wiki/Q39614 anyway has nothing that would allow making Wikidata query that is not already present on https://www.wikidata.org/wiki/Wikidata:Main_Page. In addition, is it really common for users of OSM wiki to make Wikidata queries? Mateusz Konieczny (talk) 15:29, 3 January 2018 (UTC)


From the Wikidata item at Q39614, the quickest and simplest way for a human to query Wikidata for an up-to-date list of items about cemeteries is:

  1. Select the "Discussion" tab
  2. Select "List of instances"
  3. Select the big blue "run" (right-arrow) button

[None of these links are available on Wikidata:Main Page.]

The above just ran for me, in under three seconds. No knowledge of SPARQL required; the query can also be modified using the "Query Helper" wizard. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:27, 3 January 2018 (UTC)

"query Wikidata for an up-to-date list of items about cemeteries" - so only usage is to make searching Wikidata easier? Why we would need it? What makes Wikidata so special that infobox needs a special link to search in this particular database? Mateusz Konieczny (talk) 21:00, 10 November 2018 (UTC)
The OSM linkages on Wikidata can already be quite useful to create automatic translations of most tags. Its probably a better idea to store the links on Wikidata which is a proper database rather than the OSM Wiki though. If there was some way this wiki could query Wikidata and automatically add links to Wikipedia, and images from Commons, it would be super helpful in the lesser represented languages --Planemad/Talk 08:06, 10 January 2018 (UTC)
As discussed in comments in this diary entry - "The problem with using wikipedia / wikidata for this is that the words that OSM uses to describe things often don't match the dictionary definition (in any language, even British English) of those things, even for basic things like "city"." Mateusz Konieczny (talk) 21:02, 10 November 2018 (UTC)

I don't think the "Wikidata" link adds anything useful for OSM mappers and I would be in favour of dropping it. Also, if there is no Wikidata link set, then currently the template displays a "search in Wikidata..." link which gives the whole "linked data" religion unnecessary prominence. The template has many optional parameters, and "wikidata" is the only parameter where, when it is missing, Wiki users are nudged in the direction of researching and adding it. This makes it look as if adding the "wikidata" parameter was a more valuable use of an editor's time than completing other missing bits of information. This is a value judgement that I oppose. --Frederik Ramm (talk) 16:02, 8 November 2018 (UTC)

This is what Mateusz already suggested above. The only purpose of the wikidata parameter mentioned so far except the self fulfilling linking of data are to find more information that explains what the tag is about and automatic translation - which as it has been explained do not work since there is no semantic identity between the tag and the linked to wikidata entry and the illusion of such identity is misleading for the mapper. Because of this an automatic translation based on the assumption this identity exists is bound to be faulty which rules out this application as well. Plenty of examples given above that illustrate this. So i also see no good reason to keep this. It does more damage by misleading mappers than it provides actually useful information (which essentially amounts to someone thought this wikidata entry is somehow related to this OSM tag). --Imagico (talk) 16:27, 8 November 2018 (UTC)
Now we have our own Wikibase there’s another problem. The Wikidata link has a database link (Q number) that is different from the Q number in our own Wikibase instance. The WMF developers were very un-keen on Yuri’s suggestion of us using a different prefix letter to distinguish the two. Getting rid of the Wikidata parameter would solve this.--Andrew (talk) 06:26, 9 November 2018 (UTC)

Another user asked on the craft page:

"What to do if there is more than one Wikidata counterpart implied with craft=*? There is "craft" - Wikidata:Q2207288 - but usage in OpenStreetMap also implies "skilled trade" - Wikidata:Q64506407.
; Options
  1. Note down all Wikidatas (with semicolon) even if that's not currently supported? (e.g. wikidata=Q2207288;Q64506407)
  2. Link to the literal expression?
  3. Put in the best match? (Here you could prefer "skilled trade", covering a wider range of usage than "craft".)
  4. Leave it empty? (How many percent of matching is needed? Better a link with 75% matching or no link?)
I'm undecided myself and tend to 1 or 2 for now. (Perhaps "skill" would have been a more universal key than "craft".) --Chris2map (talk) 07:41, 3 May 2020 (UTC)
This is another reason that "wikidata=" should not be used in the Description templates (which create the Infobox), because it usually does not work. --Jeisenbe (talk) 16:04, 3 May 2020 (UTC)
Bald statements that something "usually does not work" do not inform the debate: you need to say what you mean by "usually does not work", you need to give examples, and you need to say what you have tried to remedy the examples you give and how that failed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)
The sensible solution, missing from your list, is to either use a parent item on Wikidata, that encompasses both of the child items which cause you an issue; or to start a discussion on Wikidata, to ask the community there to resolve the issue. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:59, 3 May 2020 (UTC)
Though in this case, "craft" is the parent of "skilled trade" (and not vice versa as you have it) and is the correct item to use here. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:08, 3 May 2020 (UTC)
Because items on wikidata relate to real-world concepts, while tags in OpenStreetMap are used in particular ways which have developed over time, attempts to link to a wikidata page will not find a good match. An example is how landuse=cemetery and amenity=grave_yard were both linked to https://www.wikidata.org/wiki/Q39614 - "place of burial", however the wiki pages for those tags note that they are not identically: amenity=grave_yard is used for churchyards and other grave sites located next to a place of worship, while landuse=cemetery is generally used for burial sites that are not associated with a place of worship. Similarly, the key craft=* does not match the definition on wikidata: https://www.wikidata.org/wiki/Q2207288 "pastime or profession that requires particular skills and knowledge of skilled work" vs our definition https://wiki.openstreetmap.org/wiki/Key:craft "A place producing or processing customized goods". Notice that the wikidata definition is of a hobby or job and focuses on skills + knowledge, while the OpenStreetMap tag is a location and focuses on making or processing goods. But also "places that are widely accepted as shops should not be tagged as crafts". Comparing the German and English wikipedia definitions might explain why wikidata and OpenStreetMap don't match: https://als.wikipedia.org/wiki/Handwerk vs https://en.wikipedia.org/wiki/Craft - but it's also due to the fact that craft=* was accepted long after many things were tagged as amenity=* or shop=* or man_made=*. Reading the linked wikipedia articles on the wikidata page will not help mappers or database users to understand what the key is used for in OpenStreetMap. --Jeisenbe (talk) 23:43, 9 May 2020 (UTC)

Categorisation Change

I changed

<includeonly>[[Category:{{{lang|en}}}:Tags|{{{key}}}]][[Category:Tags_by_value|{{{value}}}]] {{#if: {{{image|}}} ||[[Category:Feature pages with missing images]]}}</includeonly>


<includeonly>{{#ifeq: {{lc:{{#ifeq: {{{lang|en}}}|en||{{{lang}}}:}}Tag:{{{key}}}.3D{{{value}}}}} | {{lc:{{anchorencode:{{FULLPAGENAME}}}}}} |[[Category:{{{lang|en}}}:Tags|{{{key}}}]][[Category:{{{lang|en}}}:Tags_by_value|{{{value}}}]]|}}{{#if: {{{image|}}} ||[[Category:Feature pages with missing images]]}}</includeonly>

to only categorise pages with names in the format (lang:)Tag:(key)=(value) in the first two categories. I didn't change the bit about the image. This change was also added to the De, Fi and Pt versions of this page to keep categorisation consistent. The template was also being used in Proposed Features pages which didn't really seem to fit the category properly. The .3D and the anchorencode: were to handle spaces in page names where there were underscores in keys or values. It also then categorised the tags_by_value by language as was already the case with the tags category. --EdLoach 23:40, 25 June 2009 (UTC)

So it appears that the auto-categorization remains non-functional, correct? My apologies, I was looking at implementation on the improperly named page Key:access:bdouble; this function works after moving the page to Tag:access=bdouble. --Ceyockey 14:34, 11 November 2010 (UTC)

Resolved: seems safe to archive after such long time Mateusz Konieczny (talk) 12:34, 26 March 2021 (UTC)

native_value and native_key parameters

We have more and more active people in the mapping who do not speak English.
I suggest adding a parameter to the template for the key and value, such as native_key and native_value. This will allow us to search for the correct key in the user's language.
I'm not sure whether it is possible to write a template for "Category" that can automatically create a list of tags in the user's language, based on these new parameters. --Władysław Komorek (talk) 11:30, 16 March 2014 (UTC)

It would be misleading to suggest that tags are language-dependent. But there are ways to make a word in the native language available to search: You could either use the word in the translated page content, or add a list of RelatedTerm entries at the bottom of the page, containing all synonyms for the object in the native language. --Tordanik 13:58, 16 March 2014 (UTC)
But do not give it to the user, especially the novices, the list of available tags in his language. Create an additional category to the list of tags in the language in no way interferes with the use of the existing categories, but minimize incorrect tagging and show other possibilities for tagging people do not understand the English language.
One of the biggest problems in OSM is a misunderstanding of the importance of individual tags and their improper use. Google Translate does not give a correct translation. --Władysław Komorek (talk) 15:09, 16 March 2014 (UTC)
Wouldn't the translated version of Map Features be much better suited for newbies? Alternatively, you could work on Pl:How to map a; that page is like a dictionary that gives translations from words of your native language into tags. --Tordanik 18:23, 16 March 2014 (UTC)
We have translated the "Map Features" long enough and still have the problem with improper tagging. Nothing has improved. You wrote "Pl:How to map a, that page is like a dictionary", but it is not a dictionary and needs to be written and continuously updated.
Category is the easiest way to automatically creating the current list of translated tags.
Based on the discussion on OpenStreetMap Forum in Polish, new users are very unhappy with the lack of a list of tag names, understandable in their language. Most people are looking for the information based on Wikipedia, where they have categories in their native language. To use the search he needs to know, in advance, a specific tag name. Search of intrinsic tag is too time-consuming and discouraging them to continue mapping. That's why most new users only focused on adding a few POI. --Władysław Komorek (talk) 20:53, 16 March 2014 (UTC)
Perhaps I simply misunderstand what you are trying to do. But to me it looks as if you are trying to solve the following problem: A user wants to tag an object. He knows what such an object is called in their native language. He now wants to find out the tag for it.
But that problem can be solved with some of the suggestions I made above. If you add the word as a RelatedTerm to the page, for example, then the page shows up in the results when the user types the word into the search field. --Tordanik 22:09, 16 March 2014 (UTC)
I already have it. If you open a Polish tag, you'll see in a Polish template for ValueDescription or KeyDescription, equivalent to the key name and value name in the Polish language.
But this is not enough for the Polish newbies. Remember that often the same object can have different names. A similar problem, for example, have users in the U.S., when they are looking for a tag for the road and do not know that the tag for the road is called "highway". This is a big difference between seeking unspecified name and picking a name from the list. --Władysław Komorek (talk) 00:05, 17 March 2014 (UTC)

Should group name be added a language prefix?

In October 2015, this template has modified; a category name from 'group' is now automatically added a language prefix from 'lang' value. But this has caused another trouble.
For example, the page 'JA:Tag:railway=halt' already has a prefixed group name ('JA:鉄道'). So the category name has become 'JA:JA:鉄道' by adding language prefix automatically.
It can resolve if I change the group name to '鉄道', but it will cause another trouble; if a localized group name has same name to English version, the localized version of category Key descriptions for group "XXX" (created by Template:DescriptionCategories) can't exist independently because it duplicates with the English version.

There are two methods to avoid this trouble:

  1. The all localized group names should be added language prefix, and cancel to add language prefix automatically (by this template).
  2. Modify Template:DescriptionCategories to add language prefix to category name automatically, such as Key descriptions for group "ll:XXX". The all prefixed group names must be modified.

How should we resolve it? --Mfuji (talk) 16:56, 26 October 2015 (UTC)

Group names should not have any prefix. The categorization however is partly broken in languiages other than English as the stan dard template currently does not imply any language prefix for the category name. There are works to do to separate the localized group name and the category name (whose default is the group name, but still not necessarily translated).
There are many "groups" not working properly for sorting features,; and many red links there for missing categories or categories with mixed/random contents.
Only a few groups/feature are currently working almost properly but there are still issues before it can work completely and the solution applied on other groups.
This is work in progress (complicated by the fact that the Feature template has also some localized variants not working exactly like the English one (because the Engliush one is also defective and still ignores how to completely manage translations). — Verdy_p (talk) 12:50, 28 October 2015 (UTC)
In summary: for parameter group=*, just use a unprefixed feature name which will be displayed as is by the template (you can temporarily leave this name in English, but you can translate it to Japanese (don't forget to set lang=ja in the template): if you translate the term, the category translated to Japanese will be "Category:JA:<translated group name in Japanese>". When this category exists, the article will be sorted there.
If you have still not created the category, don't translated the group name (leave it in English), but you can still use lang=ja (the template will first look for "Category:JA:<untranslated group name in English>", then for "Category:<untranslated group name in English>" to sort your Japanese article "JA:<article name in English or Japanese>").
A few groups are being converted to sort them by language. A priori there's no longer need to use a localized version of "Template:ValueDescription" (which still uses the lang=* parameter, but soon you'll no longer even need the lang=* parameter as the language code will be autodetected for the article page name including the template).
Hope this helps. — Verdy_p (talk) 14:02, 28 October 2015 (UTC)
Group names are used in not only "Category:LL:<group name>" but for example key description's category as Key descriptions for group "<group name>" (without language prefix). Isn't it possible that multiple languages have (localized) group names accidentally and in conflict between category names of Key description? (This problem is, however, irrelevant to Japanese...) --Mfuji (talk) 17:37, 28 October 2015 (UTC)
Category:Key descriptions for group "<group name>" do not support any kind of classification of languages for now. All is mixed, and in fact most group names do not have therir own categories even in English. This scheme was added some time ago without any consideration about how it should be classified. I've not attempted to convert them with the languages bar, and prefixes compatible with Template:Langcode. In fact the scheme is not fixable for now, and I don't care much about them. For now it only works for English-only pages. There's a solution to develop, but if we keep that name in English, for other languages it will become Category:<Lang:><translation of:Key descriptions for group> "<group name>" and quoted group names will also be translated. Later it some categories will need to be merged (using soft-redirection templates like other translatable categories)
Note: I do not intend to translate the (technical) **tag** names, but "group names" / "feature names" (in mostly the same naming space as some groups are also isolated features) are not tags and are translatable.
A few groups have started to be translated in their categories (Sports, and Buildings), I using only these to finalize the translation scheme before going further for other groups. The problem is to manage the many legacy templates that have been translated using their own local schemes for specific languages (but that also don't work fully), without breaking all. There's a lot of cleanup work to do to collect everything and get the expected navigation. But with what I did, it cannot be worse than what there's now which is incoherent everywhere and full of red links for lots of missing categories or orphan categories. — Verdy_p (talk) 20:56, 28 October 2015 (UTC)
About your example category, you can look at what I did, but I've still not scanned all languages. It should be OK however for Japanese.
If you still have doubts, about what to do, use English only group names for now (even if this populates categories in mixed languages), they will be translated later. — Verdy_p (talk) 20:58, 28 October 2015 (UTC)
I personally never liked the group attribute exactly because it seems to have been added on a whim to the template, without a good way to use it. Besides this problem you mentioned, there are tags that don't have a well-defined group or belong to multiple groups. I think this parameters shouldn't be used at all, much less add a category. I remember that recently some users went around removing explicit categories from pages, "forcing" the use of this parameter (I don't think they did this out of bad faith, but a previous discussion would have been helpful). --Jgpacker (talk) 23:54, 28 October 2015 (UTC)
I see. I agree if it won't be needed to re-add namespace to group names. I also think the category name Key descriptions for group "<group name>" should be internationalized.
I also think that the group attribute isn't needed, because category can be used instead of it and more flexible. It is problematic (e.g. we can't use multiple group, and it may cause a problem I said), although there is only few benefit. I think it is better if important categories can be enumerated in the info box, instead of groups, then it will become much simpler and flexible. --Mfuji (talk) 11:37, 30 October 2015 (UTC)
I also agree that "groups" were designed only to refer to the name of main subcategories in the "Features" categories. For me they are just a few selected feature names (all translatable independantly of the technical set of tag, i.e. keys/values, used to implement them and that remain preferably in British English).
The bad thing about those "group=*" parameters is that they force the automatic inclusion in some categories not correctly designed an in fact never discussed. It is hard to work with all those Category:<Lang:>Key descriptions for group "<group name>" automatically generated. I would personnally only keep the category names based on the British English key names. But sorting features via the template is a bad idea, and it has in fact never worked correctly the way this was done, and it is not maintainable). — Verdy_p (talk) 13:07, 30 October 2015 (UTC)

Hi, I think, the "group categorisation" piece of code should be removed altogether from this template:

  • "because it seems to have been added on a whim to the template" I totally agree.
  • There is now a more flexible way to add tags to group-specific categories via Template:DescriptionCategories if you do want this kind of categorisation.
  • It doesn't seem to be very widely used: The subcategories of all the categories in "Category:Features/translations" contain a total of exactly 600 pages containing "Tag:" in their title.
The most prominent namespace is Pl:, totalling 280 pages. However, in the total Pl: namespace, only 36 Tag: pages use this template, the others still using Pl:ValueDescription -> no change.
The other two main users are JA: and Cs: at 110 pages each. Cs: is already using Template:DescriptionCategories for that, which means they don't need this code too.
JA: could be enabled in Template:DescriptionCategories to continue pointing to Category:JA:<Group> if wished. Mfuji, what do you think?

Cheers, Charel (talk) 21:31, 29 April 2016 (UTC)

Relation multipolygon and onRelation=no?

Discussion moved from Talk:Wiki

Hello, there is a debate (e.g. here) about whether a feature mapped as area will get onRelation=no or onRelation=yes. I had the impression, backed by many wiki pages, that multipolygon relations are an exception and are considered to be just areas. Therefore when a feature can exist as area or multipolygyon relation it gets onArea=yes and onRelation=no.

But user VerdyP claims that we have to set onArea=yes and onRelation=yes. I find this clumsy as multipolygon relations are areas and if we accept this idea then onArea=yes will imply onRelation=yes all the time so onRelation meaning would be not so clear any more.

Could you please state your opinion here?


Chrabroš (talk) 12:28, 14 May 2017 (UTC)

It has been the assumption for as long as I have been involved that onRelation, like onWay, specifically relates to relations that are not areas; that is the whole point of having a separate onArea flag. --Andrew (talk) 20:57, 15 May 2017 (UTC)
I agree with you that multipolygons fall under onArea, not onRelation. That convention is also documented on Template:ValueDescription, so I'm surprised that Verdy p isn't aware of it. --Tordanik 13:40, 21 May 2017 (UTC)
When and where was this agreed ? There has just been some proposals but no discussion anywhere, and many topics use onRelation=yes (including external tools) that do not have this subtle distinction. And I've seen people changing multipolyugon relations into very complex areas (single closed way) because their validator complained about this, and thinking it was invalid to have inner rings for holes and they dropped them, or removed a multipolygon made of several outser areas and replacing them by tagging multiple areas (closed ways) instead, meaning that they duplicated the same feature with two distinct very close locations such as a couple of buildings. — Verdy_p (talk) 17:21, 21 May 2017 (UTC)
Note also that you insist on this, then the icon for relations should be completely dropped everywhere (including for boundaries, and as well for turn restrictions as their real geometry is an oriented line even if it includes an optional via node). We have conflicting interpretations between the OSM representation (used by all external tools) and the effective geometry (which is very fuzzy, as almost all features could become a node, a line or a surface and there's no need to prohibit them). The definition on OSM of an area is a single polygon forming a single non-intersecting ring, it does not include multipolygons with holes or that at not fully connected and have several outer rings.
Nothing was really decided, someone jhust commented his opinion in an informal proposal that was never decided/voted. — Verdy_p (talk) 17:27, 21 May 2017 (UTC)

"But user VerdyP claims that we have to set onArea=yes and onRelation=yes. I find this clumsy as multipolygon relations are areas and if we accept this idea then onArea=yes will imply onRelation=yes all the time so onRelation meaning would be not so clear any more.".

Wouldn't it be easier to add separate parameters for multipolygons and closed ways; like this?:

  • onNode=
  • onWay= (as in an open way)
  • onClosedWay=
  • onArea=
  • onRelation=
  • onMultilinestring=
  • onMultipolygon=
  • onParent= (also known as a Super-Relation).

EzekielT (talk), 18:25, 20 July 2017 (UTC).

Rendering of areas

With osmcarto-rendering and osmcarto-rendering-size you can show an example how the surface is rendered. But it is unclear in what size this should happen. To give an example: Tag:leisure=garden Tag:leisure=pitch

I think they take too much space and it would be better to show them in context. Leisure pitch has eg a frame. Often a pattern is also included which should not be reduced or enlarged (eg forest). Most existing examples of rendering have the size 125x125 pixels. And that is too big for the box.

There is no recommendation yet. It should really be fixed. For icons it has proven itself well, but for surfaces I would not agree.--geozeisig (talk) 09:42, 4 June 2017 (UTC)

I agree that they take too much space, but then I feel they should not be in the infobox to begin with. To me, that's mostly a concession towards Taginfo's limitations, not the best possible presentation on a wiki page. --Tordanik 10:31, 4 June 2017 (UTC)
For reference, affected revision looked like that: https://wiki.openstreetmap.org/w/index.php?title=Tag:leisure%3Dgarden&oldid=1467936 I suspect that something with reduced vertical size would work well Mateusz Konieczny (talk) 10:26, 16 April 2019 (UTC)

Why does the template provide a different % than taginfo?

For example; in leisure=garden; the template says "11.18%" for ways; but when you go to taginfo itself (https://taginfo.openstreetmap.org/tags/?key=leisure&value=garden); it says "0.09%" for ways.

For trees; the template says "90.02%" for nodes; but on taginfo (https://taginfo.openstreetmap.org/tags/?key=natural&value=tree); it says "7.35%". That is a massive difference! What's going on?

EzekielT (talk), 18:50, 20 July 2017.

Unless I'm mistaken, those are two different statistics: The template shows % of features with that key (e.g. 11.18% of ways tagged leisure=*), whereas the Taginfo page shows % of all features in the database. I agree it's confusing, though. --Tordanik 14:34, 21 July 2017 (UTC)

I was wondering if that was the case. Thank you :)! Maybe we should add % of all nodes, ways, and relations in the database; as provided by taginfo, to the template, too?

EzekielT (talk), 11:09, 21 July 2017.

That part of the template is included from an external source, so we (wiki contributors) can't change it. Would need to be changed in the code. --Tordanik 15:26, 21 July 2017 (UTC)

Add incompatibilities

This template shows useful combinations, implications but not incompatibilities which exist between some tags.
I mainly have concern with power=* for which power=transformer is incompatible with building=* or even power=plant shouldn't be used in combination of generator:*=*.
It's pretty sure many other contributors need such a classification. —Preceding unsigned comment added by Fanfouer (talkcontribs)

We could add a new property to the data items, and make both {{KeyDescription}} and {{ValueDescription}} support it. This way it will automatically show up in all languages the moment data item has it. I just created incompatible with (P44) for this purpose - try to add it to a few data items (e.g. update the power=transformer (Q5254) -- click "add statement" at the bottom to add P44 with the needed values. --Yurik (talk) 23:55, 6 March 2019 (UTC)
This is great ! Thank you :) Fanfouer (talk) 00:07, 7 March 2019 (UTC)
Nothing against the property, but I find it a bit confusing that this new property has to be edited directly on the wikibase page while the others that are listed under "Useful combination" etc. have to be added on the normal wiki pages in {{KeyDescription}} / {{ValueDescription}}. Why is this so? What are your plans with what is currently listed in the "combination", "seeAlso", "requires" and "implies" sections? --Hufkratzer (talk) 19:29, 7 March 2019 (UTC)
@Hufkratzer: the goal is to migrate all other properties to the data items as well, and remove them from the template parameters. The only reason we haven't done it yet is because TagInfo does not yet support data items, and instead tries to (often incorrectly) to extract that data from template parameters. The current system of having different values depending which language you are reading is clearly a problem that needs to be solved. --Yurik (talk) 20:39, 7 March 2019 (UTC)
AFAIK when editing a wikibase page directly it is not possible to add a meaningful changeset comment. I think this is a big disadvantage. Can that be changed? --Hufkratzer (talk) 21:19, 7 March 2019 (UTC)
@Hufkratzer: I think it is possible, just not with the standard Wikibase interface. We could implement our own gadget to customize the UI (might take a bit of effort, but doable). There are many existing Gadgets we could use as examples. In the meantime, there is always a talk page where we can discuss certain aspects of a data item (not ideal, but still much better than having thousands of conflicting parameters in different languages) --Yurik (talk) 21:37, 7 March 2019 (UTC)
P.S. I have made a request for this feature, please track it at T217873. --Yurik (talk) 00:34, 8 March 2019 (UTC)
"the goal is to migrate all other properties to the data item" - this is a horrible idea, for start that makes changeset comments impossible and makes editing wiki even harder. Mateusz Konieczny (talk) 07:57, 8 March 2019 (UTC)
@Mateusz Konieczny:, creating and editing a wiki markup page is far more difficult for novices than filling out a pre-made form. The moment data items were added to the wiki, we got 10s of thousands of description edits, often for the items that have no corresponding wiki pages (in that language). In other words, it is far easier to add a translation for a key/tag in a data item than to create a full blown wiki page in every language. On the other hand, having 10 translated pages with mismatching definition of an item (requires/implies/... params) has very low value, and is confusing. Plus it makes it nearly impossible to accurately parse - taginfo simply skips many of the broken ones, and noone else AFAIK even tries to parse these parameters. So yes, it is desirable to move these things to the data items, while keeping free-form text on the wiki pages. Note that the infobox is just the first step -- we also want to migrate tables of data (like a list tag values appropriate for a key) -- those should also not be copy/pasted between languages, but instead auto-generated from the data items.
The ability to add summary is a very valid concern, and I am looking into it, but I don't think a complete mismatch between languages/unparsable data and inability to add edit summary are the same level of problems (especially because we can work around it by discussing things on the talk page). --Yurik (talk) 17:36, 8 March 2019 (UTC)
Yes check.svg
Everyone, you can now add summaries to your data item edits. Enable it in the preferences - gadgets tab, and you can try it on the sandbox item. --Yurik (talk) 21:58, 16 March 2019 (UTC)
If I click save, enter a comment, activate another browser tab (in Chrome) and come back the comment box is gone and my change is saved without my comment. --Hufkratzer (talk) 18:56, 26 March 2019 (UTC)
@Hufkratzer: do you click "ok" or "cancel" after you click "save", or do you just enter a comment and don't click a button? I see many comments that you entered in sandbox history (funny too :)). --Yurik (talk) 19:21, 26 March 2019 (UTC)
The comment box disappears before I click "ok" or "cancel", I just activate another browser tab. --Hufkratzer (talk) 21:15, 26 March 2019 (UTC)
I think this is standard Chrome-specific behavior (no idea why to be honest) -- See [1] and [2]. A better solution would be to use OOUI dialog lib, maybe @Minh Nguyen: might know how to do it? --Yurik (talk) 00:19, 27 March 2019 (UTC)
P.S. Come to OSM slack to discuss. I'm @nyurik there. --Yurik (talk) 19:23, 26 March 2019 (UTC)
Wouldn't this be the appropriate place to discuss this gadget? --Hufkratzer (talk) 21:15, 26 March 2019 (UTC)
Different types of discussion -- Slack allows direct communication, a chat, much faster to figure out what is going on. Phab ticket is for bug planning -- unfortunately I don't think Wikidata team has it as a high priority item, so it might take some time for it to happen there. --Yurik (talk) 00:19, 27 March 2019 (UTC)

truncation of changeset comments

Another issue with the gadget for changeset comments: If a very long description is edited the changeset comment will be truncated because there is limited space which is occupied by the long description, see example --Hufkratzer (talk) 20:38, 16 April 2019 (UTC)

Where this template may be edited?

https://wiki.openstreetmap.org/w/index.php?title=Template:ValueDescription&action=edit has just {{#invoke:DescriptionFromDataItem|main}} Mateusz Konieczny (talk) 12:15, 25 April 2019 (UTC)

@Mateusz Konieczny:, I believe that {{Description}} is still used to define the layout of the infobox. I'm not 100% sure as I no longer really understand the templates since the Lua port, but the documentation of Module:DescriptionFromDataItem seems to confirm it. --Tordanik 14:01, 5 May 2019 (UTC)
I asked author of recent edit for confirmation Mateusz Konieczny (talk) 16:57, 29 May 2019 (UTC)
Thanks Tordanik, that is correct. {{Description}} is still used for all styling. --Yurik (talk) 17:12, 29 May 2019 (UTC)

Script errors based on input

There are some pages in the category Pages with script errors due to issues with the input I guess namely Ko:Key:wikipedia and Pl:Key:addr:place among others. I could not figure out what is wrong there. Any ideas? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 16:16, 25 May 2019 (UTC)

Fixed the Ko:Key:wikipedia case -- it was actually an error in the template parameter - group was given as a link rather than a string, but now the code will handle it. --Yurik (talk) 23:17, 29 May 2019 (UTC)
@Yurik: - any idea what is happening in Pt:Tag:place=square? Mateusz Konieczny (talk) 18:12, 24 January 2021 (UTC)

move statuslink after all status values

currently the order in the doc is :

status: the approval status of this feature; possible values include:
statuslink: name of the proposal page, for linking

it should be :

status: the approval status of this feature; possible values include:
statuslink: name of the proposal page, for linking

I can fix it, but the doc page request to talk it here first :) Marc marc (talk) 11:04, 7 June 2019 (UTC)

I think you are right. --Hufkratzer (talk) 11:14, 8 June 2019 (UTC)
Resolved: done Marc marc (talk) 14:38, 8 June 2019 (UTC)
I do not think you would have needed to ask for such a small change in the documentation. This box is put on the doc page along with the rest of the documentation, but it is actually about the documented template itself. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 15:02, 8 June 2019 (UTC)
so the warning should be removed on the doc page ? Marc marc (talk) 20:44, 13 June 2019 (UTC)
If you think that warning is confusing you may improve/propose to improve wording of Template:Heavily used template Mateusz Konieczny (talk) 10:08, 14 June 2019 (UTC)
I think {{Heavily used template}} could be moved from {{ValueDescription/doc}} to {{ValueDescription}} ("...<noinclude>{{Heavily used template}}{{documentation}}</noinclude>" ). Then it would be more clear that the warning belongs only to the template itself. --Hufkratzer (talk) 10:25, 14 June 2019 (UTC)
I do not see a benefit in changing this. It even says "This template is used on a lot of pages!". --Tigerfell This user is member of the wiki team of OSM (Let's talk) 14:37, 14 June 2019 (UTC)

Stop Feature pages with missing images for deprecated tags

I propose to stop requesting images for features marked as deprecated - see Category:Feature pages with missing images that has many image requests, many of them for unimportant deprecated pages where adding image to infobox is not useful. I proposed to remove them from this category Mateusz Konieczny (talk) 11:46, 8 June 2020 (UTC)

+1 --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:11, 8 June 2020 (UTC)

Add category listing English language pages loading content from data items

Standard practice on English-language pages is to specify infobox template on Wiki Page rather than to load content from data items. I propose to create a category listing pages where anything is loaded from outside wiki page (from data items), so that such cases can be fixed. It would be done for English pages and potentially also other languages where there is no consensus to use data items Mateusz Konieczny (talk) 08:46, 21 June 2020 (UTC)

Please see Template_talk:KeyDescription#Add_category_listing_English_language_pages_loading_content_from_data_items --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:58, 21 June 2020 (UTC)

place a page in the language specific category even if it doesn't exist

See for example Yue:Tag:building=garage. This page in Cantonese is placed in the English category Category:Parking because Category:yue:Parking doesn't exist. It should placed in the language specific category even if it doesn't exist. It would be easier to create missing categories from Special:WantedCategories, but now no one knows that such category is needed. maro21 16:29, 6 January 2021 (UTC)

Merge discussions

There is a proposal to have one talk page for Template:Description, Template:KeyDescription and Template:ValueDescription and their doc subpages. See Template_talk:Description#One_discussion_place Mateusz Konieczny (talk) 08:04, 22 January 2021 (UTC)

I will start archiving resolved discussions from that page into Template talk:Description/Archive 1 Mateusz Konieczny (talk) 16:25, 24 January 2021 (UTC)

Ability to specify whether direction matters for ways and areas.

Knowing whether a way's direction matters is important when using a tag, so I think it would be useful to point this out in this template for tags where it does. I don't have a good idea about how it could be presented though. --GoodClover (a.k.a. Olive, ) (talk) 13:08, 12 June 2021 (UTC)

Compare wiki description with British English version of data item


This template compares the description given as a parameter with the description given in the corresponding data item, and if they differ it shows a red warning. The wiki uses British English, but the template seems to compare the description given as a parameter on an English wiki page (British English) with the US English description in the data item. An example is hazard=horse_riders. I propose, to avoid wrong warnings, the template should compare it first with the British English description of the data item (3rd line), and only if this is empty with the US English version (first line). --Hufkratzer (talk) 18:04, 20 August 2021 (UTC)

Description should be the same in the infobox and data item. Data item should be a copy of the Wiki page. I fixed the description. maro21 16:52, 10 October 2021 (UTC)
This wasn't a fix. The data item has two different fields, one for US English (first line) and one for British English (third line). If I configure the preferred language in my OSM account to "en-GB", iD shows me the description from the third line (British English), if there is any entered, and this makes complete sense. If I configure the preferred language to "en" or to "en-US", iD shows me the description from the first line (US English). Because the wiki uses British English, the wiki description should be the same as the description in British English in the data item (third line). But the description in US English in the data item (first line) may be different from the description in British English (third line). In the example that I mentioned, the British description has to use the expression horse riders, while the US description has to use horseback riders. It had been like that and your so-called fix has made it wrong. There is a similar problem especially with all tags that have "centre" in their description. --Hufkratzer (talk) 19:05, 10 October 2021 (UTC)
Why do you assume that "English" is US English? If the Wiki uses British English, fields in the data item are also in British English because data item is a copy of the infobox. maro21 22:15, 10 October 2021 (UTC)
I have already explained above that there are two different fields in the data items and how iD uses them. Do you think it makes sense to use both of these fields redundantly for British English and none for US English? The wiki itself uses only British English, probably for historical reasons, but the OSM website also uses "en" for US English and en-GB for British English (see [3]). See also wikidata. --Hufkratzer (talk) 11:46, 11 October 2021 (UTC)
iD and website use American English as default English, Wiki uses British English, AFAIK. maro21 21:17, 12 October 2021 (UTC)