Talk:Data items

From OpenStreetMap Wiki
Jump to navigation Jump to search

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)

Could the page description be changed to explain this line in plain English: "create an item for any key with 10+ usages if it matches:
^[a-z0-9]+([-:_\.][a-z0-9]+)*$
I think this means "the key has to start with a word (string) containing only letters from a to z and numbers from 0 to 9, then a dash, colon, underscore or period, possibly followed by more letters and numbers form 0 to 9. But I don't know the last part "*$" means, nor is it clear if only the 26 letters in the English alphabet are allowed, or if you can include characters like ñ or é. It would be great to make this intelligible for people without extensive computer science / coding / programming experience. --Jeisenbe (talk) 06:15, 4 August 2019 (UTC)
@Jeisenbe I added a human-readable description. (By the way, * means “zero or more of the previous” (i.e. the parenthesised expression), and $ means “end of string”, because otherwise the regular expression might match only a portion of the string; similar to ^, which marks the beginning of the string.) —Tacsipacsi (talk) 09:23, 4 August 2019 (UTC)

Data Items should not be created by bot for undocumented tags

According to https://wiki.openstreetmap.org/wiki/Data_items#Item_Creation_Process the Data Items (aka "Wikibase" or "Wiki Data items") are automatically created by a bot, even before a tag is documented, if a tag has a certain standard format and more than 10 uses in the database.

The data item is created in this case with the text "‎Created a new Item: Auto-updating from Wiki pages" - e.g. https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947&action=history

This is confusing to users. For example, Item:Q19947 above, "landuse=research" was created before there was a wiki page. Then yesterday a user documented the tag with a page, but did not understand why there was already a data item:

"Wikibase entry: evidence for preceding deletion? I've just created landuse=research, but the data item https://wiki.openstreetmap.org/w/index.php?title=Item:Q19947&action=history was already existing in December '19. How was the data item then created?" https://wiki.openstreetmap.org/wiki/Talk:Wiki=#Wikibase_entry:_evidence_for_preceding_deletion.3F

Besided the potential confusion caused by creating these items by bots, I think it is a bad idea to encourage wiki users to start editing these data items without first creating an actual human-readable wiki page to document the tag.

In theory, the "Data Items" can be useful if they properly document how tags are used, in a way that is easier for computers to handle, but this only works if the data is maintained and updated.

Creating a new wiki page (by human) will alert other users via Special:RecentChanges and Special:NewPages, while the stream of items created by bots is too much for humans to maintain, and the page names are too obscure (Item: Q19947 is meaningless) to be scanned by humans.

Therefore, I propose that Yurikbot be changed to only add new data items for documented tags which already have a wiki page in at least one language. I do not see a benefit to creating date items for undocumented tags. --Jeisenbe (talk) 17:42, 18 February 2020 (UTC)

+1 --MalgiK (talk) 18:14, 18 February 2020 (UTC)
This is also being discussed on the Talk mailing list, starting at https://lists.openstreetmap.org/pipermail/talk/2020-February/084100.html --Jeisenbe (talk) 12:07, 19 February 2020 (UTC)

Key usage count threshold

Wiki say "create an item for any key with 10+ usages if it matches ^[a-z0-9]+([-:_\.][a-z0-9]+)*$ […] or for any 1000+ usages regardless of the key syntax".

Theses thresholds seem hard coded and are greater: >50 and >5000 (cf. sophox/metabot/metabot/Processor.py#L229)

--Pyrog (talk) 11:27, 28 June 2020 (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)
This will be problem for deprecated or discouraged tags where the Map Features description or ValueDescription description field currently recommends a link to a different tag. --Jeisenbe (talk) 11:34, 4 August 2019 (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)

@Yurik For now, can we add the most obvious types that can't be viewed as a special case of well-known values? I'm thinking of string, numeric, external identifier, and multivalue. Numeric could be paired with minimum, maximum, and interval properties. Further down the line, we could add more specialized types, such as conditionals. If we add a multivalue type, then it could be qualified by "of". But instead of a multivalue type, maybe there should be properties indicating whether multiple values are permitted and the value separator (;, ,, |, or a combination of the three). But just adding string, numeric, and external identifier would already cover a large swath of the tag corpus. String and numeric keys are pretty easy to spot based on value statistics. – Minh Nguyễn 💬 16:17, 10 December 2019 (UTC)

> there should be properties indicating whether multiple values are permitted and the value separator
We should specify:
  • a list of values
  • if multivalues are allowed (the separator is alway ";" ?)
  • if other values are allowed
  • a list of allowed subclasses (alternative of multivalues) i.e. recycling:glass=*, recycling:paper=* …
It could be done with regex but could be difficult to parse for a machine or understood by a human.
--Pyrog (talk) 13:27, 18 May 2020 (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)

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)

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)
Would it be possible to add an alt-text to those pencil images, for people who use the wiki without always loading images? This would be helpful for blind users, and for people like me who use metered internet connections. --Jeisenbe (talk) 11:55, 4 August 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)

