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)

Resolved: Mateusz Konieczny (talk) 21:43, 9 January 2021 (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)

Resolved: closing as outdated and replaced by other parameters present nowadays Mateusz Konieczny (talk) 21:44, 9 January 2021 (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)

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)

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


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)
@Mateusz Konieczny: It does not work for property.
Example P1937 in ref:LOCODE=*. Link to https://www.wikidata.org/wiki/P1937 but must be https://www.wikidata.org/wiki/Property:P1937
--Pyrog (talk) 12:26, 4 August 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)
@Valor Naram: Can you give some examples where such field would be useful? Mateusz Konieczny (talk) 08:49, 29 October 2020 (UTC)
@Mateusz Konieczny: For example: You shouldn't tag Tag:diaper=no and Tag:changing_table=yes together and generally absent from using Key:changing_table and Key:diaper together. But also combining Key:playground: and Key:playground (note the : char missing there) is toxic for data users and customers. Although they are similiar, they do not mean the same. --Valor Naram (talk) 17:55, 31 October 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)
Resolved: seems to not be a problem anymore Mateusz Konieczny (talk) 08:49, 29 October 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)

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)

Standard practice on English-language pages is to specify infobox template on Wiki Page rather than to load content from data items.

Is there a standard practice? As far as I can see, there are some pages that use information from wiki pages and others relying on data items. I can not see any consensus. I am also strongly against changing pages not to use data items. I know that there was no consensus to introduce them, but changing anything back now is no better IMHO. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:56, 21 June 2020 (UTC)
There was no decision to add information to the pages. What happens is that someone edits the data item, and then suddenly the information on the page changes. It's quite possible that the editor of the data item does not even realize that the infobox has changed.
It's also a problem that people like Mateusz Konieczny, who try to maintaine the Tag: and Key: wiki pages as the standard documentation, are unaware that the infobox is suddenly showing new information. No watchlist is going to show these changes, unless you watchlist all the relevant data items. --Jeisenbe (talk) 20:08, 22 June 2020 (UTC)
There was never consensus, agreement or clear support to replace any part of OSM Wiki pages by data items. There was support for enabling data items, but it was never clarified how it would be used. Also, note that I am not proposing to stop using data items - I am proposing to only allow monitoring when it happens. Mateusz Konieczny (talk) 21:04, 22 June 2020 (UTC)
Translating wiki content, I constantly have the problem of diverging translations. For me, it is a great help, that there is only one place where you can change the information. I can accept that some users prefer to watchlist wiki pages over data items, so I think we agreed on leaving everything as it is and append the existing information with data items originating partially from the import process. replace any part of OSM Wiki pages by data items @Mateusz Konieczny: Please explain what was replaced? As far as I can see, all current input is taken into account by the template. Only data missing in some translations is taken from the data item. There is a general agreement not to remove the input parameters. I am proposing to only allow monitoring when it happens I understand, but I think your suggestion will not make the situation better for the reasons mentioned at the beginning of this comment. Please also consider tags with no English description. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 22:05, 23 June 2020 (UTC)
@Tigerfell:"Please explain what was replaced?" - Infoboxes display if no parameter is specified - what is quite confusing where someone removes incorrect parameter and it is not disappearing as now incorrect part of data item is displayed. Mateusz Konieczny (talk) 16:43, 18 August 2020 (UTC)
Okay, but that is an invitation to update the data items, too. That helps maintaining some consistancy IMHO. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:16, 18 September 2020 (UTC)
Only if you know why it happened this way. What worse, removing wrong data from data item has no immediate effect. I suspect that number of people who understand what happens is quite low. And the worst part is that someone may add gibberish by editing data item and you get not warning... Mateusz Konieczny (talk) 07:40, 19 September 2020 (UTC)
@Tigerfell: "That helps maintaining some consistancy" note that you need to manually spot such leaks of an incorrect data. Automatic listing where data items are silently copied into infoboxes would allow to verify all of them rather than spot them months or years later Mateusz Konieczny (talk) 08:04, 22 October 2020 (UTC)
I agree with @Mateusz Konieczny:, this is a serious problem. There are a small number of active wiki users who make sure that the pages for common tags and keys are not vandalised or accidentally changed to redefine the meaning of important features in OpenStreetMap, and many of us rely on the watchlist items to notice when an article has changed. It's not practical to watch all the data items, because these change 10 to 20 times more frequently, when every anyone adds a new translation or makes an edit in another language, and because each small change is listed separately. But now that the infobox pulls in data from the items, the "authoritative" text of a page can suddenly change without warning.
The best solution would be to no longer pull in information directly from the data items onto the English language pages. --Jeisenbe (talk) 04:01, 30 October 2020 (UTC)
Your suggestion does not solve the problem with vandalising users, it just keeps it out of English language pages. We have some additional 100 languages in this wiki and iD pulls its data from data items, not from the pages. I do not see how your approach addresses this. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:10, 29 December 2020 (UTC)
ad nonEnglish: I am anyway utterly unable to recognize vandalism/damage in non-English edits, except the most blatant one. But if I am forced to look at all edits at once then I will become unable to monitor also English ones. Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
ad data items and iD - if noone is capable of watchlisting data items (I am not going to do this), and it is causing issues then iD should not use data items. Exporting data from infobox parameters is not so hard Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
And yes, I have position "I am not interested in watchlisting, monitoring or using data items - and I do not want to be forced to do this" Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
BTW, I ended writing script that compares data items and infobox parameters, so I sort of monitor data items right now Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)

Examples of silent damage caused by nonsense in data items

https://wiki.openstreetmap.org/wiki/Key:addr:place was listing "Requires: addr:city=* addr:street=*" in infobox what is complete nonsense. addr:place=* is used for example whee no street names are assigned! It was silently added from data item Mateusz Konieczny (talk) 08:00, 22 October 2020 (UTC)

This specific damage was temporarily fixed in https://wiki.openstreetmap.org/w/index.php?title=Item%3AQ44&type=revision&diff=2052462&oldid=2004659 Mateusz Konieczny (talk) 08:01, 22 October 2020 (UTC)
Completely nonsense "implies", added by bot, supposedly based on a Wiki page (it was not based on a wiki page): https://wiki.openstreetmap.org/w/index.php?title=User_talk:Yurik&diff=prev&oldid=2078828 Mateusz Konieczny (talk) 18:19, 29 December 2020 (UTC)
tourism=information had confusing and pointless "requires tourism=information" shown until https://wiki.openstreetmap.org/w/index.php?title=Item:Q4804&diff=prev&oldid=2087824 Mateusz Konieczny (talk) 22:01, 9 January 2021 (UTC)

What should be done with pages describing prefixes?

Maybe a new template would be a good idea? Or a way to hide/reformat statistics? For example taginfo summary for Key:disused: is confusing and misleading, links to tools are also probably broken Mateusz Konieczny (talk) 08:48, 29 October 2020 (UTC)

Taginfo should show 0 uses for such prefixes. And I think we should move Key:addr to Key:addr: or don't name such pages with "Key". I think addr is not a key, but for example addr:city. maro21 00:20, 30 October 2020 (UTC)
You are correct, addr: is not a complete key, in the database it is going to be something specific like addr:housenumber. Usually we link to the page Address instead. A key is simply a string of any characters, and there is nothing special about a colon (":") by nature. Although many application developers are familiar with this being used for "namespacing" in other contexts (including this wiki), all database users have to custom-design code to handle this, if desired. So it would be best to address actual, complete keys in the pages like Key:addr:city, or redirect those to a general article which is not prefixed with Key:. --Jeisenbe (talk) 03:55, 30 October 2020 (UTC)