Talk:Data items

From OpenStreetMap Wiki
Jump to: navigation, search
Available languages — Wiki
Afrikaans Alemannisch aragonés asturianu azərbaycanca Bahasa Indonesia Bahasa Melayu Bân-lâm-gú Basa Jawa Baso Minangkabau bosanski brezhoneg català čeština dansk Deutsch eesti English español Esperanto estremeñu euskara français Frysk Gaeilge Gàidhlig galego Hausa hrvatski Igbo interlingua Interlingue isiXhosa isiZulu íslenska italiano Kiswahili Kreyòl ayisyen kréyòl gwadloupéyen kurdî latviešu Lëtzebuergesch lietuvių magyar Malagasy Malti Nederlands Nedersaksies norsk norsk nynorsk occitan Oromoo oʻzbekcha/ўзбекча Plattdüütsch polski português română shqip slovenčina slovenščina Soomaaliga suomi svenska Tiếng Việt Türkçe Vahcuengh vèneto Wolof Yorùbá Zazaki српски / srpski беларуская български қазақша македонски монгол русский тоҷикӣ українська Ελληνικά Հայերեն ქართული नेपाली मराठी हिन्दी অসমীয়া বাংলা ਪੰਜਾਬੀ ગુજરાતી ଓଡ଼ିଆ தமிழ் తెలుగు ಕನ್ನಡ മലയാളം සිංහල ไทย မြန်မာဘာသာ ລາວ ភាសាខ្មែរ ⵜⴰⵎⴰⵣⵉⵖⵜ አማርኛ 한국어 日本語 中文(简体)‎ 吴语 粵語 中文(繁體)‎ ייִדיש עברית اردو العربية پښتو سنڌي فارسی ދިވެހިބަސް
This is the talk page for discussing improvements to the Data items article and its related topics.

Contents

Item Creation process

"Ideally, an automated tool should create all tag keys when they are detected in the OSM database."

I recommend not doing that: there are a lot of strange tags out there based on typing errors or whatever (example: way 50694394). Following a suggestion from Zverik in a different context, I would limit the automatic creation to the keys with the following syntax (az09)(az09)*(:_.-(az09)(az09)*)*(az09)* where az09 meanst one small Latin character xor a numeric such as 0,1,2,3,4,....

That would effectively exclude

  • keys starting with _ or :.
  • keys including white spaces, tabs, etc.
  • empty keys.
  • capitalization problems (duplication due to different capitalizations).
  • empty namespaces like abc::def.

I would also recommend limiting the values following some of the maintenance work Xybot did (like removing white spaces and escaped characters at the beginning and the end). I also suggest ignoring tags with empty values.

I know that this seems nasty and restricting, but otherwise the database gets flooded with trash-like items that need no documentation and unnecessary human effort is wasted to clean this.

U30303020 (talk) 20:59, 20 August 2018 (UTC)

U30303020 thx, makes sense. I think the bot would simply download list of keys from taginfo, and create all the ones that have 10+ entries, and fit the above regex (unless there is a 1000+ entries, in which case regex will be ignored). Also, I think the bot should try to extract some common data from the wiki pages, and pre-populate those items (e.g. description from multiple languages, recommended tags, used on, etc). It should not change wikidata entries that have those things already set. Also, eventually the wiki pages (info cards) should use that text directly from wikibase. --Yurik (talk) 21:47, 20 August 2018 (UTC)

Great, thank you for incorporating this. The "overriding" is a good idea as there are (few) tags like USGS-LULC:CLASS=* which do not follow the naming conventions, but they are still valid. U30303020 (talk) 17:45, 22 August 2018 (UTC)

CCing @Zverik just in case he has some ideas. --Yurik (talk) 23:03, 22 August 2018 (UTC)

Descriptions from map features

Map features templates have more descriptions in languages where there is no wiki page for the referenced tag. --Andrew (talk) 20:11, 22 August 2018 (UTC)

Andrew, not sure what you mean, could you link to examples? Also, if this is a separate topic from the item creation discussion above, please add a header above your comment to help with conversation management. Thanks! --Yurik (talk) 21:00, 22 August 2018 (UTC)
For instance, Template:Ca:Map Features:landuse has the Catalan description “Zona en construcció. Espai en obres” for landuse=construction. There is no page Ca:Tag:landuse=construction that the description can be taken from.--Andrew (talk) 21:19, 22 August 2018 (UTC)
Andrew, thanks, makes sense. Unfortunately I am not exactly sure how to pick these up automatically - for example, on that same page landuse=comercial is in English, so it shouldn't be copied. Plus Wikibase has a 250 char description limit (I will see if I can raise that). Lastly, you cannot have rich text with links in the Wikibase description - only raw text. I think eventually we should have each of these tables and infocards get the description from Wikibase, with a small edit button linking to Wikibase, plus add any extra wiki text afterwards (we can do it with a Lua code). --Yurik (talk) 22:38, 22 August 2018 (UTC)
So we should be clearing up the report at Taginfo/Parsing the Wiki#description_parameter_should_only_contain_plain_text? --Andrew (talk) 08:07, 18 September 2018 (UTC)
Andrew, hopefully we will be able to migrate to the auto-generated info cards, where the description (as well as everything else) comes directly from Wikibase. And in the process of doing that, we would have to clean up the descriptions to be simple 250max no link text. --Yurik (talk) 08:19, 18 September 2018 (UTC)

Types of keys

There are several basic types of keys, e.g. "free-style" and "enum-style". Free style keys allow any user input, e.g. street name or the hours of operation. The "enum-style" keys tend to have well known tags, e.g. highway=motorway. We can store this data using "instance-of" - e.g. in addition to generic instance-of = key, we also have a instance-of = enumkey, where enumkey is a subclass of key. What other types of keys would we need to make this system useful? Some ideas:

  • instanceof=key - main type, at some point we could even require everything to have more specific keys
  • enum-key - well known values, expects all such values to also be stored in the wikibase
  • boolean keys (subclass of enum-key, e.g. only allow key=yes)
  • external ID key - a free-form reference into an external system, e.g. Wikidata or a Government database

One downside of this approach is the inability to quickly determine the type of the item, without also querying the class parent of the type. E.g. given a key with "instanceof=enum-key", one would have to also examine the subclass-of for the enum-key, and possibly do it until it gets to the root element.

Alternative is to have an additional "key type" property, a required property for all "instance-of=key". Thoughts? --Yurik (talk) 01:47, 18 September 2018 (UTC)

I'm not sure if "key type" is the best name for this – isn't it rather the type of the key's values? (Or to put it differently, the set of possible values?)
But naming aside, this kind of property makes a lot of sense. I believe the following are also typical types of values:
  • Integer (e.g. layer, building:levels, step_count, ...)
  • Length (e.g. height, width, length, maxheight, ...)
  • Weight (e.g. maxweight, maxaxleload, ...)
  • Speed (e.g. maxspeed, minspeed, ...)
  • Time interval(s) (e.g. opening_hours, happy_hours, lit, ...)
  • Time instant(s) (e.g. collection_times, service_times, ...)