@Yurik @Minh Nguyen Such a property would be extremely helpful as a qualifier not only for images, but also for value regex, and used for statements on keys, tags, relation types and relation roles that only make sense locally. One example, where it could be used: region-dependent postal_code=* formats and ranges, or the prefix at values for traffic_sign=*. Making it an external identifier for https://www.openstreetmap.org/relation/$1, could integrate well in what OSM already has and would make it versatile enough, so that it could be used on sub-nation level and it could help in disputed areas, that are in OSM, but don't have a country code as well. --CamelCaseNick (talk) 19:36, 20 June 2020 (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)
@Yurik - could you edit how labels are edited and displayed, to fix this issue? I've seen several cases of users adding labels in other languages by translating the `key=value` of the tag to a literal translation in their language, but this is unhelpful since the tag is actually in English. See for example https://wiki.openstreetmap.org/w/index.php?title=Item%3AQ16181&type=revision&diff=1959299&oldid=1910691. Best would be to delete or hide all non-English labels, and perhaps if possible also make the English label invisible, and replace it's location with the permanent_tag_id "property P19) (which is the same as the English label in all cases, I think). --Jeisenbe (talk) 00:16, 20 February 2020 (UTC)
> So yes, it should be empty for all languages but English
+1
> unless you have a really good reason to do so
I don't see any good reason ;)
--Pyrog (talk) 09:12, 12 October 2020 (UTC)

English label is sometime different from Template:ValueDescription parameter

For example for P22, requires is set to required key or tag.

I think that english label must be exactly the same as the infobox parameter. --Pyrog (talk) 09:31, 12 October 2020 (UTC)

"Good" usage of Description

It should be a short, concise and clear sentence, not a long description like a howto.

For example compare the list of all properties displayed in english and french.

Also, it must be translated.

--Pyrog (talk) 09:52, 12 October 2020 (UTC)

"Good" usage of Also known as (alias)

It should be a list of synonyms and must be translated.

Example : draisine (Q10198)

--Pyrog (talk) 09:58, 12 October 2020 (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)
How can we proposed deleting the empty Data Items which were created directly from usage statistics (in Taginfo), but which have no other content, besides the key=value? I think those items should not have been created, and should be deleted. They can be added back as soon as a user wants to create a wiki page manually. Should this be a wiki page in the Proposal namespace? Which of the admins has the ability to delete such items? --Jeisenbe (talk) 01:40, 20 February 2020 (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)

Try new data item editor

After a few hours of hacking, I managed to get the majority of functionality of the new data item editor. To try it out, make sure you are logged-in, and create or edit your common.js page. Add this text to it:

mediaWiki.loader.load('/w/index.php?title=User:Yurik/dataitemeditor.js&action=raw&ctype=text/javascript');

