Template talk:KeyDescription

From OpenStreetMap Wiki
Jump to: navigation, search

Proposed reuse for Machine-readable Map Feature list

There is a group working on a Machine-readable Map Feature list. In order to automatically harvest information about keys (which we call tag-defs) from the Wiki, this template should be slightly modified. —Preceding unsigned comment added by Gubaer (talkcontribs) 19:23, 21 December 2008

Proposed new arguments

  • displayName (optional): a display name for the key in the language given by lang. Will be used by interactive applications for drop-down lists, menu entries, etc.
  • onRelation (optional): whether this key can be used on relations either yes (default) or no
  • status (optional): the status of this key in it's life-cycle (similar to status in the template Template:ValueDescription). Either proposed, rejected, accepted (default) or deprecated. —Preceding unsigned comment added by Gubaer (talkcontribs) 19:32, 21 December 2008
Apparently onRelation is already present. I would also like to see a status argument, and would add it to the template, if nobody opposes. MHohmann (talk) 08:43, 16 February 2014 (UTC)

Proposed changed arguments

  • groups (optional): a comma separated list of groups this key belongs to. Groups should be declared with a new template Template:GroupRef. Example:
     groups={{GroupRef|name=naming|lang=en}}, {{GroupRef|name=non-physical|lang=en}}
—Preceding unsigned comment added by Gubaer (talkcontribs) 19:29, 21 December 2008
  • propose a solution :
    first, second ... up to 13 :) are the names of additional groups. It make list and categories for these groups. I did it in the template RU:KeyDescription --Dr&mx 20:42, 3 July 2011 (BST)

Proposed expansion of the template

The expansion of the template should include a reference to the category <lang>:Category:Keys. Example:


—Preceding unsigned comment added by Gubaer (talkcontribs) 19:40, 21 December 2008
probably [[Category:EN:Keys]] --dr&mx 20:07, 28 February 2012 (UTC)


New and changed arguments are optional. They shouldn't brake existing uses of the template. Neither does the declaration of a category.

We therefore suggest

  1. update the template
  2. adjust wiki pages (add arguments for the new parameters) step by step —Preceding unsigned comment added by Gubaer (talkcontribs) 19:40, 21 December 2008

Add a Proposal link

Hi, would it be a good idea to add a backlink to the proposal of a feature? Sometimes it is a very detailed help and gives further informations for usage, even on start of the feature --!i! 10:44, 17 August 2010 (BST)

Proposal - parameter - replaces

It might be useful to include a parameter which inidicates whether a key replaces another key; this would decrease the incidence of using "obsolete" keys. Example, see Key:power output, which refers to Key:power rating . . . which in turn redirects to Key:generator:output. --Ceyockey 13:17, 24 November 2010 (UTC)