(This list is partly inspired by the "Values" column of Template:Map_Features:restrictions.)
It might also make sense to allow using the property more than once, because some keys use a combination of these. For example, Key:lit can either use a value from a list of well known values or a time interval. --Tordanik 19:51, 18 September 2018 (UTC)
@Tordanik true, naming is hard :). We could make it longer, or use the word "tag" or "class", or anything else. Renaming it is easy - the property will stay the same. I wouldn't want to mix value type with value semantics, e.g. "integer" and "weight" in the same property, especially since everything is a string. Also, type validation should probably be per-key, not per key class. We already have a regex property for validation, see Item:Q574 (population - integer). We have to be very clear of how key type will be used. For example, iD could see "enum" and show all tags that reference this key. Or if it sees "external ID", it can use some format URL property to show that id as a link. I guess time or time-range could also be useful - to show some sort of a customized time entry dialog. Agree about multiuse. --Yurik (talk) 20:37, 18 September 2018 (UTC)
The distinction between "integer" and "weight" is not just semantics, but directly affects the acceptable values. "5 t" is a valid value for a weight, but not for an integer. This has immediate practical uses: The iD editor, for example, already offers unit dropdown menus where users can select "mph" or "km/h" for maxspeed. Also, this will allow for better error messages in validators than a regex would: "Periods should not be used in integer values" is more user-friendly than "Value does not match regular expression '[0-9]+'". --Tordanik 19:06, 20 September 2018 (UTC)
I would suggest some sort of multi-value like in traffic_sign=*. If people add the national number of a sign it would look like traffic_sign=country_code:code_A[some_value];code_B[some_value_2] with some_value being optional or depending on the code. It might be useful to have an enum for the country codes and maybe even the sign codes (not really sure about that). Unfortunately, there seems to be traffic_sign=stop and other text values as well.
As far as I know, this "data structure" is also used in railway mapping. Maybe, the "value validation regex" is a better place for that?
There are also some default values for speed limits. I have no idea how to add them or if this really relates to data types or classes. It would be useful to infer values that are not given (like an editor telling the editor that highway=trunk and no maxspeed tag imply maxspeed=100 in this country).
If there were some sort of integer (sub)type, one could also store the default unit (or even the default value) of a certain tag.
Enum, boolean, and external ID seem reasonable to me. Enum should have some facility to add values later on if they emerge. Boolean should take into consideration that sometimes numerals were used instead of "yes" and "no". External id could be used for Wikimedia Commons file links (sorry, I do not remember the appropriate key-name) and links to Wikipedia. There is also source_abc:id=* (looking at taginfo).
Additionally, I would suggest Conditional restrictions as a data type. Kind regards --Tigerfell This user is member of the wiki team of OSM (Let's talk) 16:27, 19 September 2018 (UTC)
Thanks @Tigerfell. traffic_sign seems like a good one (but complex) to tackle. Enum values are very easy to add - we simply add a new item of type "tag". The only difficulty is "forward vs reverse linking" dilemma:
  • in reverse linking, all tag items simply set their "tag key" property to point to the right key page (see Item:Q888's tag key). This makes it easier to add (each item is independent), and we can have any number of such tags, but it makes it more difficult to find all available ones - we have to query "show all items with tag key = mykey" (note that query service is not done just yet - see Wikidata QS).
  • in forward linking, in addition to the above, the key entity also lists all possible values on the same item page. Think of it as a table of values on the traffic_sign page. This requires someone to manage that list, and add new items as they get created. The list could get very large. This approach is much easier for automatic table creation on the key wiki pages (e.g. list of religion denominations).
I now think it is a bad idea to create a "boolean" type -- it's the same as enum, and there could be additional details for each value, plus it could grow. Also, I think there should be a "multivalue" type. It will be added as an additional property, e.g. "valuetype: enum, multivalue", and it will indicate that more than one value is possible on this key. --Yurik (talk) 17:04, 19 September 2018 (UTC)
I just found Machine-readable_Map_Feature_list#Using_Semantic_MediaWiki_in_the_future. It also mentions data types as far as I understand. Btw {{ping}} does not issue a notification for me, so maybe it is broken, just that you know. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 12:15, 20 September 2018 (UTC)
@Tigerfell might be incorrect notification settings in your acc? Then again, I simply monitor the pages and it emails me when they change. Thanks for a great find! We should definitly use it for some ideas. @Janko might also be interested in it. Please let me know if there are any specific properties you think are missing at the moment. --Yurik (talk) 18:01, 23 September 2018 (UTC)

English label?

What do the words “English label” in set English label to be the same as the key but without the "Key:" or "Tag:" prefixes mean? --Andrew (talk) 08:12, 18 September 2018 (UTC)

Andrew, for each item, wikibase has a label and a description for each language. For a key like highway, we have a wiki page Key:highway, so the sitelink (link in the upper right corner) will point to that. The label field will be the same but without the "Key:" -- so it will be set to "highway". Other languages should not be set at all. Maybe we should even hide the label field from the interface. --Yurik (talk) 08:24, 18 September 2018 (UTC)
Andrew, after thinking some more, the labeling restriction seems to be too silly and error prone. Feel free to change the labels in an internationally useful way, e.g. name:en -> English name. --Yurik (talk) 02:35, 20 September 2018 (UTC)

different prefix - Q complexity

> Key:bridge:movable: https://wiki.openstreetmap.org/wiki/Item:Q104

As I understand most of the osm keys/tags will be 2 Q prefixed ids. ( one for the wikidata and the other is for the osm wikibase )

example:

amenity=

aeroway=

Is it possible to change the prefix? ( now "Q"/"P" - for me better "M" or any other letter)

for me (as a human) it is very hard to work with similar id-s ( hard to debug, hard to understand, and a lot of confusion) ( my nightmare: debugging complex JSON file: inside a wikidata and an OSM wikibase id, and checking the Q and the P values )

--ImreSamu (talk) 11:36, 18 September 2018 (UTC)

ImreSamu, agree, I wrote the code, but Wikbase devs don't like it without offering any alternatives. See comments. If you can convince them, and raley support, it would be great. [1] --Yurik (talk) 13:00, 18 September 2018 (UTC)

Yurik, thanks - I see: https://phabricator.wikimedia.org/T202676 , I am not happy .. --ImreSamu (talk) 14:04, 18 September 2018 (UTC)

ImreSamu being unhappy doesn't change anything. Write to the devs, explain our position, get other people to do the same. --Yurik (talk) 18:19, 18 September 2018 (UTC)
One way to make this a non-issue would be to remove the Wikidata property from the database. Would the WMF developers really prefer us to do that?--Andrew (talk) 18:37, 18 September 2018 (UTC)

what is "primary tag storage for the OSM database"?

"This project's goal is NOT to replace the primary tag storage for the OSM database" - can someone tell me what is currently this primary tag storage? Is it about wiki containing tag description? Or something else Mateusz Konieczny (talk) 16:02, 18 September 2018 (UTC)

Currently tag metadata is stored in this wiki as a free text, and cannot be easily used by other tools like taginfo or iD editor. With this approach, we can store data in a structured way, usable to other tools. --Yurik (talk) 17:50, 18 September 2018 (UTC)

"that it is disallowed"

I am not sure is it intentional, but it read like attempt to be an attempt to forcefully deprecate at least some keys. AFAIK there is no consensus to do that Mateusz Konieczny (talk) 16:04, 18 September 2018 (UTC)

It may be a good idea to mention that nobody is forced or obligated to follow suggestions included in this database Mateusz Konieczny (talk) 16:06, 18 September 2018 (UTC)
it's a bit hard to forcefully deprecate anything in OSM :) This is an attempt to make sense of the data. If the data doesn't make sense to anyone, that data can be deleted as it is just noise that gets in a way. But this is not the primary focus ;) --Yurik (talk) 17:46, 18 September 2018 (UTC)
There are already deprecated tag wiki pages such as highway=incline.--Andrew (talk) 20:23, 18 September 2018 (UTC)

MW API

"use MW API to create new items" - can someone link this tool? I am unsure what is this (maybe MediaWiki API?) Mateusz Konieczny (talk) 16:05, 18 September 2018 (UTC)

Correct, MediaWiki API. The easiest is to use pywikibot. --Yurik (talk) 17:56, 18 September 2018 (UTC)

Link to create new item

Is there any easily accessible link for creating a new item? While it's possible to manually navigate to Special:NewItem, this will likely not be easy to discover for most wiki editors. Wikidata has a "Create new item" sidebar link for that purpose. --Tordanik 19:19, 18 September 2018 (UTC)

Tordanik, I don't think we should expose it the way Wikidata does. Most new items are created by a bot from TagInfo data, plus at some point I hope other tools like iD editor will create them when user enters a new key. Casual users should not be creating them. Once the project stabilizes, we should have documentation describing when how to create new items and what properties they should have. --Yurik (talk) 19:29, 18 September 2018 (UTC)
Importing data from Taginfo works for tagging-related items. But as I previously said on the forum, I feel the community should be able to use the Wikibase instance for purposes besides tagging documentation. --Tordanik 18:50, 20 September 2018 (UTC)
@Tordanik the data is not being imported just from taginfo. Taginfo tells me how common is the key, and then i parse the KeyDescription template to extract image, description, used-on, and status (with the reference). I hope we will parse and add other things, e.g. the group and the used-with type of info. --Yurik (talk) 00:16, 21 September 2018 (UTC)

Property "Same as"

I propose this property because some tags are considered the same, and this would help with finding data. For example, if you want to find all phone numbers of an area, you will have to search for all phone=* as well as contact:phone=*. Also, artist=* and artist_name=* are the same tag. This database is perfect for finding duplicate tags like this. Janko (talk) 22:00, 19 September 2018 (UTC)

@Janko agree in principle, but we would need a different name, because "same as" implies equality, whereas what you really want is "don't use this, use that instead". The "same-as" property could be set on both "phone=*" and "contact:phone=*", which is not what I assume you want. I created Property:P17 - "redirect-to" property. Any better name?
On top of it, we would need "different from" - copied it from wikidata -- Property:P18. --Yurik (talk) 22:55, 19 September 2018 (UTC)
@Yurik I don't think we should use wikibase to make people tag a certain way. Wikibase should be as objective as possible. I don't know which is more right, contact:phone=* or phone=*. First one is better structured, second is easier to write. I just know they are two tags that give us the same information. Janko (talk) 00:14, 20 September 2018 (UTC)
Wikidata has a similar property, P460[2]. Janko (talk) 00:24, 20 September 2018 (UTC)
@Janko, you are right, we shouldn't use Wikibase to tell people what to do - that would be wrong. Instead, we as a community should establish the ways certain things should be mapped. That's the reason we have a tagging mailing list, that's why we discuss things, that's why we document things on this wiki. Without it, each user could potentially come up with their own way of mapping, their own keys, thus reducing the value of OSM to near-zero. Any casual user seeing phone=* and contact:phone=* would assume these things are different in some way, causing additional mental strain. Even a simple example where local communities would start using translated keys -- while more readable for that community, the value of that data would be very low. That said, I agree that for some identical concepts we have historically ended up with multiple ways of tagging them. It would be great to document such cases, and indicate the "primary method" vs "alias-of". iD editor could use that to determine the best tag to use when a user is creating something, and we could decide some day to converge on those. At the end of the day, keys is an "internal implementation detail". New users don't care about keys, they want to draw "a house" or create "a science museum", and tools should help them by filling out all the needed keys. The "redirect-to" on the other hand could be used for when something is a no-brainer - e.g. description:DE (39) → description:de (16000). What do you think? --Yurik (talk) 01:24, 20 September 2018 (UTC)
P.S. Look at the description of Wikidata P460 -- this item is said to be the same as that item, but the statement is disputed. We might at some point need something like that, but i hope its not soon :) --Yurik (talk) 01:55, 20 September 2018 (UTC)
@Yurik OK, there is value to having the principal tag that is encouraged, but then there should be strict rules how that is decided. For example, as you said, number of uses. And if the community decides that a tag should be overthrown in favor of a less used one, then there should be some wiki page with a vote that shows how the community decided.
Anyway, I'd like to propose a different name like "More accepted key" or "Better established key". I think when you use words like "wrong and right", edit wars will happen :)
And a new question, does it have to be "key"? What about tags? For example landuse=cemetery and amenity=grave_yard (The wiki says that amenity=grave_yard is a cemetery that is close to a church, but you get what I mean). Do we use the same Property:P17? I see no problem in using the same property, as long as a key connects with a key, and a tag connects with a tag. -- Janko (talk) 09:10, 20 September 2018 (UTC)

I think there should be both: "Equivalent key/tag" (when both tags are in use, but neither one has status (P6)=deprecated (Q5061)) and "replaced by key/tag" (for keys/tags that also have status (P6)=deprecated (Q5061), to point to the currently accepted method of tagging this). --Floscher (talk) 09:05, 26 September 2018 (UTC)

@Floscher, Ok, so basically "has identical meaning to X", with the description explaining that community has not decided on which one to standardize on, but there is absolutely no difference between the two, and both should NOT be used at the same time? Meh, but ok.
For the "replaced by" - very often it is not "X is replaced by Y", it is "X is replaced by two items - Y & Z". Should we assume that if this property contains more than one value, they are ALL required at the same time? And in case something is too ambiguous, and the community decided to replace it with something more specific, we can have a property "X is too unspecific, and should be replaced by either one of these: Y or Z". In which case we now still face the same problem - being able to disambiguate something by multiple tags: "X should be replaced by either (Y+Z) or W". Should we start thinking about tag combinations? --Yurik (talk) 19:55, 26 September 2018 (UTC)
I found identical tags that don't have the "better" one. maxspeed=* and maxspeed:conditional=*. They tell you the same exact thing, what's the maxspeed of this road, but in different ways. Janko (talk) 13:50, 2 October 2018 (UTC)
@Janko these are not the same tags, per description: Key:maxspeed#Time_or_other_conditions. One is unconditional speed, the other one is conditional. Different use case. --Yurik (talk) 04:42, 3 October 2018 (UTC)

Labels and IDs

A key like alt_name=* has an item Item:Q1079. That item has a sitelink (upper right corner link) to Key:alt name, plus a label alt_name. Due to MediaWiki limitations, the sitelink to Key:alt_name is the same as Key:alt name, so it is not possible to have both. Moreover, sitelink has to be using spaces instead of underscores, or else it will not be possible to link from the Key:* pages back to Wikibase items - making it very hard to find them (also affects the API). To keep the proper value, we also store the key alt_name in an ID property (P16). For now, these IDs are created only for the keys with spaces and underscores, but maybe we should add them to all items.

The label field is multilingual by design, so I think it makes sense to start using it as a short key description? E.g. "English name" or "Name in English" instead of "name:en". --Yurik (talk) 06:15, 20 September 2018 (UTC)

ID seems like a good solution to this problem, and adding it to all keys will make it easier for machine reading. Using labels as short descriptions that iD and other editors can pull also seems like the logical solution. Janko (talk) 09:30, 20 September 2018 (UTC)

Using Property:P3(Subclass) on OSM tags and keys

I see this property wasn't discussed in terms of using it on OSM tags, but I would like to use it like that. For example, amenity=grave_yard is a subclass of landuse=cemetery because (as the wiki says) grave_yards are cemeteries that are close to a church. Or, amenity=concert_hall is a subclass of amenity=music_venue. Do we use this property for this or do we invent a new one? Janko (talk) 09:53, 20 September 2018 (UTC)

@Janko sure, but maybe we should have a different property for that? E.g. instance-of and subclass-of are for structuring meta-meta-data, e.g. this is a status, which is a subclass of osm concept, vs this key narrows down the concept of another key? Looking for a good name... :) --Yurik (talk) 23:31, 20 September 2018 (UTC)

Wikibase helper templates

I've created {{Label}}, {{OP}}, {{OQ}} templates for use with WikiBase items. They will show permanent key ID (P16) values if they exist, otherwise, they will show the 'en' label. Suggestions welcome. Teester (talk) 17:01, 20 September 2018 (UTC)

