Template talk:KeyDescription/Archive 1

From OpenStreetMap Wiki
Jump to navigation Jump to 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 :
     |groups={{GroupList|en|first|second|e.t.c.}} 
    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:


   [[Category:en:Keys]]

—Preceding unsigned comment added by Gubaer (talkcontribs) 19:40, 21 December 2008

probably [[Category:EN:Keys]] --dr&mx 20:07, 28 February 2012 (UTC)

Transition

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)

Implemented "requires" section

Example 1:

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

Example 2:

{{KeyDescription
|key=grassland
|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


Resolved: Mateusz Konieczny (talk) 08:42, 21 June 2020 (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)


Resolved: Mateusz Konieczny (talk) 08:42, 21 June 2020 (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
Resolved
as it is offtopic on discussion page of this specific template Mateusz Konieczny (talk) 18:44, 21 May 2020 (UTC)