well, i saw your comment by chance (actually by using "What links here") when reorganising some power keys ... sorry for destroying your example ;-) (I won't change the links here, though) -- Schusch 23:38, 24 November 2010 (UTC)

Proposal - value interpretation

I think it would be really useful if the description also included information about the scale type and the default unit of the value. This would simplify automatic conversion of values (e.g. for people who prefer inches and feet instead of cm and m).

Examples (I think that's the easiest to explain what I suggest):

key scaleType defaultUnit
width number m
voltage number V
wires count
population count inhabitants
lanes count
ele number m
include number  %
maxweight number t
maxspeed number km/h
website link http://
email link mailto:
name text
highway list
amenity list
start_date date

Therefore valid scales could be 'number', 'count', 'link', 'text' (maybe we should distinguish between texts which "can" be translated like "name" and those which can't? are there any?), 'list' (for keys like highway, amenity, landuse, ...), 'date', etc.

What do you think? -- Skunk 15:36, 17 October 2011 (BST)

Clean-up/Translation out of Sync

There are even two different french templates: FR and fr
  • the "available languages" show different languages dependent on the language one choses, e.g.:
english template shows 13 languages but no German one (polish template similar)
french template shows 5 languages and exists a second time with no other languages: french
netherlands template shows no other languages (german template similar)

As a Newbie (at least regarding templates) I don't feel able doing anything to make these things clear and homogeneous --Rennhenn 15:13, 23 December 2012 (UTC)

By putting the template in those categories, you put all pages that use the template in those categories too. Since only the template itself needs cleanup, that's obviously not right. --Cartinus 18:32, 23 December 2012 (UTC)
Sorry for inconveniance, I was not aware of that - thanks for "repairing" --Rennhenn 19:52, 20 January 2013 (UTC)
All pages should have a working language bar now. German shows up as untranslated, because the language bar expects "DE" (like all the key pages themselves have), but the template has "De". If you rename the template, you have to edit all the key pages too, so I'll leave that for someone in Germany. --Cartinus 18:32, 23 December 2012 (UTC)
Thanks --Rennhenn 19:52, 20 January 2013 (UTC)

Overpass Turbo link

I don't think the recent addition of the Overpass Turbo link to the template is a good decision. Even though that site is a lot more accessible than the plain Overpass API, it is still suited for advanced users only - for others, any Overpass query IDE is necessarily confusing. But perhaps more importantly, its inclusion here is redundant because there is already a link to overpass turbo on all Taginfo pages, along with links to XAPI, JOSM, and many other statistics that are not directly linked from the infobox. So I don't see a reason to give special prominence to the Overpass Turbo link when Taginfo already neatly collects all the relevant resources. --Tordanik 18:23, 26 February 2013 (UTC)

This was initially suggested by Zuse at Talk:Overpass_turbo and added shortly after. I can see that this link shouldn't get as much prominence as taginfo for example. But, I still think there should be some room for this, too. (The wiki is not for beginners only and the link on taginfo may not be known by everyone; the way via taginfo also adds one unnecessary page load.)
After the few layout iterations, I think we have found a good solution for this now: the new "tools" section.
--Tyr (talk) 23:48, 2 March 2013 (UTC)
Danke :o) --Reneman (talk) 00:03, 3 March 2013 (UTC)

Stale links

Combinations worldwide (tagstat.hypercube.telascience.org/tagdetails.php) seems to be dead. Is this a permanent situation? If so, should we remove the link? Mmd (talk) 13:14, 23 March 2013 (UTC)

I guess it's really dead, but I'm not sure. The Tagstat page doesn't say anything about the current situation. Maybe we should simply email User:Petschge and ask. --Tordanik 20:49, 23 March 2013 (UTC)
TagStat still seem to be dead. I've removed it now. Also Tagwatch is discontinued, see[1]. I've commented out both links and added one to taginfo. The Tagwatch page does list some other useful pages. Not sure if any of those should be linked.--Salix alba (talk) 05:40, 8 March 2014 (UTC)
Good call on removing the inactive services. However, the new Taginfo link doesn't add any value because it's the same one already available in the Taginfo box. It might be more helpful to link to some of the regional versions of Taginfo instead, thus compensating for the removed regional tagwatch links. I'm not sure which ones to pick, though. --Tordanik 06:56, 8 March 2014 (UTC)
I have removed the duplicated global taginfo link and replace it (probably temporary) with links to US, UK, France and Italy (currently having problems?) versions. I would add Germany as well, but I haven't found it. Chrabros (talk) 03:32, 9 March 2014 (UTC)

Proposed seeAlso

Hi, I would like to add seeAlso to this template, same as seeAlso in ValueDescription. Sometimes it could be handy. Any objections? Chrabros (talk) 03:34, 9 March 2014 (UTC)

Proposed removal of onRelation

Hi, I would like to propose the removal of onRelation=

As it seems this icon has not really clear definition and causes a confusion.

See the discussion here Talk:Key:building#onRelation.3F.

The short summary of views is:

Which is odd as just below is a taginfo window indicating that the tag is used on relation in many cases.

  • there are really no tags which can be used only on relation. Therefore the icon onRelation is useless anyway. See relation:multilinestring.

So I am proposing to remove it.

Or maybe if someone know the definition then please write it here so we have one clear definition to use.

Chrabros (talk) 04:46, 9 March 2014 (UTC)

No matter whether we go with your opinion or mine, there are still cases where onRelation would be set to yes. So I don't see why we would want to remove it. Providing a clear definition is a good idea, but because of the recent discussion I fear the two of us will not be able to agree on one. I would be interested in other people's opinions on the topic, though.
For those who didn't follow the discussion: My point of view is that:
  • onArea=yes means that the tag can be used on areas, modelled with a single closed way or as a multipolygon
  • if a tag can only be used on areas, then use
    • onWay=no, to distinguish it from tags that can also be used on linear ways
    • onRelation=no, to distinguish it from tags that can also be used on other relations than multipolygons
--Tordanik 17:01, 9 March 2014 (UTC)
I do not see why we could not reach an agreement. The previous debate might be little bit too hot but this was partly to my mistakes while not keeping up with two separate threads. Sorry for that. I have learned that you are nice person since then. ;-)
Anyway. We could change the popup "Used on areas" to either "Used on areas (incl. multipolygon)" and similarly "Used on relations (excl. multipolygon)". And document it somewhere clearly as well. Chrabros (talk) 02:45, 10 March 2014 (UTC)
Thanks for the compliment. ;-) I fully support your suggested change. At the same time, I would suggest to point the link behind the area icon to Area. The current link target section no longer exists, and the Area page fits the icon's meaning well. --Tordanik 16:49, 13 March 2014 (UTC)
I have added links to Template:ValueDescription just now. They lead to Node,Way,Way#Closed Way,Way#Area and Relation.
It seems to me more consistent than to point to Elements for Node, Way and relation and then to Area.What do you think? Chrabros (talk) 02:53, 14 March 2014 (UTC)
I would have linked area to Area, which is called the "main article" even at your link target and is consistent with Node, Way and Relation. I also think the closed way icon is pointless, but it was not you who added it, so that's a topic for a separate discussion. --Tordanik 16:39, 15 March 2014 (UTC)
PS: Due to unrelated reasons, I've just edited ValueDescription, and as a small additional change in the same edit I've changed the area link to Area. But I want to make it clear to you that you can still give objections and change it back, I didn't intend to work around this discussion. --Tordanik 17:25, 15 March 2014 (UTC)
OK, no problem. :-) Chrabros (talk) 02:32, 16 March 2014 (UTC)