@Teester that's awesome!!!! Thank you!!!!!! Some ideas: for {{OQ}}, I think we should show the label in the current user's language, with english fallback. Also, maybe we should show both if they are different by default? E.g. Name in English (Q1542 name:en) or name:en (Q1542)? Once again, thanks! --Yurik (talk) 23:26, 20 September 2018 (UTC) (P.S. I fixed your links above)
@Teester do we need description as well? Or pehaps a label + description + Qid ? --Yurik (talk) 00:21, 21 September 2018 (UTC)
  • I've added a {{Desc}} template which gets the entity description. There's an optional language parameter. If it is left out, the template determines the language to use from the page name - e.g. {{desc|Q4}} will produce Un chemin est une liste ordonnée de nœuds, qui dispose normalement à minima d'un attribut ou qui est inclus dans une relation. on FR:WikiProject France and A way is an ordered list of nodes which normally also has at least one tag or is included within a Relation. on WikiProject France. You can also use {{desc|Q4|fr}} to get the french description no matter what. If there is no description for the specified language, the template falls back to English
  • Regarding {{OP}} and {{OQ}}, I suspect as the data evolves, it will become clearer how these should work. I think that any key with permanent key ID (P16) and tag with permanent tag ID (P19) should show permanent key ID (P16) and permanent tag ID (P19) (since that's the key or tag which should be used on OSM) and other entities should use localised translations e.g. way (Q4) as Chemin (Q4) on French pages
  • One interesting option is to use something like Template:Hover_title (en wikipedia) to show localised descriptions on hover for tags and keys if it is supported by this wiki
Teester (talk) 12:13, 21 September 2018 (UTC)
@Teester looks great, thank you! Agree with the above. I will cross it out in the TODO section. Would you like to tackle the {{KeyDescription}}? Seems you have more than enough expertise to solve it :) I think it should automatically show data from wikidata with the direct link to help editing (you can add #P123 anchors to the links to jump to the right place). If the template parameter still has description, than it should override what's given in the wikidata (for now), but there should be a red/green dot indicator to show if it is the same as in wikidata or not. What do you think? Thanks! --Yurik (talk) 15:52, 21 September 2018 (UTC)
@Teester I just spoke with @Joto about TagInfo -- turns out they are actually parsing wiki markup (ouch!) to extract KeyDescription values out. Hopefully we can all work together on migrating it to the new system. But in the mean time, we need to figure out a way to keep TagInfo running. My idea: create a new template {{KeyInfo}} that looks similar to {{KeyDescription}}, but make it work only from Wikidata. Then, once it shows everything needed, add it to the page, and also add a new "hide" parameter to the {{KeyDescription}}. This way KeyDescription will stay on the page with all of the original params, but it will not show up. Once taginfo is migrated, we will simply delete keydescription from those pages. What do you think? BTW, this also means that TagInfo may need to support some of the same parameters that are not in Wikibase yet... --Yurik (talk) 19:54, 21 September 2018 (UTC)
I've had a brief look at {{KeyDescription}}. It looks like it's a wrapper for {{Description}}, so we should be able to develop an OSMWikiBase version of {{Description}} and transclude it into {{KeyDescription}}, while hiding the {{Description}} template at the same time. This will save us from having to change each key's page individually.
Looking at the information displayed, one thing I see is that {{KeyDescription}} shows whether or not a key can be used on each element (node (Q3), way (Q4), area (Q5), relation type (Q6)). There's also an unknown option (shown by a greyed out icon). Currently, OSMWikiBase has ERROR: Invalid ID to show that a key can be used on elements. However, we may also need a property to show that a key should not be used on elements in order to be able to show all this information. I'm not sure that there's any properties yet to cover the group, implied, see also and useful combinations sections of the template yet, either. Teester (talk) 10:12, 22 September 2018 (UTC)
On second thoughts, creating a new version of {{KeyDescription}} and transcluding the new template into {{KeyDescription}} looks a little easier! Teester (talk) 11:03, 22 September 2018 (UTC)
@teester I can create a don't use on property, but it seems kinda silly to have a 3 state for this. Adding status is easy - just create a new item, and set instanceof to status. Use special page. BTW, I just realized that we should have an {{O}} template that will understand both P and Q. Less confusion. Thanks!! --Yurik (talk) 21:05, 22 September 2018 (UTC)
@teester the more I use it, the more I think we need just one template for both, to remove any chance of mistakes. Users shouldn't use raw number, they should copy/paste the value as shown in wikibase UI. So {{O|Q2}} seems like the best choice, and we should remove the OQ and OP before they are used in many places. I have also been thinking about the migration. Some cases will not be simple to switch over to, e.g. Key:service has a field requires, which contains words or - will be hard to represent that in structured way just yet. See comment below. So I think we really ought to adjust existing template to slowly remove parameters with. And It should always highlight if the value matched WB or not. Thanks for helping with this!!! --Yurik (talk) 08:13, 23 September 2018 (UTC)
I've created {{O}} and changed {{OP}} and {{OQ}} to use it, so now, using {{O|P2}}, {{O|P2}} or {{O|P2}} should give the same result. Feel free to delete them if you wish, though. Teester (talk) 23:20, 23 September 2018 (UTC)
I've a preliminary version of an OSMWikiBase {{KeyDescription}} at User:Teester/sandbox. Issues so far:
  • No images from OSMWikiBase - since image (DEPRECATED) (P4) have to be commons files. We may have to just use the template values for now.
  • Nothing for Group, Implies, See Also or Useful Combinations since the info isn't in OSMWikiBase
  • Differences in data in the infoboxes and on OSMWikiBAse - e.g. highway (Q335) has de facto as the status in the template and approved in OSMWikiBase. The same entity also says not on relations in the template, but allowed on relations in OSMWikiBase
You can test it out by going to a page and replacing {{KeyDescription}} with User:Teester/sandbox and leaving all the variables the same and previewing the page. There's still a few bugs in the template and I haven't gone near comparing template and OSMWikiBase values yet, so please bear that in mind. Teester (talk) 00:00, 24 September 2018 (UTC)
@teester thanks, i deleted OP and OQ, and fixed all the usages. Also, I modified your module a bit to also handle a few other ID props. WRT images: lets also use the fallback model - if the image is specified, use it, otherwise use the property (it is set on many pros, e.g. bridge:movable (Q104). WRT groups: feel free to modify bridge:movable (Q104) to make it a perfect example of the new system. There is already group (Q12) that we can use as an instance of (P2), so just create the group(s) you need using special page. Same for implies, see also, and useful combinations (although the last one might be tricker, together with requires - it could be a simple list OR-style, or it could be in theory "X OR (Y AND Z)", which would be more difficult to represent (see discussion below). WRT data difference -- I was merging templates from all languages of the given key - that's why it might mismatch. I will review it and might reset it back to EN only for everything except descriptions. Thanks for all the hard work! --Yurik (talk) 00:27, 24 September 2018 (UTC)
P.S. Lets skin this cat one part at a time - while we can already try to show the "perfect" card, we should try to migrate existing usage at least for the few of properties initially. --Yurik (talk) 00:29, 24 September 2018 (UTC)
@teester, I have added a ERROR: Invalid ID, populated it with data for all of the keys we have, and also fixed the values for ERROR: Invalid ID to match English wiki. I will post the difference in languages in a separate post (i have an easy way to generate that difference now). --Yurik (talk) 01:33, 25 September 2018 (UTC)
@teester, I have taken a stab at implementing it using a Lua-only approach. Seems to be working, and already supports images, groups, status, and description. Please take a look, maybe you have some suggestions. {{Template:KeyDescription/Sandbox}} --Yurik (talk) 06:03, 28 September 2018 (UTC)
Unfortunately, I haven't had time to make any more progress in the past week, but your {{KeyDescription/Sandbox}} looks excellent. A couple of things I've noticed:
  • One thing it's not doing at the moment is passing a key= value into the {{Description}} template if it's not provided in {{KeyDescription/Sandbox}}, which makes it look a little odd when transcluded. It should pass permanent key ID (P16) or the en label if there's no value provided.
  • There are a couple of missing sections - perhaps fall back to provided parameters until there is a data model for them
  • I'm not sure how clear it is what the user is supposed to do when they click the various edit buttons on description section the template. Perhaps an explanatory <title> property on the edit links would help and would only be visible on hovering over the link. -Teester (talk) 13:28, 30 September 2018 (UTC)
@Teester, thanks, fixed the automatic key/value detection. I am not sure what you mean by the missing section - any params you set on the template are automatically passed to the {{Description}}. I agree about the edit box's title - could you help out with that (have to board the plane). Feel free to modify the module. Thanks! --Yurik (talk) 19:00, 30 September 2018 (UTC)

Search suggestions to Wikibase only?

Currently, the wiki search suggests items in wikibase only. Could this please be changed (back)? This is somewhat confusing. I thought the main reason for Wikibase would be the machine-readable interface. I guess, they do not need the search suggestions...? @Yurik --Tigerfell This user is member of the wiki team of OSM (Let's talk) 16:32, 21 September 2018 (UTC)

@Tigerfell, thx, weird, must be a bug - it should include both the main namespace and item namespace in the suggestions. I will see how to fix that. --Yurik (talk)
P.S. the new items are still designed for humans - machines use an API :) We do want users to go to those pages to add translations and write short descriptions. Advanced users could add statements to specify validation rules, suggestions, etc. --Yurik (talk) 16:42, 21 September 2018 (UTC)

How to structure relation's metadata?

I was looking at the Relation:route, trying to figure out the best way to structure that information. First, we need to have some sort of an item that describes a relation's type. We kind of already have it in terms of a Tag, e.g. type=route (not yet in Wikibase), but this is not the same as a relation's item. Example:

property example value info
label "route relation"
instance of (P2) relation type (Q6)
<relation-type-tag> (label TBD) (item for type=route) type seems to be the only way to differentiate relations
sitelink Relation:route

The "relation's member role" is a string that could be set to a specific value like platform, or it could have free-form component, e.g. platform:<number>. I added relation member role (Q4667) (to be used with instance of (P2)) and relation role ID (P21), but I don't think this would be enough. Proposed structure for storing relation member role:

property example value info
label "platform (route rel member)" indicate which relation type this role is for
instance of (P2) relation member role (Q4667)
relation role ID (P21) "platform" for multi-valued ones, there will be a trailing colon
<relation> (label TBD) (item linked to Relation:route) Need to link to the item that represents route relations
ERROR: Invalid ID way (Q4), area (Q5) Same as with keys and tags
sitelink - (I don't think we have pages for them, so no sitelink)

In case the role can have extra data, use similar approach as we would for the Key elements, e.g. regex validation rule. The relation role ID (P21) will have to be ending with a colon. We might want to add some other "member role type" property, similar to Keys. There will be no enum-like type similar to well-known values (Q8). Thoughts? --Yurik (talk) 07:55, 23 September 2018 (UTC)

Describing "required" constraint

Some Key:* pages have requires section in the info card, e.g. service=*. The requirement is described in plain text. How can we document it in Wikibase? Should we support arbitrary Boolean logic (any combination of must have, must not have, this OR that, this AND that, and groups? This might be overly complex to support. --Yurik (talk) 07:55, 23 September 2018 (UTC)

I'm not sure that list of required tags is complete. And even if it is, if it would be a good idea to document tag use from top to bottom. If we have taginfo that has info about service=* not being used without these other tags, than we can take that info from there automatically. Put it in the list of "frequent combinations with this tag". Janko (talk) 13:58, 23 September 2018 (UTC)

Linking to Wikidata

One big thing I'm missing is a link to Wikidata. For instance, bridge:movable (Q104) should somehow link to w:d:Q787417, either with a sitelink or a dedicated property. What do you say, @Yurik? Pizzaiolo (talk) 12:28, 23 September 2018 (UTC)

I think we first need items that are tag combinations, and then we will be able to connect them properly. For example, I'm not sure only bridge:movable (Q104) is enough to describe a movable bridge, I think we need man_made=bridge too. Tag combination leisure=pitch+sport=soccer is definitely the only way to describe w:d:Q8524. Neither of those two tags can describe it by itself. Janko (talk) 13:30, 23 September 2018 (UTC)

@Pizzaiolo, current list of props already contains two wikidata-linking properties. E.g. you can use Wikidata concept (P12). On the other hand, I do agree with @Janko that it is a combination of items that identify a concept, not a single tag. Her's an item that we can use: concept (EXPERIMENTAL) (Q4668). I created a required key or tag (P22) that you can use to list all required keys or tags. So for the movable bridge you would create a new item, set instance of (P2) to concept (EXPERIMENTAL) (Q4668), and set required key or tag (P22) to bridge:movable (Q104), together with any other items. Let's experiment with it, see how far we can get. In a way, this is identical to a preset in an editor - it lists "must haves" and "recommended" tags/keys, so if the user wants to insert a "movable bridge", it can offer all the needed options. One worry I have is that we may end up with a duplicate of every tag and key. --Yurik (talk) 17:40, 23 September 2018 (UTC)

That's a good point. Do we know what combinations are going to look like? Pizzaiolo (talk) 10:48, 24 September 2018 (UTC)


There are a minimal "wikidata->osmkey" linking information exists now ( Keys: 223  ; Tags: 1376 )

Some are linked to the wikidata P value! examples:

How we can sync data between two databases (wikidata <-> OSMWikibase) ?

--ImreSamu (talk) 15:14, 30 September 2018 (UTC)

  • @Yurik One thing we can already do is link key and tag documentation pages to their equivalents on Wikidata. This information is already in the infoboxes here at this wiki, they just need to be retrieved. Pizzaiolo (talk) 00:50, 26 March 2019 (UTC)
    • @Pizzaiolo this is already done (unless you mean something else): if you go to Key:bridge:movable, you see a wikidata link to Q787417 in the infobox. If you edit the page and delete it, and do a "page preview" (don't save it please), you will see that the wikidata link still shows there because it is coming from the data item. --Yurik (talk) 01:15, 26 March 2019 (UTC)
      • @Yurik Thanks! Nice to see your bot rescraping that information from time to time. Pizzaiolo (talk) 23:07, 26 March 2019 (UTC)

Invoking Wikidata statements

This is probably tangential to Wikibase on OSM Wiki, but for articles such as OsmAnd, it would be great to pull information from 3087512 to populate its infobox. Currently is that a possibility? Pizzaiolo (talk) 10:56, 24 September 2018 (UTC)

What would make sense here would be to build local Wikibase records with the software cards in them, especially if it means we can restart automatically building the tables TTTbot used to build.--Andrew (talk) 12:26, 24 September 2018 (UTC)

How to attribute "always used together with…"

bicycle_parking=* is defined as "always used together with" amenity=bicycle_parking. How do I attribute this on bicycle_parking (Q1099) or the wikidata page for amenity=bicycle_parking (which I don't know how to find ATM). —Preceding unsigned comment added by Tordans (talkcontribs)

Finding item is usually easy - go to the page that describes it, e.g. the bicycle_parking, and click the OpenStreetMap Wiki item link in the tools section on the left side. If the link is not there, that means there is no such item (at the moment there isn't - my bot is still creating them).
Validation rules are fun. You can do it with a property this item must be accompanied by this other key/tag (otherwise known as requires - required key or tag (P22)) on the bicycle_parking (Q1099). See describing required constraint above for the related issues, e.g. what if we need more complex rules like "this item requires either A or B", or "it requires A and (B or C)". We might actually end up with the top-down restriction model, where each OSM element must fulfill a "role" (or several). The role would describe all of the requirements, such as "must have A, B, C tags, may have D and E, must have either X or Z, ...". If the role gets too complicated, we simply split it into two separate roles. --Yurik (talk) 07:07, 26 September 2018 (UTC)
Thanks a lot @Yurik, I will wait a few days for the bot and then try my luck with validations :). PS: I love this initiative, thanks so much for this work!--Tordans (talk) 07:25, 26 September 2018 (UTC)

Should multi-valued tags be allowed?

There are several tags that hardcode value combination. Should these be allowed (makes migrating existing templates easier)? Or possibly treat them as combination of sorts (because all instances of the combination share the same key)... or? Apparently there are even wiki pages with images for them. Examples:

--Yurik (talk) 20:07, 26 September 2018 (UTC)

@Yurik What if values change places? Is that a new tag? I think we should just group multiple tags that have the same keys into tag collections (or some name like that) and then connect that to the wiki. Janko (talk) 20:24, 29 September 2018 (UTC)
Now I've seen the buoy tags. That's complicated, the order has meaning there. I don't know.. Janko (talk) 20:25, 29 September 2018 (UTC)

Presets

I had a GitHub discussion with an author of GoMap. They have copied all of the iD's presets, so clearly there is a good grasp of what's available. It might be interesting to try to model some of that information in Wikibase, see if it would work or not. I created a feature (Q7564) item (used for instance of (P2)), where we could try to model a few of the presets, and discuss if this is a good approach, and if we can model the most complex cases. --Yurik (talk) 20:08, 27 September 2018 (UTC) P.S. Please help iron out our "demo" item - Surface (Q7565). Lets model all aspects of a feature as we would want from it, e.g. requirements, nice to haves, possibly sub-requirements (e.g. if address is required, lets model address feature as well, and address should not show zip code outside of US (which probably should be a restriction on the key itself), etc. --Yurik (talk) 18:23, 28 September 2018 (UTC)

@Yurik I dont see that https://wiki.openstreetmap.org/wiki/Item:Q7565 will be a good example, since it is not preset the way ID uses presents. (ID just has a defintion of it and uses it in other presets, see https://github.com/openstreetmap/iD/search?l=JSON&q=surface). An example for an iD-Preset would be the vineyard-preset https://github.com/openstreetmap/iD/blob/master/data/presets/presets/landuse/vineyard.json. It defines two required tags and also lists a few optional tags (or sub-presets). Apart from that I just don't know enough about this new structure to model this myself; need more tutorial for that. --Tordans (talk) 13:54, 29 September 2018 (UTC)

@Tordans awesome example, thanks! vineyard.json maps well to our data items, we may just need a few extra properties. (at least for the vineyard example - let me know if you saw example that's more complex):

  • name -- item's label + description... in every language!
  • addTags -- required key or tag (P22) - it lists individual keys and key=values
  • fields -- I am not exactly sure what this is. Is this a list of "sub-presets"? Again, modeling it would be straightforward, just not sure what to call/how to describe this property.
  • geometry -- ERROR: Invalid ID
  • removeTags -- we may need a new property for this... Something like "must not be used with", or "duplicates the meaning of" ? Not sure what to call it.
  • tags -- how is this different from addTags ?
  • terms -- not sure what these are. Is that a list of search keywords? If so, aliases would be a perfect fit.

Could @Bhousel clear up some of it too? --Yurik (talk) 03:23, 30 September 2018 (UTC)

@Yurik Some information about - iD presets/fields:
I have created a minimal russian version for you ( presets, fields + russian translations )
(imho) The imported iD-editor metadata : presets / fields / translations / name suggestions
  • should be "read only" in the OSMWikibase. (protected, No edit by Human editors - only just 1 import bot)
  • refreshed in every hour ? ( because of the transifex translations )
  • key name: we should use same iD-key - as in the Transifex Key - with extra prefix ( 'id:'+ 'presets.presets.advertising/billboard' )
(imho) The key problem is here - that there are multiple version of every metadata/translations
(imho) IF "This project's goal is NOT to replace the primary tag storage for the OSM database, " -
(imho) As I understand - most of keys has at least 3-4 version in the OSM-Wikibase - linked each-other
This is based on my current understandings - about the OSMWikibase project. --ImreSamu (talk) 13:55, 30 September 2018 (UTC)
@ImreSamu thanks for the details. First, a minor misunderstanding -- I wrote that this system should not be the primary store for the tags themselves -- in other words, it should not store details of each OSM object (node/way/rel) in the wiki. E.g. "this node is a museum" shouldn't be here. I do think it should be the primary store for all of the metadata, e.g. information about the meaning of the tags, how/when to use them, groupings, validation rules, presets, etc - in other words - any documentation about OSM data. This keeps all of documentation in one place, queryable, multilingual, with the ability for automated verification, with the goal of multiple tools being able to use it consistently. I have been around for a while, but I had no idea I had to use Transifex to translate the data. I don't think its a good workflow where some of the documentation is on multiple wiki pages (one per language), some in json files (iD presets), map css (JOSM validations), some in Transifex for translation, some rules are hardcoded in various bots (no idea how to find them), etc. This leads to confusion, mistakes, inconsistencies, and makes it harder for the new data consumers to start using OSM data. I do not think we should drop everything as soon as possible - that would be too disruptive without a clear benefit. I do think we should move towards consolidation. For example, that table you created (thx!!) - it should be possible to easily create it by just running a single SPARQL query: show description-en and description-ru for all entities with instance-of=preset, that have changed in the last 3 days, and whose tags are used in OSM data more than 1000 times.
All this implies that creating a readonly copy is not applicable -- this is a master source. Your amenity=pub example will use wikibase data directly - see {{KeyDescription/Sandbox}} and {{ValueDescription/Sandbox}}, so there won't be a copy. I hope this clarifies it. Thanks! --Yurik (talk) 05:41, 3 October 2018 (UTC)
@Yurik OK, I am still not understandings all details, but sometimes not so easy to see the big picture - at least in the decentralized / Bazaar style osm ecosystem. My vision/target is minimal now: compare all translations, and create some language reports ... so I have to link the (keys/tags)metadata. Every system has unique translations ( for example - the OSMAND translations ( https://hosted.weblate.org/translate/osmand/phrases/ru/?checksum=18b6db88189e2fbe#translations ). So different concepts, different metadata structures, different licenses - so not so easy to organize. I am still learning and researching. ( and watching this project ) --ImreSamu (talk) 22:52, 3 October 2018 (UTC)

I've been using iD a lot so I may understand the json:

  • name -- name of a feature
  • tags -- minimal amount of tags to classify something as an instance of this feature. This is akin to the tag combination I proposed.
  • addTags -- if you click a node, way or area, and tell iD to convert it into a feature, iD will add these tags. In the vineyard example, crop=grapes isn't necessary to call something a vineyard because landuse=vineyard implies crop=grapes. But iD adds it anyway. I'm not sure how to call this. Implied tags? If you added anything except "grapes", it could be considered invalid. Another example could be highway=motorway that implies oneway=yes, but it's good practice to add it anyway. Janko (talk) 13:58, 1 October 2018 (UTC)
  • fields -- These are most frequent tags that go along this feature. Something like tag attributes I proposed.
  • geometry -- ERROR: Invalid ID
  • removeTags -- When you click a feature in the iD editor, and then try to change the feature type it is (for example, change a vineyard into a orchard) these are the tags that are removed to give space for a new set of defining tags. Vineyard example removed the defining tag, the implied tag, and one of the features, grape_variety, (but not operator) because there is little chance it would be useful for other features.
  • terms -- probably keywords.

—Preceding unsigned comment added by Janko (talkcontribs)

Thanks @Janko, so if I understood you correctly: tags = required, addTags = recommended in addition to required, but not implied (whose meaning is that you shouldn't add them because they are understood by all systems); removeTags - a subset of tags+addTags that should be removed when object is changing its type. Still unclear - fields -- is that a group-like feature? How is it different from terms? Thx! --Yurik (talk) 05:10, 3 October 2018 (UTC)

Finding missing descriptions and fields

How do you find where descriptions and other information are missing, for instance where there is no full page to import them from? --Andrew (talk) 10:34, 28 September 2018 (UTC)

@Wynndale at the moment there is no easy way to do that, but I'm hoping to make one soon. You will be able to query all this data using SPARQL, just like you can in Wikidata (see WDQS). For now, my bot has a cached copy of the whole wikibase (which is not very big at this point), and runs some queries on it locally. --Yurik (talk) 18:24, 28 September 2018 (UTC)
What I am looking at doing is filling in gaps systematically. Ideally every tag in Wikibase, including subkeys and values that are documented as part of their parent, can get a set of values and descriptions in several languages, making a large amount of information available to software that reads the data. To do this it would be convenient to know what should be added.--Andrew (talk)
Agree, this would be the goal, and the query system should help us solve it. Lets hope I have some free time next month :) P.S. my first goal right now is to migrate to the {{KeyDescription/Sandbox}} and {{ValueDescription/Sandbox}} templates. --Yurik (talk) 02:56, 30 September 2018 (UTC)

Linking between DataItems (SOLVED: and Linking between Wikipage and DataItems)

I have a hard time understanding the system because of it's missing links.

Issue a: I created a "required"-relation from https://wiki.openstreetmap.org/wiki/Item:Q1099 to https://wiki.openstreetmap.org/wiki/Item:Q6652. So Item:Q1099 shows the link to Item:Q6652 on the relation now. But Item:Q6652 does not show the relation back. The only way to see the link from a.1 is via the "links to this page"-feature (https://wiki.openstreetmap.org/wiki/Special:WhatLinksHere/Item:Q6652). But this feature is two clicks and one page-load away, very hidden and therefore not a good solution. Ideally the Items that relate to eachother would show their links on the item page directly. --Tordans (talk) 13:34, 29 September 2018 (UTC)

SOLVED: Issue b: How to I get from a DataItem to the corresponding wiki-page? There is no "wikipage"-relation ATM, which I assume is by design, 'cause the relation will be created automatically once the Items are added to the Wiki-Page, is that right? If so, the item-page should have a prominent link to the wiki-page (see Issue a). --Tordans (talk) 13:34, 29 September 2018 (UTC)

I found the link: On the item-page, next to the headline there is the link to the wiki-page. --Tordans (talk) 14:02, 29 September 2018 (UTC)
@Tordans not sure why you call "links to this page" as a two clicks, looks like just one to me :)). This is a fairly common Wikibase problem, and it has several solutions. First - the reason why it is done that way, is because each page shows just the values stored on that page. If you showed everything that was using this item, you may get huge amounts of useless data. For example, almost all data items right now link to tag (Q2), node (Q3), way (Q4), ... - you wouldn't want to see them all when viewing those pages (try clicking on "what links here" for them). That said, very often you will want to have an intelligent query of connected items. I have seen people use gadgets on the wikidata.org site. Those gadgets tend to use Wikidata Query Service. I don't have that set up for OSM wiki just yet, but hopefully it will be there within a month, and people will be able to build custom OSM wiki gadgets to help with this. --Yurik (talk) 02:37, 30 September 2018 (UTC)

How do I add bicycle_parking=stands?

We have the general description of bicycle_parking (Q1099) which is basically bicycle_parking=*. But we also need the (most common) values, like bicycle_parking=stands. The wiki page bicycle_parking=* has ~15 of those. How to I add them? Is there a "add sub item"-link? --Tordans (talk) 14:10, 29 September 2018 (UTC)

@Tordans I agree we need those values, but I don't have an easy way to find them all from the wiki. I might import them from the taginfo site, but that won't have descriptions. So far, I have scanned the wiki for the {{ValueDescription}} usage, and imported thousands of those. The bicycle_parking, as you can see from the red link (i modified your post a bit), shows that we don't have a page for that. And I don't think we should have a page, but instead we do need to find a good way to parse these tables into the data items. If you can create a google spreadsheet with all these values (key, value, description_en, plus possibly more languages, image, group, status, elements_to_use_on) -- I can automatically import them. Note that you don't need to specify anything that's the same as the key data item. E.g. don't worry about the group or status if its the same as bicycle_parking key itself, or if there is no data about it. Also, there is no such thing as a "subitem" here. A tag value is simply another data item, with its instance of (P2) set to tag (Q2). See bridge=movable (Q5711) for an example. --Yurik (talk) 02:29, 30 September 2018 (UTC)

Tag combinations and Tag attributes

Tag combinations are items that have a semantic meaning only when together. But there are too many combinations. For example, shop=bicycle can have service:bicycle:retail=yes, service:bicycle:rental=yes, and lots others. So do we really make a combination for all those tags? I think we should maybe add attributes to shop=bicycle, and each attribute has a short description. That way you can also add a default value of the attribute, for example attribute oneway for highway=secondary has default value "no" if there is no oneway tag. And "yes" for motorway. Janko (talk) 20:06, 29 September 2018 (UTC)

@Janko For the yes tags we could either have a data item for both the key and the value (that's how we have some of them already) - e.g. an item for service:bicycle:retail=yes in addition to the service:bicycle:retail=* (service:bicycle:retail (Q691)). Or we could introduce a new "yes-only" item for key type (P9), and use it instead of the well-known values (Q8). There are pros/cons for both. On one hand, there are many "yes" items, so duplicating them makes it harder to manage. Plus it is not clear how the description should be different between the key and the value. On the other, yes values very often morph into other values as well, so it will not be clear how to document those - should we change the type of the item from yes-only to known-values?
For the combinations, this is becoming even stranger. In theory, we can an infinite number of tag combinations. Which of these should we document? Apparently iD has done some preset system that we could model after. Should we just try to import their work? --Yurik (talk) 02:54, 30 September 2018 (UTC)

extreme number of some presets: count(Tags) > 10000

in the https://taginfo.openstreetmap.org/projects - some projects have an extreme number of presets (tags)

TOP5

some theoretical questions:

I don't know the answers - but we need plan ahead - and prevent some problems.

--ImreSamu (talk) 14:45, 30 September 2018 (UTC)

Bot documentation

Frequently there's some mentioning of some magic bots on this page to populate Wikibase from Taginfo or other sources. I don't seem to find any documentation on how to run those bots, any source code, or anything else. This is pretty bad after all. Can we please make sure that _any_ bot running on this Wiki _must_ include necessary documentation as well as source code. Ideally this should get reviewed as well, but I doubt that anyone will actually be able to do so. Mmd (talk) 08:30, 6 October 2018 (UTC)

@Mmd agree, a very valid point. So far the bot was developed in an ad-hoc manner, based on some of the discussions and ideas we had here. The code is getting more stable now, and I will publish it soon. --Yurik (talk) 09:57, 6 October 2018 (UTC)
It's been quite a while. Did you happen to have ths code and documentation published somewhere already? Mmd (talk) 08:45, 3 April 2019 (UTC)
@Mmd I have been pushing code snapshots (semi-unfinished state) to sophox's metabot branch. Should have something more polished shortly - I will have it running in a docker container on a server, listening to the recent changes and react automatically. --Yurik (talk) 01:22, 9 April 2019 (UTC)
@Yurik It would be pretty helpful if you would drop some bullet points at User:Yurikbot and link to the code from there. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 08:19, 9 April 2019 (UTC)

Listing translations

Would we be interested in storing the list of translated pages in the data items? For example, Item:Q104#P31 stores the list of Key:bridge:movable translations.

PROs 
Page titles do not have to be the same as the EN page, and can be localized. Better performance - language template will work much faster, and will be created using a simple Lua script. 3rd party tools can easily find all translated pages. For EN pages, Lua can get the list of other languages by using associated data item.
CONs 
A page wouldn't show up in the list of translations unless added to the data item (could be automated). Each page must have a corresponding data item (also automation). Non EN pages must specify either the data item or the corresponding EN page's title in order for Lua script to find the right data item.

--Yurik (talk) 09:57, 6 October 2018 (UTC)


imho / I don't know the technical backgrounds:
  • language neutrality - so please add "all languages" ( include EN ) to your example. - imho this is like a "Wikipedia Sites" concept in Wikidata - with differences; my suggestions "Available languages".
    • the "translated pages"/"page in other languages" is not a neutral concept,
    • sometimes the English version is a translated version. for example Key:jel - "Hungary marked hiking trails"
    • sometimes no English version. (it is possible; for example, some local keys - used by local imports)
  • should be protected by human edit. We have a fix id - the osm key, so no need human edit here.
--ImreSamu (talk) 12:55, 6 October 2018 (UTC)
ImreSamu, I would love to make it less "English-centric", but with this approach it won't make any sense. OSM wiki is designed around English being the primary language, e.g. Key:bridge:movable is always in English, and all translations add some prefix, e.g. JA:Key:bridge:movable. The primary (EN) page is already part of the data item -- see the link in the upper right corner of the Item:Q104. Duplicating it just for the sake of duplicating will lead to errors and confusion. I wish there was a different approach, but I cannot think of one.
P.S. Making it automatic is semi-possible IF each non-EN page links to the EN page in the languages template. For example, JA page could add {{Languages|ja|Key:bridge:movable}} or {{Languages|ja|Q104}}, which would tell the languages template that the language of the current page is JA, and also will show the list of other languages from the data item. A bot could also update that data item with the link to JA page. This assumes that there is only one laguage per data item. --Yurik (talk) 19:13, 6 October 2018 (UTC)
Do you mean using the Wikipedia interwiki mechanism with our own Wikibase instance?--Andrew (talk) 18:12, 6 October 2018 (UTC)
Andrew, Wikipedia interwikis (sitelinks) would not work for us because Wikibase assumes there is only one page per wiki (in other words, each wiki represents only one language). We use sitelink mechanism to connect data items with corresponding English pages, e.g. Item:Q104 links to Key:bridge:movable. Sitelink is shown in the top right corner of the data item's page. The suggestion above on the other hand is not tied to the sitelinking mechanism, but instead uses a "monolingual string" property - a string that also contains the language it is written in, or in our case - the language of the page. So we can store any number of such strings in one data item. --Yurik (talk) 19:13, 6 October 2018 (UTC)


There are tags - with wiki pages, but without English translations.
from a QA view, it is important info IF English translations exist or not. ( need some QA report to fix )
Some examples:
As I see the Taginfo don't expect - that English Wiki always exist
* https://taginfo.openstreetmap.org/tags/?key=boundary&value=religious_administration#wiki (Wiki pages about this tag : Deutsch · polski - no English!)
* https://taginfo.openstreetmap.org/tags/brand=Trilib'#wiki
* ...
And ceckin the JOSM XML preset - this is also contains the english wiki pages.
for example Highway_link info in the XML:
"link (i18n) - web link to further details (optional)"
( example from the : beautified-JOSM-preset )
So How I can detect if the "tags" has not English wiki page?
--ImreSamu (talk) 22:01, 6 October 2018 (UTC)


ImreSamu, the item shop=outpost (Q5145) uses Tag:shop=outpost as a sitelink (upper right corner), but (sadly) does not show it as a red link (technical limitation). This is how this data item can be found by everyone, despite the page not being there. You are correct that this leaves open the QA problem you mentioned. I see two options: either we always add EN links (which would be for the majority of the data items), and have a complex bot that catches things like mismatched sitelink and regular link, missing regular links when it should be there, etc, OR, use a special English string, e.g. "_" to indicate that there is no English translation for that data item. I suspect adding EN link to all data items might be more disruptive and error prone than using a special case. Underscore was chosen because no wiki page can be named that. --Yurik (talk) 22:31, 6 October 2018 (UTC)

Yurik,
  • according to the taginfo "OpenStreetMap is an international project. Tags and their descriptions can be in any language. This table lists the languages taginfo knows about and how many wiki pages there are in these languages documenting keys and tags, respectively." IMHO: languages is a highly polarized topic, so you will receive mostly emotional reactions. And this is a too high risk for a minimal local optimum.
  • Don't expect that the community will create all wiki documentation: https://taginfo.openstreetmap.org/reports/frequently_used_keys_without_wiki_page
  • You can download the taginfo osm wiki (sqlite3) database here: https://taginfo.openstreetmap.org/download
--ImreSamu (talk) 00:58, 7 October 2018 (UTC)
ImreSamu, I am afraid I did not explain properly, or you misunderstood. I am not saying we should force documentation, or that English page MUST exist, or anything like that. I am talking about a small technical element to match the current OSM wiki setup - something that 99.99% of the community would not even be aware of. If you want to introduce "EN:Key:something" pages for every key to document that Key in English, I'm all for adding that string to the property - because then there is a difference between the KEY (sitelink) and the description page in English. But without it, there is no point to storing EN string in 2 places -- sitelink and P31 property, as that would cause errors, without giving any benefit. I would even go further and suggest that P31 should almost never be set by any user. Instead, a bot should track when a page XX:Key:something is created, and automatically update that property. BTW, I am not a native English speaker, so I hope my opinion is not based on the language bias, but purely on the technical merit. --Yurik (talk) 01:13, 7 October 2018 (UTC)
Yurik, thank you! debugging my own misunderstanding:
  • the "local sitelink" = Key:bridge:movable is like a "human primary key" ?
  • And If the Users can set their preferred language (like in the wikidata) -> the sitelink (upper right corner) should be changed to the preferred language.
--ImreSamu (talk) 00:06, 8 October 2018 (UTC)
That's a good analogy, yes. I do think it would be nice to show a localized link there - but it would require some creative coding though, esp if we also want to show red link for missing page. This is not a critical requirement (most people will be reading wiki pages, not the data items), but definitely nice to have. --Yurik (talk) 00:53, 8 October 2018 (UTC)

DONE This has now been implemented as documentation wiki pages (P31) on most data items, and it includes English pages as well. --Yurik (talk) 02:58, 24 January 2019 (UTC)

KeyDescription has been migrated

Today I finished migrating {{KeyDescription}} template to use the new Wikibase items. It should function transparently to everyone. The only noticable change is the small gray pencil icon next to the description - lets users quickly edit the corresponding item. Note that if description mismatches between the item and the wiki page, it will show two pencils - a red one to edit wiki page, and a gray one for the item. Please make them the same, and it the red pencil will disappear. All such mismatches are tracked with various categories, e.g. Category:Mismatched description. Please let me know if anything breaks. --Yurik (talk) 00:01, 6 December 2018 (UTC)

I do not see "Documented values:" line. --Władysław Komorek (talk) 13:08, 10 December 2018 (UTC)

It is OK. --Władysław Komorek (talk) 23:16, 14 December 2018 (UTC)

Native name within the side template KeyDescription, ValueDescription

Topic moved from Wiki Translations.

Can we add the parameter |nativekey = in Template:KeyDescription, |nativekey = and |nativevalue = in Template:ValueDescription as a name internationalization project?

Many names in English are very unclear with any translation (e.g. in Google).
I have been adding it for a long time in Polish versions, but I have to use my own modified templates.
I would prefer to use standard templates, as well as other people from Poland.

An additional name in the native language inside the template, it will help them quickly understand names for people who do not know any of the languages describing a given key or tag and simplify the search.
Maybe someone knows a better way to show these native names in side templates?

E.g:

{{ValueDescription
|key=
|value=
|nativekey=<name in native language>
|nativevalue=<name in native language>
.
.
}}

Thank you for your understanding. --Władysław Komorek (talk) 23:07, 9 December 2018 (UTC)

Władysław Komorek, thanks for raising it. I was looking at PL version of the template just yesterday -- AFAIK it is the only template that does not use {{Description}}, and it is on my todo list to fix it. If I understand correctly, nativekey and nativevalue are the only additional parameters it handles. Please take a look at the ValueDescription Intro section - I already mention the usage of those two parameters (same for Key), and that they should be added to the data items as translated item label. In the mean time, I will add handling of the nativekey/value to the Description template - it won't affect any key/tag page that doesn't use it. --Yurik (talk) 23:39, 9 December 2018 (UTC)
It would also be nice to add a missing value for |image_caption = and the line below. See taxon=*. --Władysław Komorek (talk) 23:50, 9 December 2018 (UTC)
Can't you use the already existing field "label" instead of a new "nativevalue"? (Compare above topics #English label? and #Labels and IDs) The label field is already there, it just needs to be filled and then shown by the template, perhaps somehow optionally. I think this feature would not only be interesting for Polish but also for other languages (compare this related discussion: User_talk:Geozeisig#Please, stop removing descriptions). The value for "nativekey" would have to be taken from the label field of the corresponding key-item, I assume this would be possible somehow, and it would reduce redundancy. --Hufkratzer (talk) 09:45, 12 December 2018 (UTC)

Previous discussion at Template talk:ValueDescription#native_value_and_native_key_parameters. --Andrew (talk) 00:15, 10 December 2018 (UTC)

Per above, I have switched the {{Pl:KeyDescription}} to the unified Description system. Please take a look at the new implementation, and if everything is fine, I will switch the {{Pl:ValueDescription}} as well. If it is badly broken (e.g. many pages are in a bad shape), please revert this change. --Yurik (talk) 02:48, 10 December 2018 (UTC)

So far so good. Nothing is broken. :) --Władysław Komorek (talk) 08:22, 10 December 2018 (UTC)

It would be good if the |group = parameter could create Namespace:Category. --Władysław Komorek (talk) 23:28, 9 December 2018 (UTC)

I'm not sure what you mean by Namespace:Category, could you give an existing example? If by Namespace you mean language prefix, than I already added that yesterday (ValueDescription already had it, and KeyDescription now has it automatically as well because it seems many Key:* pages did that manually). The current logic (search for "group category" in Module:DescriptionFromDataItem) -- if the group is given, check if "Category:Language:<Group>" page exists. If it does, current page is added to it. If it doesn't, than current page is added to the "Category:<Group>". Note that a page can be added to a category without the category page actually existing. --Yurik (talk) 23:47, 9 December 2018 (UTC)
Sorry. My mistake. I can see it. The only difference is that I have a group value linkable. --Władysław Komorek (talk) 00:12, 10 December 2018 (UTC)
Linking to Category:Group might not be a good idea -- Pl:Key:taxon group links to Category:Pl:Środowisko_naturalne, whereas Key:taxon group points to natural (redirects to Key:natural). If PL group linked to Pl:natural, it would have redirected to Pl:Key:natural, a much better alternative to the category. --Yurik (talk) 01:45, 10 December 2018 (UTC)
See previous topic - {{Pl:KeyDescription}} has been migrated. --Yurik (talk) 02:50, 10 December 2018 (UTC)
Maybe taxon is not the best example. Currently, I am in the process of organizing the category in the Polish version. I'm interested in linking |group = to the basic category not to the article. This will facilitate a quick search for similar tags. Also Polish name "Środowisko naturalne" is a more understandable equivalent to the English name "Natural". Category:Pl:Natural is redirected to Category:Pl:Środowisko naturalne --Władysław Komorek (talk) 10:29, 10 December 2018 (UTC)

I lost list of groups in Category:Pl:Key descriptions by group. What is there is a mess. --Władysław Komorek (talk) 00:20, 11 December 2018 (UTC)

Multi-valued regional differences

I just added regional difference storage, e.g group=... or status=... can now be different for different languages. The system is fairly straightforward for the single value ones, but it gets a bit complex for the multivalued ERROR: Invalid ID - the logic might get too complex for the casual users/data consumer. So, I see two options:

  • Keep current system, e.g. should be used on = Way (except DE,PT,RU), should not be used on = Way (only in DE,PT,RU), ....
  • Create individual properties for each type of object:
use on way = yes (no qualifiers, preferred)
use on way = no (limit to DE,PT,RU)

To set up the second system, we would need magical Q values for yes, no, unknown. Thoughts? --Yurik (talk) 02:15, 19 December 2018 (UTC)

Done - I will remove (DEPRECATED) excluding region qualifier (P27), various q items like area (Q5), and ERROR: Invalid ID. --Yurik (talk) 19:38, 24 December 2018 (UTC)

Import of redirected items

I noticed that items for the surface (Q746) tag weren't imported. I suspect the importer was programmed to skip items of which the wiki page redirects to another page, like surface=concrete. However, some of those should have an item, like surface=concrete (Q16132). How should we proceed? —M!dgard [ talk ] 22:15, 26 December 2018 (UTC)

My bot only imports infoboxes (those created with {{Description}}, such as {{ValueDescription}}). It actually ignores the redirect status of the page - e.g. if a page is a redirect but it still contains infobox, it should still be imported. At this point, the simplest would be to create an infobox inside the redirect page, and the bot will pick it up, or just set up the data item directly. Eventually all parameters should be gone, and we may even have a custom web form somewhere to automate data item creation. --Yurik (talk) 23:24, 26 December 2018 (UTC)

FYI: Wikidata Workshop in Ulm, Germany (2019)

In case anyone from Germany wants to learn more about Wikidata, there is a Workshop + Hackathon at the end of February 2019. Train tickets are sponsored. Details at https://de.wikipedia.org/wiki/Wikipedia:Wikidata-Workshop-Ulm-2019

Sigh, if only WD team would listen to the actual user requests (like allowing non "Q" items or supporting images if they are stored on the local wiki or on Commons transparently)... Still, I think Wikidata team is by far the most productive at WMF. --Yurik (talk) 17:57, 7 January 2019 (UTC)

Restructuring key validation

Currently, validation only exists as a value validation regex (P13) property. I would like to restructure it as following:

  • Introduce a new instance-of type - "validation rule"
  • key data items will have a new "validation rules" property, that links to the validation rule data items.
  • The validation rule would contain the value validation regex (P13) or possibly other properties.
  • The validation rule's label and description will describe the exact conditions, e.g. label=non-negative number and description=The value must be a non-negative number.

This structure allows us to get per-rule translations, even if the actual rule is defined outside of the data item (e.g. "geometry must not intersect lines"). This structure also allows multiple rules attached to the same key. --Yurik (talk) 21:16, 23 January 2019 (UTC)

Seems fine, I guess. —M!dgard [ talk ] 13:01, 25 January 2019 (UTC)

Regular expressions

Which regex flavour should be assumed? You have POSIX BRE and ERE, GNU BRE and ERE, PCRE, Python, Tcl

Also: I changed to “the wrapping ^( and )$”. Just ^ and $ is not equivalent to doing a full match. Consider e.g. matching decimal or hex: [0-9]*|0x[0-9a-f]+.M!dgard [ talk ] 09:00, 24 January 2019 (UTC)

This is a good question. I guess the rule should be "lowest common denominator" -- don't use character classes, always escape forward slashes, no named capturing and non-capturing groups, etc. Also, thanks for catching the wrapper logic bug. Please have a look at the previous section about restructuring rules as their own data items. P.S. I found the bug with the user editor checker, the bot shouldn't overwrite stuff again. I have reverted all the ones I found, and will rerun the bot on them properly. --Yurik (talk) 03:21, 25 January 2019 (UTC)
Actually "lowest common denominator" would exclude groups, because in the legacy BRE they're \(foobar\) and in ERE (and everything else) they're (foobar). If you take Tcl into account, you also lose things like word boundaries with \b (because they use \m and others). So "lowest common denominator" of which ones? POSIX ERE, PCRE and Python? —M!dgard [ talk ] 12:15, 25 January 2019 (UTC)
I guess what I meant was "most common stuff" (TM) :). Groups seem to be fairly well supported without escaping. The forward slashes are trickier (e.g. Perl/PHP/grep might have some issues with that?). We could make a list of systems we really want to support, e.g. JavaScript (client-side validation), Java (JOSM, Sophox's SPARQL), Python (various bots). Possibly others that actually do data validation (Ruby? .NET? ...?) --Yurik (talk) 19:21, 25 January 2019 (UTC)

Template to retrieve just a description

Is it possible to create a template to retrieve the description (plain text string) for a key or a value from the wikibase item? It would be very useful for use in the sections "See also" / "Related tags" that are at the bottom of most wiki pages, example. Currently all these descriptions have to be copied manually from the corresponding key/tag wiki pages, which is tedious/cumbersome. The template could look like {{TagDesc|key|value}} and should retrieve the description in the language of the wiki page where it was used --Hufkratzer (talk) 14:28, 17 February 2019 (UTC)

@Hufkratzer that's a good idea, thanks. We already have {{O}} to link to data items, and {{Desc}} to show the description given the Q ID (Desc is not actively used so we can change its meaning). I think we can easily change it to use the "sitelink" ID instead - e.g. you will write {{desc|Tag:noexit=yes}} or {{desc|Relation:border=inner}} to add a description of the noexit=yes or the inner role for the border relation. --Yurik (talk) 22:56, 17 February 2019 (UTC)
P.S. Are there times when you want to show more than just description, e.g. show the tag (key=value) followed by the description? The wiki might be a bit more perfomant in those cases. --Yurik (talk) 23:18, 17 February 2019 (UTC)
I would like to have, always as a format, the first line where/when to use this tag/value:
Tag|key|value - {{TagDesc|key|value}}
Then the "==Description==" section for the object "key=value", where you can add more description of the given value or key , as in this example.
Often, instead of a Wikipedia link, we have a rewritten Wikipedia text. Currently, we have a different article structure. Giving some order in the creation of proposals and then a new page tag=value, simplifies reading and translation of the article. --Władysław Komorek (talk) 07:57, 18 February 2019 (UTC)
* I would not overwrite/redefine the standard template {{Desc}} because someone might want to use it in its original form and because it would be confusing; I think it's better to create or to extend other OSM specific templates.
* I find {{Desc|Tag:noexit= yes }} more complicated to write than {{TagDesc|noexit|yes}}.
* I don't think that the new template should create section headers or other additional things to the description string because this would limit its usefulness. Very few wiki pages use the same description string that is shown in the {{ValueDescription}} box also in their long text. What I had in mind was to use it in the "See also" sections like "{{Tag|amenity|waste_disposal}} - {{TagDesc|amenity|waste_disposal}}". An alternative may be to integrate the functionality into the already existing {{Tag}} template. Then, for example, instead of the above we would just need to write "{{Tag|amenity|waste_disposal|desc= yes }}" or sth. like that. But "{{TagDesc|amenity|waste_disposal}}" would have the advantage that it could also be used in tables (e.g. in Template:Map_Features:amenity). OTOH perhaps we can also extend the {{Tag}} template in a way that it can alternatively also be used this way (e.g. "{{Tag|amenity|waste_disposal|desc= only }}"). I am not sure what is better/easier.
* Without a parameter for the language the standard template {{Desc}} gets the description in the current language of the wiki user interface. This is not what we want, we always want Polish descriptions on Polish wiki pages, German descriptions on German wiki pages and so on. So we need to detect the language of the page where the template is used (probably from the filename) and then use {{Desc}} with parameter "en", "pl", "de" ... (e.g. {{Desc|Q6465|pl}}).
* For key descriptions (and relation descriptions?) we need similar things.
--Hufkratzer (talk) 21:05, 18 February 2019 (UTC)

Rendering in ______

@Yurik it would be nice to have properties for "rendering in {map project}", containing their pictures. For instance as seen in Tag:shop=lottery. Pizzaiolo (talk) 23:18, 26 February 2019 (UTC)

@Pizzaiolo we already have P38 (deprecated) and OSM Carto image (P39) (just like images we need to have 2 because Wikibase only supports images directly from Commons, and does not handle the local ones). I'm not sure if osmcarto-rendering-size should be stored too. --Yurik (talk) 03:06, 28 February 2019 (UTC)
P.S. I'm running the bot now to import all the rendering images, but still not sure what to do with the sizes - it seems wrong to store them as they are tied to pixels, but maybe it would be ok to create a facet property to store it... Not sure. --Yurik (talk) 03:31, 28 February 2019 (UTC)
Let's please avoid a solution that only works for OSM Carto. Adding rendering examples for Carto directly to the key/tag infoboxes was specifically done as a temporary shortcut to allow Taginfo/Taglists to produce the same output as the existing Map Features templates. I see no reason for Wikibase to have the same limitation.
Also, I'm not sure how to handle the overlap with Taginfo/Projects, which already supports adding the icons used for a tag by a particular renderer (but unfortunately does not support rendering examples for non-point features yet). It's certainly more convenient as a developer to automatically generate JSON for Taginfo than to keep such data current on Wikibase.
Overall, I feel this topic may need some more thought. --Tordanik 21:53, 4 March 2019 (UTC)
I agree that the property should not be tied to a specific renderer. But the current schema can handle it, all we have to do, is to add a qualifier to each statement. Although, we do not have the property "renderer" yet, which seems as a good next step.--YjM (talk) 22:09, 4 March 2019 (UTC)
@Tordanik, @YjM I agree we should store more than just OSM Carto. We can use two approaches (both have drawbacks):
  • Dedicated property for each map style -- this approach is more straightforward, and a much easier to manage/process/query. OSM Carto will be stored as OSM Carto image (P39) (will need to update the label & description). The only drawback -- new style properties must be requested from admins -- please add a property request as a new topic on this page (this might be ok as new styles don't appear too often, and community can discuss them first).
  • Single property with qualifiers -- each map style would have to be a data item, and there will need to be a qualifier property to link to it. Drawbacks is that it is somewhat harder to edit (users have to know about qualifiers, validation is needed to ensure qualifier exists and is valid), and harder to query. The benefit is it makes it easier to add a new style - just create a new data item for the style.
I feel the ease-of-use is far more important than the speed of adding new map styles, so I think the first approach is better. See below section about removing double image properties. --Yurik (talk) 19:38, 5 March 2019 (UTC)
P.S. @Tordanik I did not understand your other comment about taginfo integration. The goal is to make data items easy to query and create data for taginfo and other projects.
To (hopefully) clarify that other comment: Taginfo/Projects records the tags supported by a rendering style, including (optionally) the icon used for that tag. See the entries for JOSM or OsmAnd, for example. One limitation is that it currently only supports icons, not larger images e.g. for area styles. It still seems like a bit of an overlap in functionality with the Wikibase properties we're discussing here, though. --Tordanik 18:20, 25 March 2019 (UTC)
The property seems to be limited to one image, right? I was recently asked about displaying multiple symbols for Key:healthcare. Maybe, that's worth a thought as well ...? @MalgiK --Tigerfell This user is member of the wiki team of OSM (Let's talk) 13:41, 5 March 2019 (UTC)
@Tigerfell see above.--Yurik (talk) 19:40, 5 March 2019 (UTC)
Update: I have consolidated two rendering image properties into one OSM Carto image (P39). The P38 is now deprecated and should be removed soon (same as the image property). Now we can just decide how to progress -- keep P39 just for OSM Carto, or have multiple props, one per style. Example of a single P39 prop, with a style qualifier working the same way as limited to language (P26):
  • image name.jpg (preferred, works as default for all styles except those with a style qualifier)
    • Image size qualifier = 10
  • image name.jpg
    • Style qualifier = Qxxx (The WOW style)
    • Image size qualifier = 12

--Yurik (talk) 05:32, 9 April 2019 (UTC)

Removing double image properties

We have two properties for images - image (DEPRECATED) (P4) and image (P28), and also two properties for OSM Carto Rendering -- rendering image (DEPRECATED) (P38) and OSM Carto image (P39). This duplication is caused by Wikibase limitation -- "image type" only links to Wikimedia Commons, but cannot use local OSM wiki images. The second property is of type "string" - making it less convenient to work with (no autocomplete, no validation, no automatic preview, etc). Recently I made a change so that the string is automatically shown as an image using JavaScript gadget. I think we should start removing "image" type properties, and only use a "string" ones. Thoughts? --Yurik (talk) 19:38, 5 March 2019 (UTC)

My thought is that this should be solved on the Wikibase level. I was crawling through the Phabricator, but did not find any task to allow local wiki image datatype instead of WM Commons image. Do you know, Yurik, if there is some work on it? If this is not going to happen, then the "String way" seems feasible. --YjM (talk) 20:36, 5 March 2019 (UTC)
@YjM I agree, but... :) T90492 - there hasn't been any progress for a long while, and it is not anywhere on the horizon, so we have 3 choices: 1) use two properties every time we need an image (current approach, but not scalable as we have more image properties), 2) use a string instead of the image type and javascript code to show it (already done), or 3) implement/wait for it to be implemented... The #3 might take forever, as there currently noone to work on it, and later work with the upstream to merge, so we might as well in the interim work with #2. --Yurik (talk) 21:09, 5 March 2019 (UTC)
@Yurik I've never worked with Wikibase, so I have no idea how complicated it might be to translate from #2 to #3, when possible. If you say it's no problem, I think we can go with #2 for now ;-) --YjM (talk) 21:18, 5 March 2019 (UTC)
YjM migration is never straightforward because you cannot just change the type of a property -- you have to run a bot to copy a value from one property to another, update all of the usages (e.g. external tools and Lua wiki code), and eventually delete the old one. But this is still preferable than to have two properties instead of one for every usage. --Yurik (talk) 21:44, 5 March 2019 (UTC)

Yes check.svg we now have just image (P28) -- a string with the filename, without the File:/Image: prefixes. The P4 has been deprecated and might be deleted soon. Everything seems to work well. Makes all the code much cleaner. --Yurik (talk) 05:22, 9 April 2019 (UTC)

Proposal: auto-convert description Tag:xxx=yyy into a link

Often key/tag/rel descriptions contain links to other key/tag/rels. Moving content to data items removes the wiki markup, so I think we should allow well known patterns to become links again. Here are some examples that I think should automatically be converted into links. Note that this is not regular wiki markup, as that would not work for external data consumers. The bold string is how users would write it in a data item, followed by what it would be converted to in a infobox:

  • Key:highway{{Key|highway}}
  • Tag:noexit=yes{{Tag|noexit|yes}}
  • Rel:boundary{{Rel|boundary}} (the Rel template still needs to be created and made work with all languages)

--Yurik (talk) 21:49, 12 March 2019 (UTC)

How many key/tag/rel descriptions contain links to other key/tag/rels? I couldn't find a single example yet. Give some example pages please. In lists (that also contain descriptions) it is more common. --Hufkratzer (talk) 17:30, 23 March 2019 (UTC)
There are at least 188 keys and tags I found using A query to find all keys and tags that have a "=" in their description in any language. (click blue "PLAY" button on the left). While there might be some false positives, it also leaves out all of the keys that do not have an equal sign. --Yurik (talk) 17:52, 23 March 2019 (UTC)

Yes check.svg Done. See examples condo / Item:Q171 and automatic translation in es:denotation / Item:Q212. I am not sure what to do with cases like Key:construction. --Yurik (talk) 22:00, 26 March 2019 (UTC)

Updated usage statistics -- after I did some search/replacing to clean up {{Tag}} usage in descriptions -- 404 instances of tag: or key: in all of the descriptions (ignoring multiple usages inside a single string) in 198 unique data items. --Yurik (talk) 16:29, 27 March 2019 (UTC)
iD editor plans to support it, hopefully soonish. See issue #6115. --Yurik (talk) 16:31, 27 March 2019 (UTC)
It looks like taginfo does not support it, these descriptions do not show up there, see condo. How will this be solved? --Hufkratzer (talk) 10:34, 10 April 2019 (UTC)
Is there anyone with the time and programming skills to implement this, possibly with other enhancements? --Andrew (talk) 16:09, 10 April 2019 (UTC)
Which other enhancements? --Hufkratzer (talk) 17:08, 10 April 2019 (UTC)
It should be taken into account that this is related to section #Template_to_retrieve_just_a_description. If in the desc string we write Tag:building=apartments instead of {{Key|building|appartments}} and want to use this string somewhere else in the wiki it will be necessary to reconvert it. How can this be done? --Hufkratzer (talk) 17:08, 10 April 2019 (UTC)
@Hufkratzer i don't think it is the "key:" prefix that's not working. building:roof shows the description ok (with the key: prefix - so it is clearly not converting key:* to a link, but it does pick it up. I do agree that we need to get TagInfo to start using data items directly (please support), but I haven't had a chance to do it yet. I don't know anything about Ruby, making it a bit harder. I will write some Python script soonish to generate just the compatible taginfo DB from the data items, or if anyone wants to help, please let me know :).
P.S. Hufkratzer, I do want to implement a generic {{Descr|key|value}} that would handle all of the formatting. --Yurik (talk) 19:23, 10 April 2019 (UTC)

How to document *:both:*, *:left:*, *:right:* keys?

The Key Item:Q3908 is not documented. There is also no wiki page for it, the wiki is at Key:parking:lane. - What is the recommended pattern to document this? Add (duplicated) to all wikidata items? Reference them?/How? And add redirects to the wiki pages or not? - How can the wiki page in turn use the text written in the data items, so we don't have duplication? --Tordans (talk) 05:56, 18 March 2019 (UTC)

@Tordans, each data item should be documented independently, e.g. there should be a separate description for the item parking:lane:left:parallel and for parking:lane:right:parallel and for all the other ones, simply because the description will always be different, if only slightly. The only possible duplication will be in some of the statements, e.g. the type of features these tags can be used on. Even images could be different (at least in theory). Each item will have its own sitelink (link in the upper right corner), e.g. Key:parking:lane:left:parallel. Ideally we should create these sitelinked pages as redirects to the central place where actual wiki documentation is stored. Thanks! P.S. I fixed links in your message for readability. --Yurik (talk) 14:55, 18 March 2019 (UTC)

Wildcard (namespace) data item proposal

@Tordans raises an important point about using wildcard data items in the wiki pages -- in the case above, each specific key (left, right, ...) is slightly different, so it is not clear which one should be used in the infobox on the wiki page. I would like to propose that we create new type of data items: namespaces. Those will be identical to Key:... data items, except that their sitelink will contain an * symbol in them, and their instance-of will be something else. Also, each key data item that matches a wildcard should have a namespace property set to the corresponding namespace item (e.g. parking:lane:left:parallel will have "wildcard" prop set to parking:lane:*:parallel item (?)). We could use a fallback mechanism when displaying these items - e.g. the types of features the left key can be used on can be taken from the wildcard. This gets a bit hairier when a key belongs to multiple namespaces. --Yurik (talk) 15:13, 18 March 2019 (UTC)

New handy userscript to link to data items

I've adapted Yair rand's script for use in our wiki: User:Pizzaiolo/DataItemInfo.js. This shows a small link from the wiki page to the data item, along with its description and QID. To enable it, paste this

mw.loader.load("//wiki.openstreetmap.org/w/index.php?title=User:Pizzaiolo/DataItemInfo.js&action=raw&ctype=text/javascript"); // Backlink: User:Pizzaiolo/DataItemInfo.js

into your MyPage/common.js page. Be aware that some translations still refer to Wikidata. If you can, please correct these wrong translations. Pizzaiolo (talk) 00:25, 27 March 2019 (UTC)

@Pizzaiolo this is awesome, thank you! I think if we make a few changes, we can make this into a proper gadget and enable it for everyone, even by default. I think it needs to 1) only work on Key:, Tag:, and Relation: pseudo namespaces, 2) recognize language prefixes (both the namespaced ones like DE: and FR:, and the fake ones, like Pt:), 3) Do not show up if it cannot find a corresponding data item - it is better to let the bot do the item creation, and 4) figure out how we can let community translate it without constantly involving admins (might be impossible). But otherwise looks awesome, and I really want to enable it for everyone! Thank you for doing all the work! --Yurik (talk) 02:07, 27 March 2019 (UTC)
What is the point in showing this information on top of the page a second time? The Q-number is not very interesting. The aliases are interesting, but they could also be shown by the *Description templates. Or do you want to eliminate the *Description templates altogether?
But this topic reminded me of sth. related: In wikipedia there are Navigation popups. Can you make sth. like that with the information from the dataitems (incl. images) for all links to OSM-key/tag/relation pages? --Hufkratzer (talk) 15:30, 27 March 2019 (UTC)
I don't want to eliminate anything, it's just an optional script to make the link to the item easier to find. As for the navigational popup, there are two different schemes and I don't believe either the gadget nor the beta feature have support for Wikidata yet. Pizzaiolo (talk) 22:49, 27 March 2019 (UTC)
@Hufkratzer, adapting nav popups is an awesome idea! I think it might be a full rewrite rather than a copy/paste, or at least we will have to implement custom handling of the links to Key:* and Tag:* namespaces, but I think it will offer tremendous benefit to those who enable it (we could even make it on by default). Having a generic data item popup would not work for us because we almost never have a wikidata link, but rather links to key:* and tag:*. --Yurik (talk) 23:14, 27 March 2019 (UTC)

Backup

How can I download full backup of all data items, in format that requires no full Wikidata installation to use? Mateusz Konieczny (talk) 06:34, 27 March 2019 (UTC)

The easiest is actually to query Sophox to get just want you need for you task. Apart from that, you can download it via MediaWiki API (see my bot code that does exactly that). In theory regular OSM backups should contain it (needs to be checked just in case). --Yurik (talk) 06:43, 27 March 2019 (UTC)
I thought about a full backup - one of my worries about switching from templates to data items is whatever this data is backuped in some readable format. Running queries across all items seems a poor way to do that. Mateusz Konieczny (talk) 08:28, 27 March 2019 (UTC)
Data items are no different than regular wiki pages from the back up perspective -- they are stored as json inside the same system. Getting a local mediawiki + wikibase set up is a relatively painless activity - you can simply use a docker container and have it running within minutes. The non-mw approach is what i described above. --Yurik (talk) 09:28, 27 March 2019 (UTC)
OK, then everything is fine if that data is included in a regular dump of wiki Mateusz Konieczny (talk) 11:24, 27 March 2019 (UTC)
Just to be sure, I downloaded the dump (~3GB, 35GB+ uncompressed) from /dump, and yes, all the data is there. Reading JSON in XML is a bit scary and hugely wasteful: <text xml:space="preserve" bytes="3649">{&quot;type&quot;:&quot;item&quot;,&quot;id&quot;:&quot;Q4963&quot;,&quot;labels&quot;:{&quot;en&quot;:..., but alas. --Yurik (talk) 23:21, 27 March 2019 (UTC)

Standardization proposal: how to link key:wikidata tags to Wikidata concepts

Currently we have the following secondary Wikidata tags widely used:

So instead of linking, for example architect:wikidata=* to architect (Q42973), which already is linked with architect=*, I've opted to link it to the relevant property, Property:P84, in the hopes that this makes the concept more related to Wikidata itself. What do you think of this approach? I feel like having one-to-one mapping is probably a better idea. Pizzaiolo (talk) 04:02, 31 March 2019 (UTC)

Two property proposals

These would be "subkey of" and "related WikiProject". "subkey of" would link, for instance, name:etymology:wikidata=* to name:etymology=* (and consequently, name:etymology=* would link to name=*. The second one would link to projects that have an interest in that key/tag. Example: esperanto=* is of interest of WikiProject Esperanto, IBGE:GEOCODIGO=* is of interest to WikiProject Brazil. Pizzaiolo (talk) 04:28, 31 March 2019 (UTC)

New data item properties, improved UI

The `seeAlso`, `implies`, `requires`, and `combination` parameters are now shared between all languages via the data items. A bot collects all key/tag values from those parameters from all languages, and adds them to the data items. A wiki page infobox will show all those values, unless the page has something else. We may want to start removing them from non-English pages (thus TagInfo will continue loading them, but we won't duplicate info). Also, the data item UI has been improved with this code to make it more compact, remove "0 references" and "add references" for all statements except Status, and to make certain properties readonly (like permanent IDs). To see the original data item without modification, disable "Data Item Links" gadget in your preferences. --Yurik (talk) 03:52, 7 April 2019 (UTC)

Geographical regions as qualifiers

In this iD issue, there seemed to be some confusion over the purpose of the "limited to language" property. There's clearly a demand for the ability to qualify an image so that mappers using iD see a localized road sign or street fixture. For example, Item:Q5027 has several image claims that more or less correspond to national telephone providers, qualified by the national language. However, most physical features vary in appearance based on geography, not language. This distinction is clear when it comes to the many tags that are illustrated by street signs. For example, route=bicycle is illustrated by a London cycle network sign in English, but English speakers in other countries may find other signs more recognizable.

To facilitate image localization, we could create a "limited to geographical region" property and a series of items that are instances of a geographical region. Consumers such as iD would use the image qualified by the current country code, which can be determined by making a request to Nominatim or another geocoder. Yurik suggested making the property string-typed because country codes are easier to work with than full items. On the other hand, I'd prefer making it item-typed if possible, because then we could create collections of countries as items too. I think wiki contributors would find it more convenient to qualify images with "limited to the Vienna Convention signatory countries" than "limited to [each of the Vienna Convention countries]". But more indirection could make it more difficult to consume these qualifiers, so we probably need to make a tradeoff here.

 – Minh Nguyễn 💬 01:12, 9 April 2019 (UTC)

Translation of labels

Some users have been filling in the label field for non-English languages with translations of the key. This leads to rather weird labels such as the German "Brücke:Öffnungsmechanismus" for the bridge:movable item. I see two issues with that:

  • It causes the page title and properties on other items (e.g. "implies" or "requires") to no longer show the key or tag, but the label, which I find very unhelpful. I often have no idea what key is alluded to by a particular German word without clicking on it. Our key and tag infoboxes just list tags as they are, even on translated pages (e.g. DE:Key:building), and I would prefer the same behavior on data item pages.
  • It may encourage people to phrase descriptions under the assumption that the label is visible next to it (as it indeed is on Wikibase), and omit that word from the actual description. The label isn't visible in infoboxes, though, so these end up with a less useful description as a result.

Is there even a good reason to fill in labels at all? In my opinion, there isn't really a better "representation" for a key/tag than the key/tag itself, so the label could just be key or key=value for English, and empty for all other languages. --Tordanik 18:20, 16 April 2019 (UTC)

From this page's documentation of label for keys and tags:

Label usage is still a bit undecided for the key/tag data items, so it is best not to use it for anything. For now, bot sets the English label to the key's value, exactly the same as P16 below. Some languages have nativekey (localized key) that was added to the labels as well. Do not add a copy of the English label to any other languages. Note that same as "en", the localized label must be unique in that language.

So yes, it should be empty for all languages but English, unless you have a really good reason to do so. --YjM (talk) 18:34, 16 April 2019 (UTC)

Delete data item

How to propose the deletion of a data item. For example Item_talk:Q9583. For this case, I added the delete proposal-template on the talk page, which is probably wrong. --Tordans (talk) 06:11, 7 May 2019 (UTC)

usually yes, that's how it would be done, but it is very rare when we should delete an item - most of the time they are created by a bit because there is some real usage of a key or tag, even if small. use redirect property to indicate the right key to use, or document why the item is different from others. i replied to talk page too. --Yurik (talk) 10:35, 7 May 2019 (UTC)

How about completely unused Q7167? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:28, 7 May 2019 (UTC)

sure, deleted. --Yurik (talk) 20:19, 7 May 2019 (UTC)

File usage

Files linked within an item do not show up in the file usage section of the file page. Is there any configuration to fix that? Otherwise we might run into the issue of a deleted file still referenced by a data item. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:32, 7 May 2019 (UTC)

Unfortunately not -- wikibase does not support local file storage at all -- that's why at first we had two properties - one "file" property for files from commons (the "proper" way to link to files), and another "string" property with the filename of the OSM. This was too confusing, so I did a small javascript gadget to show images for that property. Luckly, there is a way to track usages via Sophox - we could write some simple query to check if a file is used anywhere in the data items, and we could add some template to all files with a link to that query, so that anyone can quickly run that query for the current file. --Yurik (talk) 20:10, 7 May 2019 (UTC)
Yes, that would be very helpful! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:14, 8 May 2019 (UTC)
@Tigerfell you can use this query to search for the exact filename:
SELECT ?osmd WHERE {
  ?osmd osmp:P28/osmps:P28 "MovableBridge roll.gif".
}

Run it (edit query)

Note that the string must be an exact match. A slightly slower query that ignores casing would be this:
SELECT ?osmd WHERE {
  ?osmd osmp:P28/osmps:P28 ?img.
  FILTER( lcase(?img) = lcase("MovableBridge roll.gif") )
}

Run it (edit query)

We have very few images in that data, so speed-wise they are almost identical. --Yurik (talk) 19:36, 8 May 2019 (UTC)

List of all key=value for a key

On Item:Q746 (Key:Surface) I would like to see a list of all Wiki Data items that describe values for this key (so all surface=* data items, eg Item:Q16171 surface=sett and other/search).

  • What are the required wiki data relations mark Item:Q16171 as a member/key-value-kombination of Item:Q746?
Answer: The k=v data item need a Property:P10 "key for this tag".
  • How to I see the list of all key-value-data-items on the key:surface data item (the relation "you are on key:surface, those are my sub-data-items of the type "member of key surface")?
Answer: There is no such list. I need to use the sophox-query below, manually. --Tordans (talk) 06:56, 12 May 2019 (UTC)
  • Can we make this easier to understand/navigate/edit/visualize?
Status: There is a lot to do IMO; I find this setup very promising but extremely hard to understand. Ideally the data item page would just show all "children of Property:P10" (see question above). Or maybe category-pages like Wikipedia has them would help(?) – I image those are auto-generated base on data items? Or other things, like quick links or more documentation … --Tordans (talk) 06:56, 12 May 2019 (UTC)
  • Are all keyname=value-data items already correctly associated with their key:keyname data item; if not, is there a special page to see those and clean them up?
Answer: Yes, they are; which can be seen in this modified sophox-query. The last columns shows the Property:P10-value which is "surface" for alle surface=*-data items. So all is good here. --Tordans (talk) 06:56, 12 May 2019 (UTC)

--Tordans (talk) 06:55, 11 May 2019 (UTC)

Tordans, what do you mean by "seeing a list on a data item"? If you want to find such items, easiest is to query it:
SELECT * WHERE {
  # Any item whose key is Q746 (surface), and get that item's permanent tag string (P19)
  ?osmd osmdt:P10 osmd:Q746;
        osmdt:P19 ?tagId.
}

Run it (edit query). All of these properties are up to date (maintained by the bot). --Yurik (talk) 18:37, 11 May 2019 (UTC)

Thanks Yurik for this query. I did some more digging and tried answering (and clarifying) my questions above.
Tordans, the last query is a bit misleading. Your query says: find me any subject that has P10 = surface, AND that subject must have a P19, AND that subject must have a P10. But the first part already guarantees that the subject will have a P10=surface, so unless you are looking for any subject that has P10 equal to more than one value (which is possible, but we shouldn't have it in the data), your modified query wouldn't show you what you are looking for. As for your question about making it easier - I think it would be very simple to add a link to the key description template to get a list of all values from Sophox. We could even make it into a slightly more complex query to show links to documentation in the result table. --Yurik (talk) 03:22, 13 May 2019 (UTC)
Yurik, thanks for the hint about the query which is also a +1 that we need better tooling (which might be links to queries) so people can jump in and check stuff more easily and without making too big mistakes :). And yes, I think linking to such query from the Data item page would be a great start. --Tordans (talk) 06:11, 13 May 2019 (UTC)

ListeriaBot

Is it possible to run ListeriaBot on OSM Wiki? It would be helpful for the collaborative improvement of metadata or creating "How to Map a" like listing pages automatically. higa4 (talk) 17:08, 11 May 2019 (UTC)

Theoretically yes, the (Wikidata-specific) source code should be this one. @Yurik? —Tacsipacsi (talk) 19:13, 11 May 2019 (UTC)
I would guess it wouldn't be too hard to run it. The only possible issue is that its a PHP bot (fairly unusual as far as wiki bots go), but that shouldn't be too hard to adapt to work on OSM... I would think :) --Yurik (talk) 03:24, 13 May 2019 (UTC)
Great, thanks! Hoping to see it someday. --higa4 (talk) 03:53, 13 May 2019 (UTC)

Add link to taginfo on data item page

The data item pages have this handy and important quicklink to the wiki on the right, next to the headline. But for tags without a wiki pages – for example on Item:Q18779 – this link is not helpful (there is no wiki page). Instead I need to manually look the tag up on taginfo (Example). From taginfo I can open the overpass turbo query wich is linked there and look at changesets that use this tag. With this info I have the needed info for the tag. — Request: Add a taginfo-link next to the wiki link. --Tordans (talk) 06:28, 12 May 2019 (UTC)

Adding values for P6

Aren't these status items necessary as values of p6(status)?

-- higa4 (talk) 05:26, 19 May 2019 (UTC)

Import genus=* (Q310)

I wonder about the Tags for Item:Q310 genus. Taginfo shows 480k tags for "genus" on nodes with "Acer" having 73k alone. I thought the bot would create data items for all those key-value-cases? But I cannot find any data item for "genus=*" (Query). If those Tags where created, we could experiment with using the data for easier tagging of trees, like discussed on GitHub.

  • What needs to happen to create data items for those "genus=*" tags from Taginfo?

--Tordans (talk) 15:37, 24 May 2019 (UTC)

A query to see all data items for "values" of a specific key (anything that has key for this tag (P10) == genus (Q310)):
SELECT * WHERE {
  ?id osmdt:P10 osmd:Q310.
}
Run it (edit query)
I am a bit concerned about adding tons of such values to data items because in reality you want a Wikidata query for a list of all available genuses -- this way you don't have to document/translate all available values for it. We of course could set up some bot to copy this info, but this might be mostly a dup efforts... What do you think? --Yurik (talk) 17:25, 10 June 2019 (UTC)

JOSM integration

FYI, I have created https://josm.openstreetmap.de/ticket/17842 to discuss/implement support of Data items in JOSM. --Don-vip (talk) 19:35, 24 June 2019 (UTC)

Deprecation icons

Data items for deprecated tags (like amenity=education (Q7514)) have the warning image copied from the {{Deprecated}} template. Is this expected? --Andrew (talk) 08:18, 7 July 2019 (UTC)

Adding sitelinks

What is the user interface for adding sitelinks to data items? --Andrew (talk) 17:10, 14 July 2019 (UTC)

Not sure how to understand your question, but there is a setting at Special:Preferences#mw-prefsection-gadgets. You can activate the Data item links there. The relevant code is located at MediaWiki:Gadget-dataitemsummary.js. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 19:31, 15 July 2019 (UTC)

Ideally you shouldn't be adding new data items yourself -- a bot should do it within half a day after the new wiki page is created. That said, there is a Special:SetSiteLink to add sitelinks. --Yurik (talk) 20:03, 15 July 2019 (UTC)