Now go to any English Key or Tag page, and click the WEF Key/Tag link in the left sidebar (refresh if you don't see it). It also works on the data items. This is ALPHA version, use with care... in the worst case, look at the data item and revert your changes.

Limitations that I plan to address shortly
  • Only supports Tag: and Key: pages, in the English pages only. Also works on the data item pages.
  • Shows a list of all available editors instead of offering just the relevant one.
  • Not tied to the "pencil" icon in the infobox.
  • Not yet available as a gadget.

Please send me any feedback, bugs, etc.

The source code is on github, with the actual templates in the /src/editors dir. The original editor was created for Wikipedia (used on ruwiki and frwiki AFAIK). --Yurik (talk) 05:17, 18 August 2019 (UTC)

Clarification: relation between data items about tags and keys

Skimming over the past discussions I understood that **groups** are some sort of wiki category on data items. I recently discussed with Ottonormalverbraucher about the removal of groups from tags' data items when the key's data item is already in the same group. They regarded the items in some kind of hierarchy, meaning that a tag only includes more specific information which might be different for each value. This view was supported by Template:ValueDescription which retrieves the group information from the key's data item, if not present.

Taking the perspective of a data user who wants to retrieve all information about a given tag, this would result in at least two queries for each tag. First querying the key and then the whole tag (potentially doing this more often with regards to namespaces). Was this intentional? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:48, 26 November 2019 (UTC)

@Yurik? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 17:34, 27 December 2019 (UTC)

@Tigerfell the key/tag templates already automatically get the "fallback" item -- search for -- Try to get a fallback entity - key for tag, tag for relation, relation for rel role in Module:DescriptionFromDataItem, and that fallback item is used when fallback = true (search for that too to see which properties are using it). So yes, some properties like groups support "override" mode -- an item may have a group value, and if it does not, the value will be used from the fallback item. --Yurik (talk) 18:38, 27 December 2019 (UTC)
I'm still not happy with adding things to the Tag/Key wiki pages automatically in a non-transparent way. While the group/category is not terribly important for understanding the use and meaning of tags and keys, it is strange for something to appear on a Tag wiki page based on a category/group which is set only in a wiki data item for the key. If something strange appears on a Tag page, due to the tag not matching the key category, it will be hard for wiki users to "debug" the problem, since the source is not going to be obvious. Is there a large enough advantage to this behaviour that we should accept this risk and the potential to confuse wiki users? --Jeisenbe (talk) 05:53, 28 December 2019 (UTC)

Use for translatable strings?

Would it ever make sense to use the multilingual label or description of a data item to manage a string displayed in the wiki in multiple languages?--Andrew (talk) 10:28, 3 January 2020 (UTC)

Thanks!

Comming from Wikidata I really like seeing all the good work put into getting the data items to work! I like the bot-solution that automatically creates items. It works quite well I think.--PangoSE (talk) 13:30, 12 January 2020 (UTC)

Add more information about current limitations and problems with the wiki data items

I appreciate the "Limitations" section, but there are a number of other issues and problems that should be mentioned. Some were provided by Mateusz Konieczyn in Talk:Wiki#Transition_to_use_data_items_when_this_can_be_done_without_loosing_information

  • Adding data item to the Watchlist means that it gets filled with "used added translation in Hungarian/Korean/etc" or in other language that is 100% unfamiliar to me where I am unable to distinguish correct edit from clear vandalism, AFAIK it is impossible to avoid it and makes easy to miss edits that I can review
  • Watchlist is filled with things like Item talk:Q5007‎‎. I really prefer to not use database identifiers as titles, especially in cases where obvious human-rememberable titles are available
  • As a direct result of watchlist issues - quality of data in data items is significantly lower than data specified in the article text (including template parameters)
  • poor page titles (compare Item:Q5007 and Tag:amenity=shelter), naming collision with the main Wikidata (see https://www.wikidata.org/wiki/Q5007 )
  • Editing interface requires JS, page loads for far longer and interface elements jump around as page continues to load
  • Inability to copy content, edit it outside browser as text and copy it back
  • Tying OSM Wiki to one more third-party system and relying on it, one more part that may break
  • Making editing Wiki more complex, now people need to edit in two different places
Mateusz Konieczny (talk) 11:24, 15 January 2020 (UTC)

Also see the problems with wikidata tags in Openstreetmap, which also overlap with this problem due to the naming confusion and identical use of Q#### by both wikidata and these wiki data times:

  • Wikidata item labels conflict with Openstreetmap wiki data items labels - both start with "Q"
  • Wikidata can be confused with the "wikibase" / "data items" / "wiki data items" now used here at wiki.openstreetmap.org

I think it's concerning that this change was introduced to the wiki without community consensus, and that it uses bots to make changes. If this were the Openstreetmap database such changes would require following the Import guidelines and Automated edits code of conduct because this sort of technical change puts great deal of potential power in the hands of one user, for good or for ill. --Jeisenbe (talk) 03:16, 16 January 2020 (UTC)

Could you please elaborate the following point.

Tying OSM Wiki to one more third-party system and relying on it, one more part that may break

I do not get "one more" and "third-party system".
Mateusz Konieczny wrote this, but I believe it refers to the fact that the code for the data items is not our own, and is strongly influenced by the needs and wants of Wikidata and Wikimedia in general, not the needs of the Openstreetmap community. And even if we fork all the code and maintain it ourselves, that is still a "third party" layer added between 1) "mappers" and 2) "The Openstreetmap database". --Jeisenbe (talk) 02:52, 17 January 2020 (UTC)
Yes, it is adding one more dependency that requires maintenance. Currently it is not a problem because it is an experiment and actual data is stored as template parameters (maybe except some translations?). But in case of deciding to stop using templates and storing all possible data in data items instead we have some new problems. We now must maintain this new system - in addition to wiki, preferably forever. And third-party is partially a good thing (maintenance of software is done by other people) but they may have incompatible priorities. For example, they refused to provide any way to change "Q" prefix, because they have no need for that (despite that in our situation it is very confusing with Q335 referring to highway=* in our Wikidata installation and Q335 referring to Patricio Aylwin in Wikidata). I worry here mostly about bus factor. What happens in case of switching to local Wikidata and the - after 2 or 5 years - losing all people who can debug, maintain and run it? Finding people who can maintain Mediawiki instance and people who can maintain Wikidata instance is always going to be trickier than finding people who can maintain Mediawiki. Especially as having private Wikidata instances is far more unusual. Note, it is not dealbreaker - but it is problem that should be at least acknowledged, and is part of the reason why I am hesitant about this new system. There are also all other standard third-part issues (incompatible upstream changes, new version requiring massive work to install etc). Mateusz Konieczny (talk) 07:21, 17 January 2020 (UTC)
Although, like any system, there certainly are limitations of the current state of Data Items, I really can't understand the aversion raised here against a "third-party system". Wikibase is nothing but a series of extensions for MediaWiki software, so it is technically no different than e.g. VisualEditor, an extension also installed into OSM wiki which doesn't seem to receive such negative reaction. Last but not least, how comes that Wikibase is perceived as a "third-party system" with such a negative conotation whilst MediaWiki itself is a "third-party system" in the OSM world as well? --YjM (talk) 09:36, 17 January 2020 (UTC)
Using VisualEditor is not mandatory (I am not using it), moving data into data items and removing data from wiki would force people to use data items. VisualEditor getting permanently broken would not lead to a data loss, broken wikibase would result in this (assuming that data is also not in some other location). VisualEditor getting discontinued, not supported or losing our ability to use it would not result in losing data/breaking data flow to other systems like taginfo. Losing all data from data items would be a problem if we would migrate to it. "MediaWiki itself is a "third-party system"" - my comment was about adding more dependencies. See "one more third-party system and relying on it". As far as dependencies maintenance goes Wikibase and Mediawiki is strictly more complex than Mediawiki without Wikibase. Mateusz Konieczny (talk) 10:17, 17 January 2020 (UTC)