Is the group still useful?

Now Tagwatch has gone, can the group parameter go with it or is there someone else who uses it? --Andrew (talk) 14:22, 9 March 2014 (UTC)

I like Group. And I think we can make it better by adding a clickable link to the wiki page of the Group. Something like Up in the wiki structure. Clicking Group Annotation would lead do Annotations etc. What do you think? Chrabros (talk) 02:45, 10 March 2014 (UTC)
No one is protesting. I will try to change it. Maybe you will like it. Chrabros (talk) 03:49, 14 March 2014 (UTC)
I'm not necessarily opposed to this, but I think that distributing documentation across too many different pages increases the risk of duplication, contradictions and outdated pages, and also makes it hard to find what you are looking for. There are some cases where a page about a larger concept in addition to the individual Key/Tag pages makes sense, but the "Annotations" example shows that not all groups of tags are that way. Deleting the Annotations page and changing all links to Map features#Annotation wouldn't lose one bit of useful information. --Tordanik 16:31, 15 March 2014 (UTC)

I think,would be better to link group name to category. --Władysław Komorek (talk) 09:15, 14 March 2014 (UTC)

That is a nice idea. What I do not like about it tough is that category lists all tags translations as well. Don't you think that it is a little bit mess there? Also the Feature page I am linking usually has some additional explanatory text which might be handy. Chrabros (talk) 07:10, 15 March 2014 (UTC)
Category is the "gold mine" when looking for additional information. This link is better than the "See also". Category also includes the Feature page.
All translation pages should be grouped separately, as I did with "Pl" --Władysław Komorek (talk) 19:31, 15 March 2014 (UTC)
Yep, I like your categories. I am trying to do the same in Czech Documentation category. But I am a lone Czech translator so it is slooooow.
But the other translators do not care so the English categories pages are in mess.
Also there are many tags falling in two or more categories, whereas Group is just one. So it makes sense to me to have link to a Group in the box where is just one space. Links to Categories are at the bottom after all. No? Chrabros (talk) 02:36, 16 March 2014 (UTC)

