Template talk:KeyDescription

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

OK, The language bar is unnecessary on the template itself due to internationalization; In this case is it technically possible to make it disappear from the top of the page "Template" without harming the internationalization function? I do not know how to do it! --Gnrc69 (talk) 15:40, 26 November 2016 (UTC)
No the language pbar is necessary and part of the generated content, because key description pages are themselves translated, and need this bar !
This is not related at all to the internationlisation of the template itself: it just shows that a language bar will be displayed (nont autotranslated templates should place their navbar across template version in their doc page), not above the example display (which is used as a "safety" test for edits when previewing any changes in templates: we should avoid "includeonly" sections for templates, except for the generated autocategorization of pages including the template, or if the current code still has no safe mode for previewing, and tests are fully integrated in the doc page). — Verdy_p (talk) 18:36, 26 November 2016 (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)

"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)

Or maybe it should be like this:

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

--EzekielT, 10:35, 17 July 2017 (UTC)

Clearly not needed at all. — Verdy_p (talk) 11:17, 18 July 2017 (UTC)

Some things can only be mapped as a closed way as opposed to an open way; e.g. circular barriers. Maybe there are such examples in which a key or tag may be used on multipolygons; but not normal relations?

--EzekielT, 13:14, 18 July 2017 (UTC)

Has any real progress been made toward normalising the tag system?

I'm having a lot of trouble trying to edit just the North American part of planet.osm. As far as I can tell, the keys seem to have been selected in an ad-hoc way. There are more than 9000 unique-ish keys, which is far more than there should be even in the worst case. A lot of the information tagged shouldn't be in a mapping database because it's (a) ephemeral or (b) irrelevant to the purpose of a vanilla map. I'm not even completely sure whether "amenity" is meant to be the key, and "restaurant" the value, or "restaurant" is the key and "amenity" is just a grouping that wasn't meant to appear in the database. They're both used as keys! And that's one of the most rational bits of adhockery.

There are more than 2G lines in the chunk I'm working with, and that's clearly far more than any human being can edit by hand unless they want to make it their life's work, which I don't. But to filter it under computer control, the one who writes the filter has to understand what to keep, what to modify to make it conformant, and what to discard as irrelevant. I don't understand that yet, although Goddess knows I've tried.

--Niemand (talk) 20:39, 19 July 2017 (UTC)

You will generally get more people answearing your question if you ask on the mailing lists, forum or help forum. In general bear in mind that you can discard any tag that you are not interested in if you are processing the data set for your own use and not editing OpenStreetMap.--Andrew (talk) 22:13, 19 July 2017 (UTC)
I was hoping this was an active project. Of course, if I have to ask on the list, then that's probably my answer right there! :-\ --Niemand (talk) 22:41, 19 July 2017 (UTC)
No, there isn't really any serious effort to change old tags like amenity=restaurant at the moment. It would mean quite a lot of breaking changes to data consumers, plus changing the habits of thousands of mappers. I actually agree with you that the tagging system is unnecessarily messy, but there isn't really the kind of process or mentality in place that would allow for such a far-reaching change to be adopted. For better or worse, changes to tagging conventions happen in small, incremental steps.
When writing an application consuming OSM data, the way to deal with this is to adopt a whitelist approach: Only use correctly tagged features that are relevant to your use case, ignore everything else. So don't look at all the keys in the database and try to figure out what to do with each one. Instead, learn how the objects you need are supposed to be tagged (the wiki should usually tell you that), and only ever consume that handful of keys.
And yeah, there are more people active on the lists and forums. Asking there most likely won't give you a more satisfying answer to this particular question, but it's something to keep in mind for future questions. :) --Tordanik 14:18, 21 July 2017 (UTC)
"As far as I can tell, the keys seem to have been selected in an ad-hoc way. " - yes, you guessed correctly. In general it is
as it is offtopic on discussion page of this specific template Mateusz Konieczny (talk) 18:44, 21 May 2020 (UTC)


Wikidata-Links with a prefixed "P" e.g. P137 for operator=* do not lead to the desired page (P137).--geozeisig (talk) 10:48, 11 September 2017 (UTC)

@Geozeisig It appears to work now Mateusz Konieczny (talk) 18:43, 21 May 2020 (UTC)

xmas:feature link to taginfo

The link by xmas:feature to taginfo is not correct at the moment. https://taginfo.openstreetmap.org/keys/xmas%253Afeature

https://taginfo.openstreetmap.org/keys/xmas:feature would be correct

--Rza31 (talk) 08:20, 2 December 2017 (UTC)

Translate taginfo title attributes

Hi, Is it possible to translate the taginfo title attributes where it says how many times the feature is used? The RedBurn (talk) 09:16, 14 March 2018 (UTC)