Making editing Wiki more complex, now people need to edit in two different places

Well, what should I say... Looks like there is an approach to end this duplication, but others seem to be very keen on having all content on multiple wiki pages, one for each language together with the rest of the documentation. Suggestions?
The option of editing wiki data items directly should not have been enabled. The main human-written text of each page will require writing, maintenace and translation on every wiki page no matter what, so we should keep everything there. If you want to make users of non-English pages edit 2 different pages, then they can edit the English page + their own language page, rather than having to edit both + a data item page to make any change like "onRelation=no" --Jeisenbe (talk) 02:52, 17 January 2020 (UTC)

Wikidata item labels conflict with Openstreetmap wiki data items labels - both start with "Q"

I remember that Yurik spend quite some time on changing letter Q to Y, but this seems to be hard coded, meaning there is no configuration one could change. This issue appears in all installations of mw:Wikibase. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:39, 16 January 2020 (UTC)
That's right, the maintainers of the code for Wikibase didn't think this was important to them, since it doesn't really affect Wikidata or Wikimedia. This is one of the big risks of relying on 3rd-party code which is not optimized for our relatively tiny userbase. --Jeisenbe (talk) 02:52, 17 January 2020 (UTC)
"this change was introduced to the wiki without community consensus" - I am pretty sure that there was discussion about it, with consensus about enabling it. But maybe it should be advertised more. And there was no clear mention, or any discussion, or agreement to remove data from Wiki pages (parameters -> data items). Not sure why - maybe people proposing it thought that data items are clearly 100% superior in all aspects and that everybody will agree with it. Mateusz Konieczny (talk) 07:26, 17 January 2020 (UTC)
Yes, there was some on-wiki discussion about enabling Wikibase, plus I think some hallway-track discussions at State of the Map 2018 in Milan. To the extent that there was consensus about enabling Wikibase, it didn't come with a mandate to remove infobox parameters from wiki page sources in favor of data items. There seems to be some periodic misunderstanding about that. I suppose removing the infobox parameters could be an eventual goal. But before such a proposal could be minimally viable, we'd need to refine the data item workflows considerably. It seems clear that, regardless of the benefits to other OSM-related projects, proposals for relying on certain MediaWiki extensions will have to answer the question, "What's in it for the wiki?" It would be helpful if data item proponents could work together to implement more on-wiki functionality based on data items, especially functionality that would be infeasible with templates and modules alone, to demonstrate Wikibase's practical necessity beyond matters of principle. (For example, could infoboxes surface more nuanced relationships between tags by traversing data item properties? What about maintaining a common repository of editor presets in Wikibase, which wouldn't overlap with the wiki's existing content?) – Minh Nguyễn 💬 05:12, 20 January 2020 (UTC)

Data items missing on Polish pages

Compare Pl:Tag:wood=evergreen and Tag:wood=evergreen, only the second has "Data item" on the left menu. At least for me Mateusz Konieczny (talk) 11:26, 17 January 2020 (UTC)

FTR: It is missing in all language versions but the English one. --YjM (talk) 11:27, 18 January 2020 (UTC)
Correct, the Wikibase (code behind data items) only supports a single "sitelink" (link to a wiki page) per wiki. This works fine for Wikipedia (one language per wiki), but doesn't work well for multilingual wikis. The workaround we have is the gray pencil icon in the infobox, next to the description -- i think it is more intuitive than looking for an obscure "dataitem" menu item on the left that fewer people even notice. --Yurik (talk) 17:44, 18 January 2020 (UTC)
Actually, it seems to work adding multiple sites with the same URLs as described in mw:Manual:Sites_table#Managing_the_sites_table. I run
php maintenance/addSite.php --language=en --interwiki-id=en --pagepath='https://localhost/wiki/index.php?title=\$1' --filepath='https://localhost/wiki/\$1' myenwiki wikipedia
php maintenance/addSite.php --language=de --interwiki-id=de --pagepath='https://localhost/wiki/index.php?title=\$1' --filepath='https://localhost/wiki/\$1' mydewiki wikipedia
and running php maintenance/exportSites.php shows both “wikis” with same paths. I don’t have Wikibase installed, but MediaWiki itself doesn’t crash. —Preceding unsigned comment added by Tacsipacsi (talkcontribs)
Oh, thanks @Tacsipacsi, I haven't tried that before. If this works, it would solve many existing problems we are having with linking data items back to the pages -- at the moment I am forced to store them as properties, which is not as easy to maintain, and/or sustainable without a bot. Did you check that it actually show the "data item" link in the menu for both languages? --Yurik (talk) 19:16, 18 January 2020 (UTC)
I haven’t tried it in that depth—as I mentioned, I don’t have Wikibase installed in my local wiki. Its install doesn’t seem to be an easy go, but if you’d like, I can try it once I have a bit more time (I hope in a few weeks). —Tacsipacsi (talk) 21:55, 18 January 2020 (UTC)
Would it be possible to include the language pseudonamespace in the pagepath and filepath, to avoid potential conflicts or inconsistencies down the line? (Just spitballing here.) – Minh Nguyễn 💬 05:23, 20 January 2020 (UTC)
The filepath is the wiki root URL, i.e., where index.php, api.php etc. are, so I don’t think so (in API requests the pseudonamespace is not a prefix of the URL). Adding it only to pagepath would probably mess up things even more. —Tacsipacsi (talk) 10:26, 20 January 2020 (UTC)