native_value and native_key parameters

Transferred to Template talk:ValueDescription#native_value and native_key parameters --Władysław Komorek (talk) 15:52, 16 March 2014 (UTC)

Reimplementation of KeyDescription and ValueDescription templates

I have substantially overhauled the {{KeyDescription}} and {{ValueDescription}} templates, with the new versions at User:Moresby/KeyDescription and User:Moresby/ValueDescription. I am looking for comments on this discussion page and would value any constructive contributions. Thanks. Moresby (talk) 18:57, 30 March 2014 (UTC)

Website and URL pattern

I've just added two parameters, |website= and |url_pattern=, for keys which relate to a specific website. You can see them in use on Key:openplaques_plaque, but the labels are not displaying properly. Can someone help, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:29, 1 April 2014 (UTC)

I've fixed what you were trying to do - there's a really painful interaction between template parsing and whitespace, which is where {{if}} comes in, and additional entries were needed in {{DescriptionLang}} - but I have a feeling that there's going to be some different views as to whether it's a good change. On one hand, there's not going to be many keys which have a website/database dedicated to them, I guess, which suggests the information should go on the description page, rather than the description box. Thereagain, it's a pattern which could be applied to other keys, giving a standard way to capture the way of tying a value to a URL. I'll leave it to others to comment. Moresby (talk) 17:25, 1 April 2014 (UTC)
You asked for a comment. My thought process went as such: (1) Neat idea, (2) but this would only be needed for a few keys so perhaps just put it in the page's general text, (3) on second thoughts having it in the template allows data users to get at the data more easily. In conclusion, I'm in support of Andy's changes. For a bit more context see this mailing list post: https://lists.openstreetmap.org/pipermail/talk-gb/2014-April/015953.html Btw thanks Moresby for all your recent work on the template. --RobJN (talk) 19:20, 1 April 2014 (UTC)
Putting it into a separate template would still allow automatic extraction, though? In the main infobox, it feels like too much of a niche entry to me, since all the other entries are really core facts. After all, URL patterns are probably not really interesting for most readers. --Tordanik 15:24, 2 April 2014 (UTC)
Providing general readers with the originating website (surely a core fact) and URL pattern helps them to source the data. That's a good thing, right? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:01, 2 April 2014 (UTC)
From the perspective of a general reader, the originating website is already clearly visible from the introduction text, typically in the first sentence. As for the URL patterns, I think a textual "how to map" description is more helpful than some regular expression. Also note that for some tags, e.g. wikipedia and wikidata, the value is obtained more easily by copying the page title rather than manipulating the URL.
In the spirit of compromise, though, how about stating "External reference" somewhere in the infobox (perhaps in the Group Section? it is definitely a tag classifiction), with a "show details" like the current tools list? --Tordanik 19:18, 2 April 2014 (UTC)
I do not like adding these parameters as they are too specific to be included here. Chrabros (talk) 00:36, 3 April 2014 (UTC)
Agree with above. --Władysław Komorek (talk) 07:14, 3 April 2014 (UTC)
Thank you for fixing the template(s). This information definitely needs to be in a template, so that it is machine parsable. I favour putting it in the infobox, not least so that people can see whether or not a key includes a value that is intended to be looked up online. It could perhaps go nearer the bottom of the infobox, if the current position is too prominent. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:52, 2 April 2014 (UTC)

Redirect undone

I've undone the recent redirect if this template to a user-space version, since that did not seem to have been kept in sync with recent developments here, such as the URL and URL pattern attributes and tracking category. See above section. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:04, 17 April 2014 (UTC)