This is not made directly by this wiki but by an extension ({{#osmtaginfo:||key=*|value=*|rtype=*}}) that embeds the Taginfo box within an "IFRAME" loaded separately of the wiki page, from the external taginfo site.
And for now there's no way to instruct that external website to format the rendered content in a specific language using an additional "lang=*" parameter.
So the "#osmtaginfo" just returns an IFRAME requesting the HTML from "//taginfo.openstreetmap.org/embed/key?key=*" or "//taginfo.openstreetmap.org/embed/tag?key=*&value=*" and does not transmit any language parameter; taginfo will return the HTML only in English...
This is a request to do to TagInfo site authors to add support for the parameter, and then to ask to the "#osmtaginfo:" extension so that it transmit the language parameter.
For now what is displayed is similar to this web page: "https://taginfo.openstreetmap.org/embed/key?key=place&lang=fr" (note that it is not translated at all even if there's an attempt to transmit a lang=fr parameter to ask for French, the result remains in English only, even if the Taginfo site has support for translations, but not for this "embeddable" format) — Verdy_p (talk) 13:58, 14 March 2018 (UTC)
Thanks for the very useful info Verdy_p! I've filled an issue there: https://github.com/taginfo/taginfo/issues/224 The RedBurn (talk) 08:57, 15 March 2018 (UTC)

Using structured data items

I wrote a modified version of this template that can also pull data from the corresponding Wikibase item. This should allow us to consolidate all data about a key in one place, make it easier to edit (e.g. adding a translation would not require creating a wiki page, copying templates, etc), and let 3rd party devs use the data directly. I am not yet sure how we should highlight when the template's parameter is different from the wikibase item - it adds to several tracking categories, and also draws both descriptions, one in red. TBD. --Yurik (talk) 06:30, 28 September 2018 (UTC)

Double URL encoding in Taginfo links

Regarding keys including colons, we have the issue that the taginfo URLs are encoded twice (already reported here https://forum.openstreetmap.org/viewtopic.php?pid=743592#p743592). I could not find the correct spot to fix it, but maybe @Yurik can help? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:20, 29 March 2019 (UTC)

@Tigerfell fixed. --Yurik (talk) 19:46, 29 March 2019 (UTC)
Thanks. Great that we can count on you! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 07:49, 30 March 2019 (UTC)

Add alt-text to small images used as links

Could we please edit the template to include alt-text for the small images like the gray and red pencil shown to edit Wikibase items and the proposal link, and to show if onNode, onWay and onArea etc are yes or no? Right now, if you try to view wiki pages without loading images, these features are invisible. This would be important for usability by blind and limited-vision users, and it will also help users like myself who are on expensive metered internet connection and like to avoid loading images unnecessarily. I believe alt-text is best, but something that also shows on hover-over would also work. --Jeisenbe (talk) 12:13, 4 August 2019 (UTC)


What about a `conflictswith` property which specifies with what key/tag combination the key must not be used with? Yurikbot could then use that data to populate and sync Data Items. --Valor Naram (talk) 12:37, 28 December 2019 (UTC)

The template already reacts on https://wiki.openstreetmap.org/wiki/Property:P44 defintion on data items but I don't know how to set up this directly on template Fanfouer (talk) 20:51, 12 January 2020 (UTC)

I suggest we sort combines values from wikibase

See https://wiki.openstreetmap.org/wiki/Key:distance_from_road for an ugly example.--PangoSE (talk) 22:22, 3 January 2020 (UTC)

agree. anyone wants to try to implement it? We have a sandbox for this template. --Yurik (talk) 22:27, 3 January 2020 (UTC)
@PangoSE Can you give a new example of the problem? In this specific case page is gone due to other, mostly unrelated, issues Mateusz Konieczny (talk) 18:42, 21 May 2020 (UTC)
@Mateusz Konieczny no, I will comment here if I find another example.--PangoSE (talk) 09:48, 25 May 2020 (UTC)

Applicable jurisdiction

Some keys apply only in a single country or other jurisdiction. Can we add a parameter for this? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:12, 9 April 2020 (UTC)

Do you have some examples? --Jeisenbe (talk) 12:32, 9 April 2020 (UTC)
Key:ref:NPLG:UPRN:1 Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:23, 9 April 2020 (UTC)
I would suggest to use the techniques explained at Data_items#Storing_Geographical_Differences to store the information in Data items first and append the template to display this information on the wiki page in a second step. The advantage is that you avoid a multi-value parameter and keep the translations in sync via data items but the disadvantage is that the information is not available on the wiki page itself. I do not know if this approach is feasible though. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 08:34, 10 April 2020 (UTC)