problems -> limitations

@Jeisenbe thank you for working on the data items, and my hope is that your goal is to make the whole system better, so I took liberty in reworking many of your points into limitations and possible next steps on how to address them. Here are points that I removed, with the explanation. Hope we could have a productive and constructive discussion.

  • Data items were added to the wiki without community consensus
    • This is incorrect, see initial discussion (I updated the link at the top of the page, as the initial discussion was moved to an archive) --Yurik (talk) 19:00, 18 February 2020 (UTC)
      • Right, I had intended to remove that statement myself since another user said that it was discussed. But was there consensus to create the new items by bot? Was there consensus to change the ValueDescription and KeyDescription templates to pull data from Data Item pages? I think not? --Jeisenbe (talk) 12:21, 19 February 2020 (UTC)
  • Many new data items have been created by bot due to usage >10 times in Taginfo, and have no further documentation. Too many new data items are created by bot for humans to check each one.
    • That's a problem of OSM - that everyone can add tags without documenting them, and that's exactly what data items solve -- allowing for easy documentation without a complex creation of a new wiki page with templates. --Yurik (talk) 19:00, 18 February 2020 (UTC)
      • As I asked on the mailing list, why create the Data Item before it is edited by a user? Why not have it created when a user wants to add something? What is the use of a Data Item that only includes a key=value? I also think that it is best if users are encouraged to create Key: and Tag: pages to document their tags in a human-readable way first, rather than going straight to structured data items. --Jeisenbe (talk) 12:21, 19 February 2020 (UTC)
  • As a direct result of watchlist issues - quality of data in data items is significantly lower than data specified in the article text (including template parameters), because few experienced mappers are checking for edits
    • Please provide a prof first. Otherwise this sounds like FUD. --Yurik (talk) 19:00, 18 February 2020 (UTC)
      • This statement was written by Mateusz Konieczny, not by myself; he has commented below. However, my experience is that when the Data Item description differs from that on the wiki page, usually the one on the wiki page is better. But I have edited the statement to be more factual: "many experienced wiki users and mappers are not following the data item pages, so any mistakes are less likely to be fixed as quickly as mistakes on Tag and Key wiki pages." I believe this gets the meaning across without making claims about what is higher or lower quality. --Jeisenbe (talk) 12:21, 19 February 2020 (UTC)
  • Ties Openstreetmap Wiki to an additional third-party system, which adds one more part that may break and which requires maintenance.
    • Like taginfo? Actually this is the opposite of what you claim -- instead of creating extra systems, data items allow data to be strored in a structured format within the existing system. Moreover, this is already being used by iD to get documentation, rather than relying on a 3rd party buggy system (taginfo tries to parse data from wiki pages, and naturally makes mistakes because wiki pages are not structured). --Yurik (talk) 19:00, 18 February 2020 (UTC)
      • Taginfo is maintained by members of the Openstreetmap mapper / database user community, so it's not "3rd party" (maybe "2nd party?" :-) ) while in contrast Wikibase is part of Wikimedia/Wikidata, and as you know they are not responsive to requests to fix issues that affect Openstreetmap and are not going to optimise the software for us. But yes, it is "and additional third-party system", on top of Visual Editor, WikiEditor and a few other minor extensions. Unlike those, which mainly make it easier to edit the wiki or make things like citations display nicely, adopting Data Items for storing information would be a major change to how information is stored and managed, when previously it was all in plain text in each Tag/Key page. If something goes wrong it will be more significant. --Jeisenbe (talk) 12:21, 19 February 2020 (UTC)
  • Some users now wish to delete the ValueDescription and KeyDescription templates from Tag and Key wiki pages so that the info in the box will be pulled in from the Data Items, but this means that the wiki page no longer has the complete tag information.
    • you are confusing wiki page and wiki markup. Wiki PAGE will continue having all the information. Wiki markup never had "complete" information because it relies on templates, which are separate pages - just like data items. --Yurik (talk) 19:00, 18 February 2020 (UTC)
      • "Wiki PAGE will continue having all the information." untrue, it would be lost and migrated to opaque data items system. Maybe you meant rendered HTML page, build from Wiki page, images and sometimes sadly also data items? "Wiki markup never had "complete" information because it relies on templates" - good templates are limited to formatting, rather than pulling data from external systems. (and yes, images are stores separately - but before data items any other data/information was in article text and I want to preserve this state) Mateusz Konieczny (talk) 18:00, 8 May 2020 (UTC)
  • Enabling the Data Items and Wikibase softward has tied the Openstreetmap Wiki to an additional third-party system which may break and require maintenance in the future. Since the software was created by Wikidata and Wikimedia, it is not optimised for the unique issues of the Openstreetmap community.
    • The same argument can be made about the whole OSM wiki - see Special:Version -- every single extension, plus the MediaWiki software itself were not created for OSM.