These additional attributes appear to be controversial, however, and there has been no new input for the past two weeks. Allowing for this template standardization to happen is another reason to bring that discussion to a conclusion. --Tordanik 00:56, 18 April 2014 (UTC)
I prefer Moresby's template (for English tags) over URL and URL pattern. So I believe that it would be better to keep Moresby's template and try to convince him to add these to his templates instead of reverting. Chrabros (talk) 06:45, 18 April 2014 (UTC)
Thanks Andy, Tordanik and Chrabros. I don't really want to take one side or the other in the "should these elements go into the description box" discussion, so I've put the functionality into the new boxes simply to match the current template. If there's a consensus to leave it in or take it out, I or someone else can make any necessary changes. That done, I've put the redirect back again. Moresby (talk) 15:41, 18 April 2014 (UTC)
That's great, thank you. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:30, 18 April 2014 (UTC)
I don't think you can avoid taking sides by effectively adding these fields to dozens of templates that didn't have them before. Regardless, it appears we need to have that discussion again at User_talk:Moresby/Description#Website_and_URL_pattern. --Tordanik 20:13, 18 April 2014 (UTC)
You're right - there's no way to take neither side completely, if I'm going to continue to take this work forwards. Given the options, this looked like the path of least resistance: this affects only two pages at this point, Key:openplaques_plaque and Key:openplaques:id, and the remaining hundreds of pages look just the same as they would have been without this addition. I've said that if there's a consensus, I'll happily implement it; also, if anyone wants to have an edit war, go ahead, just please don't break the templates in the process. I just don't want an as-yet-unsettled difference of views to stall a bigger task. Moresby (talk) 20:43, 18 April 2014 (UTC)

Website & url_pattern, redux

What are the substantive objections to these parameters? A prose description as suggested above, will not be machine readable. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:20, 18 April 2014 (UTC)

Machine readability can be achieved even if this is not included in the infobox, and I never meanted to argue against a machine-readable solution either. Therefore, the focus on the discussion should be on whether and how to present this information to a human audience.
Keeping this in mind, I think that including these facts in the infobox is just not helpful enough to the typical reader to justify four more lines. Furthermore, such rarely used parameters would cause the infoboxes on different pages to look very different, reducing visual consistency. Finally, I believe that people without technical background might not easily understand the "url pattern", so even leaving space concerns aside, the inclusion could create confusion rather than being helpful.
One way to address these problems would be to reduce the space this information takes up, e.g. by using my suggestion above (integration into group section) to limit the additional number of lines to 1, and keep the more technical data somewhat hidden. If we cannot agree on a solution along these lines, then I don't see a good alternative to an entirely separate template displayed towards the bottom of the page. --Tordanik 22:46, 18 April 2014 (UTC)
I agree with Tordanik. Chrabros (talk) 03:42, 19 April 2014 (UTC)
I also agree with Tordanik. This feature is too rarely used to justify adding complexity to this template (which is used pretty much everywhere). Creating another template for url_pattern and related features would not only keep it machine readable, it would make it even more flexible. --Jgpacker (talk) 01:03, 24 April 2014 (UTC)
There are not four new lines, but two (one for each parameter). If desired, they could be moved lower in the infobox. Infoboxes using them would not look "very different" to those not; the difference is relatively minor. We can link the "URL Pattern" label to an explanatory page. I'm not sure what you mean by "integration into group section" (please explain), but hiding data is not a good idea; it leads to people failing to enter or update it. that said, I'd like to see more people's views on this; do we have somewhere to flag up such discussions? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:20, 19 April 2014 (UTC)
In your openplaques example, there are even 5 new lines (in the visual output, not the source code): "Website", the URL, "URL Pattern", the pattern (2 lines). With shorter patterns, there would still be 4 lines.
What I meant with Group integration: There is a "Group" heading in the infobox, for your openplaques example this currently contains the "Historic" classification. My suggestion would be to additionally display an "External reference" (or similar) classification if the website and/or url_pattern parameters are filled in. The url pattern and website should not be displayed normally, but should be revealed by interacting with the "external reference" label, e.g. by hovering over it or clicking on it.
If you want to get more people involved, you could try the "Wiki Team" subforum on forum.osm.org. Not many people are active there either, but it could still get a few more eyeballs onto your suggestion. --Tordanik 10:26, 20 April 2014 (UTC)
I've posted neutrally-worded pointers there and in a couple of other places. I'm going to be mostly offline for a week; let's wait and see what others think, and pick this up when I return. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:24, 21 April 2014 (UTC)

How about 'pattern' or 'regex_pattern' ?

We could add a generic pattern key, which would not be shown to normal users (because it's only useful to programs or advanced users) and would contain a regular expression to find typos and/or errors (the regular expression would be able to validate every possible good value this key could have, and trying to avoid false negatives).

For example:

  • the key layer=* would have as pattern the regular expression ^(0|-?[1-5])$ (number from -5 to 5).
  • The key contact:website=* would have ^(https?://)?([a-z0-9-]+\.)+[a-z]{2,4}(/.*)?$ (a valid URL) (note: this regular expression doesn't support IP numbers).
  • The key population=* would have ^[0-9]{,10}$ (integer number from zero to 9 billion).
  • The key width=* would have ^([0-9]*(.[0-9]+)?( ?([ck]?m|mi|ft))?|[0-9]+'([0-9]+\")?)$ (quite permissive regular expression, you can test it here).
  • The key name=* would have [^\s]+ (has a sequence of one or more non-whitespace characters).
  • Etc.

The flavor of regular expression would be POSIX extended, which is the one used by the Overpass API (I should note that there are some small differences between in regular expressions between the Overpass XML Flavor and OverpassQL Flavor, and the one used should be the Overpass XML Flavor because it reduces some unnecessary character escaping)--Jgpacker (talk) 14:52, 3 May 2014 (UTC)

Good idea! It is right place to put in documentation (i.e. this wiki) instead of some program code. OSM data used by many users, sometimes not really involved in full stack of OSM technologies. Xxzme (talk) 03:23, 22 July 2014 (UTC)
I think we have discussed this idea previously. As long as it isn't visible in the infobox by default for normal users, I'm fine with it. I have some questions and ideas, though:
  • Which mechanism you would use for hiding this from normal users? Not show it at all and only have it visible in the source, or would there be some option to make it visible?
  • There are some value types which are used with multiple keys, e.g. length, width, and height (which are documented here. Would it be possible to prevent duplicating the regular expressions for these?
--Tordanik 16:33, 22 July 2014 (UTC)
Hi Tordanik,
  • I think either it wouldn't be displayed (only documented and visible in code), or a link would be added besides the overpass turbo link, adding something like <a href="overpass turbo with regexp">(with regexp)</a>.
  • I'm afraid it wouldn't be possible to avoid duplicating the regular expression for these keys.
--Jgpacker (talk) 14:17, 23 July 2014 (UTC)

Proposal "appliesTo"

Every key applies to some features. I propose to add a new parameter "appliesTo" analog "seeAlso". --Rudolf (talk) 08:06, 3 June 2014 (UTC)

AFAIK the parameter "combination" is used in a similar way. Could you elaborate further on how this parameter would work? For example, how would this parameter look on the template in the page Key:capacity ? Would it be used on pages like Tag:highway=steps ? --Jgpacker (talk) 19:08, 3 June 2014 (UTC)

Documented values

Hi, the new feature "Documented values" seems not to work very good. Please see leaf_type=*. When introduced this tag had 4 documented values which was OK. Then I have translated it to Czech and it reports 8 documented values now. This is little bit odd. I do not think that translations should be counted as a new values. Are you able to fix this? Chrabros (talk) 07:32, 11 June 2014 (UTC)

I also noticed this problem. I agree it can be a little confusing. --Jgpacker (talk) 20:34, 11 July 2014 (UTC)

Deprecation of parameter "seeAlso"

Usually the wiki page already has a "See Also" section, which tends to be more informative than what the content of the parameter "seeAlso=" could be (because it has more space to explain why other pages/tags are related). Tools like taginfo derive related tags from the tags linked on the page's content, so as far as I can see, this parameter isn't being used, and doesn't really seem useful by itself. That's why I propose we mark this parameter as deprecated on this template, so no one feels obligated to add it, unnecessarily duplicating information already shown in the page. Oh, and I only am proposing this after using this a couple of times, and seeing no benefit on this parameter. --Jgpacker (talk) 20:31, 11 July 2014 (UTC)

I quite like seeAlso section. It seems to me very easy to read and sometimes useful. I wouldn't deprecate it. Chrabros (talk) 06:58, 14 July 2014 (UTC)
I prefer the traditional "See also" section. As an infobox parameter, this can get quite large and inflates the size of the box, pushing images and similar content too far towards the bottom of the page. The "See also" section also allows adding a description to the link, which is not possible in the infobox. It's ok if people want to keep it around, but I'm not a fan. --Tordanik 19:49, 15 July 2014 (UTC)
Small section in infobox is good place to link page with other tags. Use bigger section if you need to post external links. Don't move tags is infobox. Xxzme (talk) 19:58, 15 July 2014 (UTC)
So what do we do now? Users are starting to simply copy all tags from the "See also" section on the bottom of the page into the infobox, without any explanatory text. I still believe that the seeAlso parameter shouldn't have been added. The infobox needs to be used sparingly, only showing the most important information. --Tordanik 20:21, 26 March 2015 (UTC)

Implemented "requires" section

Example 1:

| key         = crossing
| required=*{{Tag|highway|crossing}} or
* {{Tag|railway|crossing}}

Example 2:

|required=* {{tag|natural|grassland}}

Xxzme (talk) 16:52, 27 July 2014 (UTC)

OK yes, please. I'm here for this exact reason. What is the usual route for changes of this template?--Jojo4u (talk) 23:19, 24 January 2015 (UTC) OK would be helpful. --Tordanik 12:42, 28 January 2015 (UTC)

See also Request for namespace with machine-readable definitions Xxzme (talk) 04:16, 23 February 2015 (UTC)

Implemented as 'requires=', 3 Jan 2016

Removing parameter "lang="

As far as I can understand, the parameter "lang" from this template and {{ValueDescription}} are completely unnecessary right now. The language is already automatically inferred from the page's prefix, so it doesn't need to be manually specified. Anyone against removing it from the documentation, and perhaps updating the code to simply pass the value of {{langcode}} to {{Description}} ?--Jgpacker (talk) 19:58, 29 August 2014 (UTC)

"May Be Used On Areas" + "Should Not Be Used On Relations" -> What About Multipolygons?

Considering a multipolygon relation is meant to be a stand-in for a closed way for any area-feature, I suggest modifying this template slightly. If onArea=yes but onRelation=no, currently the key description box says "should not be used on relations"; perhaps it should say "should not be used on relations (except multipolygon relations)" or "may be used on multipolygon relations". Vid the Kid (talk) 20:54, 27 February 2015 (UTC)

I'm not sure. I think this would add to the confusion. The idea is that multipolygon relations are areas. We don't say "should be used on ways (except on closed ways)" when we have the attributes onArea=no and onWay=yes. --Jgpacker (talk) 21:36, 27 February 2015 (UTC)
Perhaps it would be less confusing to change the mouseover description of the area icon to "may be used on areas (i.e. closed ways and multipolygons)"? --Tordanik 09:49, 28 February 2015 (UTC)
I like this idea. Maybe it could be and multipolygon relations instead of and multipolygons. --Jgpacker (talk) 14:30, 28 February 2015 (UTC)

Edits since January 2015, consider reversion

I’m proposing rolling back this and some other pages to the beginning of this year at Template talk:Description#Edits_since_January_2015.2C_consider_reversion.--Andrew (talk) 06:35, 21 May 2015 (UTC)