--Yurik (talk) 19:00, 18 February 2020 (UTC)

      • Which Tag and Key pages rely on separate templates? Are you talking about Key pages that have taglists, or Map Features pages which have templates? The great majority of "Tag:" and "Key:" pages don't have any external template, and the ValueDescription / KeyDescription section is included directly in the source text, so the wiki markup includes all of the information. If users delete these templates and expect the server to pull info from the data items, users will still see a box with the description and onWay, onArea, Image, seeAlso etc., but won't know if they can edit it in the page, or if they have to link to the Data Item, until they try to edit the page source. This is a big pain when you are on a flaky or slow internet connection. I strongly prefer not to have to edit a separate data item every time I edit a Tag page, and I want to be able to do it all in plain text. (I wrote this all in plain text, twice, and it took me 3 tries to get it to submit, due to my lousy connection tonight) --Jeisenbe (talk) 12:21, 19 February 2020 (UTC)
      • "Please provide a prof first. Otherwise this sounds like FUD." - is there some list of differences between what is specified in the templates and what is in data items? Mateusz Konieczny (talk) 10:54, 19 February 2020 (UTC)

Link to proposal instead of to non-existent Tag/Key page or redirect page

Currently every Data Item appears to have a link in the upper right corner to a wiki page in the format Tag:key=value or Key:key, but this is the case even if there is no page yet. Many data items were created from page in the Proposed_features space.

Would it be possible to always create a link to the proposal automatically when these data items are created? Would it be possible to use this for the link in the upper right corner? I see this has been done in a few places, but not for tags like https://wiki.openstreetmap.org/wiki/Item:Q17204 which ought to link to Proposed features/Tag:footway=link

Similarly, would it be possible to link to the redirect, when a data item is created from a page which has a redirect only?

When there is no page yet, I don't think that new data items should be created, but if this happens, could the upper right hand corner link be in the format https://wiki.openstreetmap.org/w/index.php?title=Tag:key%3Dvalue&action=edit so that it is clearly a non-existent page? --Jeisenbe (talk) 12:48, 19 February 2020 (UTC)

Create more useful comments for Yurikbot edits

Currently, it appears that Yurikbot edits always have a comment like "Created a new Item: Auto-updating from Wiki pages" no matter if the tag is created from usage in Taginfo or from an actual Key: or Tag: or Proposal page. Could these comments be made more useful by saying "Created a new item: Added due to ## uses in Taginfo", or "Created a new item: Added due to mention at Proposed_features/***" or ""Created a new item: Added due to documentation at Tag:key=value" or similar?

Better yet, used the rest of the comment to show the description, e.g. "Created a new item from Proposed_features/*** with description 'An area used for headstands'..." etc.

When a Data Item is updated, Yurikbot always comments "Cleared an Item: Auto-updating from Wiki pages". This doesn't provide any info, and "cleared" is too similar to "created" at first glance. Can this be changed to "Updated an Item: edited property X and Y which was changed at Tag:key=value" or something like this, so that we can see what was actually changed. E.g. if the description changes, have this written in the comment, and include the new text of the description, if it fits. --Jeisenbe (talk) 12:57, 19 February 2020 (UTC)

User template to show appreciation of data items

I’ve created a user page template {{Support data items}} for mappers who appreciate the data items.--Andrew (talk) 16:16, 23 February 2020 (UTC)

Labels

@Yurik and others: Two editors (one of them new) have changed English labels of data items from the key to a descripitive word or phraseover the past 24 hours. How should they be responded to? --Andrew (talk) 13:44, 8 May 2020 (UTC)

Can you link them? If edits are clearly wrong then reverting such edits is typically a good idea Mateusz Konieczny (talk) 17:11, 8 May 2020 (UTC)

I guess Special:Contributions/Fanfouer is one of the intended. --Chris2map (talk) 17:42, 8 May 2020 (UTC)

Looking at Data items it has "Label usage is still a bit undecided for the key/tag data items, so it is best not to use it for anything.", so probably people that use/edit data items should discuss it, or document consensus if there is support for a specific form. I reverted two edits in Polish labels that produced an absurd gibberish. Mateusz Konieczny (talk) 17:56, 8 May 2020 (UTC)

P36 dropdown misbehaving and confusing

Why dropdown has No, no, NOME, NOMBRE, NO_SITE etc? How one may fix this? Which one is correct? "no"? Mateusz Konieczny (talk) 12:11, 8 June 2020 (UTC)

NOMBRE, NOME, No... are used keys according to taginfo, thus they are listed because they each has a data item associated. I suspect they are errors and that in most of the case another wellknown tag can be used (for instance NOMBRE, which means 'name' in spanish, seems to be used for street or place names). I don't know if there is a way to say that a given data item is probably a misused of another data item. Hope this helps. LeTopographeFou (talk) 12:15, 8 June 2020 (UTC)
@Mateusz Konieczny Which dropdown? Where? When? I can't see any of the terms listed on the P36 property page, so what exactly are you addressing? --YjM (talk) 12:26, 8 June 2020 (UTC)
How to see this dropdown for property P36 ?
--Pyrog (talk) 12:31, 8 June 2020 (UTC)
@YjM https://wiki.openstreetmap.org/wiki/Item:Q19460 representing Tag:amenity=hydrant from Category:Mismatched onRelation. I wanted to add "use on relations" property so I clicked on "add statement", filled left box with "use on relations", selected sole matching dropdown value and clicked on right one. For some reason no dropdown appeared so I started to type "n" and got ridiculous/unclear values in dropdown.
Ok, I understand now :)
I don't know if we could specify the valid values, and specify that they should be displayed in a list.
--Pyrog (talk) 12:46, 8 June 2020 (UTC)
Giving example/usage instructions on https://wiki.openstreetmap.org/wiki/Property:P36 would be a good first step, but I have no idea how can I do this Mateusz Konieczny (talk) 12:48, 8 June 2020 (UTC)
It seem that this "issue" is not specific to P36 (try to add "use on nodes", "use on ways"…).
--Pyrog (talk) 12:51, 8 June 2020 (UTC)
Yes it is not specific to P36. We are talking about a way to differenciate data items relative to OSM keys to other data items which are not OSM keys. Maybe there is a way to categorize data items into two groups (OSM tags and others) and say that this property accepts values from this and/or that group only?LeTopographeFou (talk) 13:08, 8 June 2020 (UTC)
I tested this in wikidata. For example change the country for phare du Créac'h.
Same issue ;)
In wikidata, it possible to add forms to easily edit items (javascript or plugins).
Is it possible to do this in DataItems, and better provide checkboxes, radio buttons or dropdown lists by default ?
--Pyrog (talk) 13:15, 8 June 2020 (UTC)
See Help:Property constraints portal/Entity suggestions from constraint definitions
--Pyrog (talk) 13:39, 8 June 2020 (UTC)
See this form User:MichaelSchoenitzer/quickpresets took from this discussion in french.
--Pyrog (talk) 14:04, 8 June 2020 (UTC)
Would be great to have radio buttons for that boolean properties, otherwise predefined values yes and no. --Chris2map (talk) 18:14, 8 June 2020 (UTC)
You can try using the options under “Edit data item” in the sidebar. You have to go to the English or data items page first. --Andrew (talk) 20:42, 8 June 2020 (UTC)
I needed to go to preferences, tab gadgets to enable it. And on the first attempt to use it I managed to trigger "Lua error in Module:DescriptionFromDataItem at line 213: attempt to index local 'datavalue' (a nil value)." after selecting "no value" in dropdown as apparently it was "empty value", not "set no". How one is supposed to use this editor to set usage by object type? Because manually typing value "no" has exactly the same dropdown issues. Though interface is not laggy jumpy forever loading mess, so it is a big improvement Mateusz Konieczny (talk) 23:39, 8 June 2020 (UTC)

Category for items without a linked Wikidata ID

@Yurik it would be useful to have a category of pages that are not connected to a Wikidata item. I'd like to work on shortening that list. Can we do it? Pizzaiolo (talk) 00:50, 16 July 2020 (UTC)

You could create a SPARQL query to find all data items that do not have a specific property. --Yurik (talk) 00:52, 16 July 2020 (UTC)
@Pizzaiolo - something like this: Find 10 keys that do not have wikidata concept (click blue "play" button) --Yurik (talk) 02:34, 16 July 2020 (UTC)
Thanks! Huh, 13849 results in total... Pizzaiolo (talk) 02:38, 16 July 2020 (UTC)
@Pizzaiolo that's just the keys. If you change P16 to P19, you will see tags (and there is a way to get relations, relation roles, etc) --Yurik (talk) 02:41, 16 July 2020 (UTC)
@Yurik is it possible to sort them by taginfo usage? Pizzaiolo (talk) 02:50, 16 July 2020 (UTC)
I don't think I added that info to Sophox. It could be done because in the sophox bot I import taginfo DB. --Yurik (talk) 03:50, 16 July 2020 (UTC)
@Yurik That would be extremely useful! Pizzaiolo (talk) 04:33, 16 July 2020 (UTC)
@Yurik I was thinking of turning this list into a mix'n'match catalog, to make things easier. Then a bot could just check Wikidata periodically to reciprocate the linking from there to here and from here to there. One thing I'd need in the query above would be returning the relevant wiki page titles, too, in the order stipulated here. Is that possible? Pizzaiolo (talk) 02:52, 9 August 2020 (UTC)
@Pizzaiolo You can use osmm:key instead of the P16 as it links to the Key page. --CamelCaseNick (talk) 20:12, 13 August 2020 (UTC)
@CamelCaseNick Thanks. Within that query, how can I also fetch the data item labels in English? Pizzaiolo (talk) 13:59, 15 August 2020 (UTC)
Well, you can still include the P16 output if you need to, or use the labeling service (see wikidata docs). The P16 is probably better though. --Yurik (talk) 14:24, 15 August 2020 (UTC)
@Pizzaiolo Oh, and beware that 862 keys in the data items don't have the osmm:key (https://tinyurl.com/y4xeyolg). --CamelCaseNick (talk) 17:42, 15 August 2020 (UTC)
@CamelCaseNick By the way, an alternative to osmm:key is schema:about, which works in the other direction for both keys and tags, as long as there's a wiki page about the key or tag. But for the query above, it should be enough to look for instance of (P2) key (Q7). – Minh Nguyễn 💬 22:47, 11 September 2020 (UTC)

access restriction defaults

I think it would be beneficial to have the data at OSM_tags_for_routing/Access_restrictions in the respective highway=* tags data items for that using P45 and for the country specific deviations with a P48 qualifier. Is it possible to do this here in a semi-automatic manner (i.e. not fully manually going through the Special:NewItem process for each region and adding snaks and qualifiers in the web interface), more like a workflow with QuickStatements or OpenRefine? And would it indeed be a good idea to have those implies statements there? -- CamelCaseNick (talk) 20:51, 8 August 2020 (UTC)

Item creation process

The subtitle Data_items#Item_creation_process says the bot did create data items for all tags which have 1000+ usages. So i wonder a bit why there is no data item available for tag toll=yes, click wiki search? There is an amount of usage of quite 300k, see toll=yes

--MalgiK (talk) 19:04, 23 August 2020 (UTC)

Yurikbot seems to have stopped running in June. Not sure if this is the reason that the item for toll=yes was never created, but it probably does account for other missing data items. Yurik, does the bot just need to be restarted, or is there another reason why it stopped running? – Minh Nguyễn 💬 22:39, 11 September 2020 (UTC)
Thanks for response. Yes, the log of user:Yurikbot shows, that the bot isn't continuous running over all. Looks like only some batches which were manually triggered. Furthermore the toll=yes reached 1000+ items app. in 2009 (https://taghistory.raifer.tech/#***/toll/yes) and in June 2020 there was a amount of 200k+. Seems more like a general bot bug. --MalgiK (talk) 18:17, 12 September 2020 (UTC)

Known Bad Tags

Would it be a good idea to have a suggested replacement for known bad tags?

For example, https://wiki.openstreetmap.org/wiki/Item:Q18785 and https://wiki.openstreetmap.org/wiki/Item:Q16174 -- the first is `surface=paved2` and the second is `surface=paved`. `paved2` is (obviously) a typo to a human, but it can be difficult to detect programmatically.

I've gone ahead and given the `surface=paved2` a rejected status for now, although it (really) isn't the best solution, and I would prefer to point to Q16174 from Q18785 as a "correct" tag.Vorpalblade77-kaart (talk) 19:56, 22 September 2020 (UTC)

Never mind. I just saw P17 (redirect to).

WEF: tag ("edit data item" tool) fails on translation pages

I just tried on https://wiki.openstreetmap.org/wiki/Pl:Tag:amenity%3Dcustoms Mateusz Konieczny (talk) 08:22, 10 October 2020 (UTC)

WEF: tag ("edit data item" tool) is missing necessary dropdowns

I wanted to change whatever usage is allowed/incorrect on area/node/way and necessary fields were missing in dropdown Mateusz Konieczny (talk) 08:24, 10 October 2020 (UTC)

Popup to select an image

The popup to select a image is missing.

Example: data item Q10198 and wikidata element Q3008463

--Pyrog (talk) 06:27, 12 October 2020 (UTC)

Constraints (or validation rules)

How to add constaints to OSM keys and tags ?

Currently, it seem that there is only value validation regex (P13).

  • Does it used by any OSM editor or any OSM QA tool ?

Examples of constraints

Mandatory keys for sub keys

ref:FR:FINESS=* must be only used with the following main keys or tags :

Values format

ref:FR:FINESS=* must be respect the following format \d{9}
It should be described with value validation regex (P13).

Mandatory values

For emergency=defibrillator, the key indoor=* must have one of the following values :

Multiples values

  • Does a key could have multiples values separated by ;
  • Does a value must be one constrainst ? See Mandatory values above.
  • Does a value is free but could be selected in a list of well-known values (Q8) ?

--Pyrog (talk) 07:47, 24 October 2020 (UTC)

"Does it used by any OSM editor or any OSM QA tool ?" AFAIK no, and I would not expect this to happen. Mateusz Konieczny (talk) 15:25, 24 October 2020 (UTC)
Currently editors or QA tools use validation rules in MapCSS…
But I'am not sure that all tools share the same rules.
The wiki display more or less some.

The OSM formatter URL (P8) and Wikidata formatter URL (P1630) are used (at least by JOSM).

So DataItems seem a good place to store this knowledge about OSM keys and tags.
--Pyrog (talk) 16:19, 24 October 2020 (UTC)

I'm currently using WikiData for a QA check I'm writing. I'm also probably going to see about autogenerating mapcss rules based off of it at some point. Before that happens, I'm probably going to need to set up some kind of CI for it (so I can look for issues with changed/modified regexes, e.g. `https?:\/\/[a-zA-Z0-9]+\/?[.*]` for websites). I don't think the QA check is going to have public tasks for awhile, just so that I can have people fix/update wiki items (I've noticed some issues). @Mateusz, why do you not expect it to be used by any OSM editor/OSM QA tool? I might need to readjust my expectations depending upon your reasoning. Vorpalblade77-kaart (talk) 14:37, 26 October 2020 (UTC)