Talk:Data items

Item creation

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: 50694394 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)

Item creation by hand

The creation of a new data item should start with verification that there is no existing data item for the feature, key or tag by searching for one.

You can search for a data item by these two ways, I use both in following order:

1. Wiki search in namespace "Item" only - (Enter key or tag without "Key:..." or "Tag:..."). - If there is no result or the results don't match exactly to the key or tag you searched for, go on with the special page item search:
2. Special:ItemByTitle/wiki/ - (It is essential to put in exact notation of the key or tag there, so you have to include the namespace "Key:..." or "Tag:...". In the first row leave the preselected entry "wiki" for website). - If there is no result it will offer a link to create the new data item:

Following that link you get an input mask with 4 editable rows, where you have to select ...

• Language for the entries of the following rows (select "en" English)
• Label - should be the exact notation of the key or tag (the same you entered on previous page, without namespace Key: or Tag:)
• Description - could be filled in here or left empty for specifying later
• Aliasses - could be filled in here or left empty for specifying later

-- Chris2map (talk) 20:28, 2 May 2021 (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  (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  (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 )

• see https://taginfo.openstreetmap.org/projects/wikidata_org#overview
• JSON: http://tools.wmflabs.org/wp-world/wikidata/tags.php

Some are linked to the wikidata P value! examples:

• {"key":"voltage", "doc_url":"http://www.wikidata.org/entity/P2436"}
• {"key":"opening_hours","doc_url":"http://www.wikidata.org/entity/P3028"},
• {"key":"facebook","doc_url":"http://www.wikidata.org/entity/P2013"}
• {"key":"ref:rce","doc_url":"http://www.wikidata.org/entity/P359"} on the wikidata side: Has a regular expression + website url info for linking. imho: it is useful info!
• {"key":"ref:isil","doc_url":"http://www.wikidata.org/entity/P791"}
• {"key":"nist:fips_code","doc_url":"http://www.wikidata.org/entity/P882"}
  • format as a regular expression: "\d{5}"
  • formatter URL : http://www.census.gov/quickfacts/table/PST045215/$1,00

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

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)

What are the plans for P4 deletion? Mateusz Konieczny (talk) 17:24, 10 December 2020 (UTC)

For the record, the only data item that has P4 is https://wiki.openstreetmap.org/wiki/Item:Q890, which also has the same information in P28. Vorpalblade77-kaart (talk) 17:32, 10 December 2020 (UTC)

Now Q890 is also clean Mateusz Konieczny (talk) 18:10, 10 December 2020 (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)

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)

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

Currently we have the following secondary Wikidata tags widely used:

• operator:wikidata=*
• network:wikidata=*
• brand:wikidata=*
• architect:wikidata=*
• artist:wikidata=*
• species:wikidata=*
• subject:wikidata=*
• name:etymology:wikidata=*

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

Note that such bot edit should be discussed, not just run based on this hidden discussion Mateusz Konieczny (talk) 17:26, 10 December 2020 (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)

+1 --Pyrog (talk) 09:17, 8 November 2020 (UTC)

-1

I don't thing we need Q data-item pages for tags for which no wiki pages exist. Item:Q18779 is a perfect example of a miss-tagging of probably surface=asphalt. Instead i would recommend to align the threshold amount of the bot (which is even not running continuously) to a lower amount. Btw. what is the current number of tag items which are needed that the bot will create a new Q data-item? Were the bot parameters ever discussed on an mailing list or a forum? Link? --MalgiK (talk) 06:51, 9 November 2020 (UTC)

Add link to overpass on data item page

Like taginfo, add also a link to OverpassTurbo. --Pyrog (talk) 09:20, 8 November 2020 (UTC)

Adding values for P6

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

• undefined (ex. https://wiki.openstreetmap.org/wiki/Item:Q266 )
• canceled (https://wiki.openstreetmap.org/wiki/Category:Proposals_with_%22Canceled%22_status)

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

"cancelled" is status of a proposal, not of a tag.

"undefined" is achieved by not adding status, right?

Mateusz Konieczny (talk) 17:28, 10 December 2020 (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)

I would consider it as a mistake and delete such image properties Mateusz Konieczny (talk) 17:29, 10 December 2020 (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  (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  (Let's talk) 21:48, 26 November 2019 (UTC)

@Yurik:? --Tigerfell  (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)

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  (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 (talk • contribs)

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)

list of differences between OSM Wiki and data items

I created a script that can list such differences and started to work through them. It works only partially (parsing complex data item values such as lists is NOT implemented). Is someone interested in such output? It can list cases where data item is used instead of infobox value and where simple data item value is not matching infobox value Mateusz Konieczny (talk) 17:33, 10 December 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)

The topic "labels" is still an unfinished hot potato for me! Especially since iD uses data items and offers a link for editing. In my opinion, users are quickly tempted to fill in the label in their own language. In the current system, I don't think this is desirable for keys and tags. To alleviate the problem, I would very much appreciate it if on the item page for keys and tags the "label" field for languages other than English is no longer displayed at all. I would be happy if someone could implement this in a timely manner! -- Best regards, Chris2map (talk) 11:41, 10 April 2021 (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)

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 :

• healthcare=*
• social_facility=*
• Only some amenities :
  • amenity=dentist
  • amenity=doctors
  • …

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 :

• indoor=yes
• indoor=no

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)

@Vorpalblade77: "@Mateusz, why do you not expect it to be used by any OSM editor/OSM QA tool?" - in general QA rules are quite carefully written and authors of programs take responsibility for them. Many of them are quite complex. Also JOSM, Osmose, Vespucci, iD authors put quite significant effort in making their QA working well. In comparison Wikidata item validatation rules is no very capable, with much smaller coverage, harder to edit, not controlled/watched by anyone. Using this would require more effort for little to no gain. And for a new QA editor it makes more sense to import JOSM rules (like Osmose did) or ones from Osmose/iD

If someone decides to take validation rules from data items instead note that you should review any changes on importMateusz Konieczny (talk) 06:47, 5 November 2020 (UTC)

Thanks for the explanation. I had been planning on writing unit tests for anything with a value validation regex initially, and expanding from there.

@Mateusz Konieczny: "In comparison Wikidata item validatation rules is no very capable, with much smaller coverage, harder to edit…"

What is your source to assert this ?

--Pyrog (talk) 09:50, 8 November 2020 (UTC)

See say https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator for example https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/religion.mapcss Note that checks include

• Explanation what is wrong with data if test fails
• assertMatch/assertNoMatch tests allowing to verify that rules are working as specified, making their editing easier

Or see https://josm.openstreetmap.de/browser/josm/trunk/resources/data/validator/highway.mapcss with tests such as

[highway=footway][maxspeed] detecting unusual combinations

Support for things such as "do not trigger this rule if already one of the 4 previous rules applied"

Sane syntax without troublesome repetition [highway=crossing][barrier=kerb].is_in_major_road

As far as I know all that features are missing from data items and there is no good way to specify it. And even if there would be such way I am dubious whatever editing it would be easier than editing JOSM rulesets (especially as text based syntax can be sanely handled in git repository and so on).

If someone wants to spend effort on recreating such system, it may be possible to do but I am dubious is it going to be either more useful or easier to edit or with a better coverage Mateusz Konieczny (talk) 16:41, 8 November 2020 (UTC)

@Pyrog and Mateusz Konieczny: Wikibase has a companion extension, mw:Extension:WikibaseQualityConstraints, that apparently isn't installed here yet. Wikidata has the extension installed; it's what powers the icons there. The system is less powerful than what one could possibly write by hand in a custom validator, but it has the advantage of running automatically as soon as you edit an item or property and notifying you about any issue immediately. It's even possible to block edits that violate certain rules. I don't think this system is comparable to the JOSM validator: one validates the OSM database, while the other validates the wiki's metadatabase about the OSM database. A better comparison would be to the schema validator in schema-builder, which goes mostly unnoticed by mappers; by comparison, WikibaseQualityConstraints would be more useful because mappers can easily edit data items at will. – Minh Nguyễn ^💬 19:06, 19 May 2023 (UTC)

How data items data may be downloaded?

"able to get tag information without complex and error-prone parsing of the wiki markup" is mentioned in header, but section about actually getting data (SOPHOX?, link to data dumps?) would be nice. Right now I want to process data items (all of them) and I am looking for way to download all relevant data Mateusz Konieczny (talk) 06:50, 5 November 2020 (UTC)

Program demonstrating how to download and use data items for specific OSM tags also would be cool. For now I tried User:Yurikbot source code but it is definitely not some easy task to even find where this code is fetching data from Data Items and/or Wiki pages Mateusz Konieczny (talk) 07:15, 5 November 2020 (UTC)

I asked now also on OpenStreetMap dev Telegram channel Mateusz Konieczny (talk) 07:21, 5 November 2020 (UTC)

@Mateusz Konieczny: I wrote a script to do exactly this. See https://github.com/osmlab/atlas-checks/pull/357/files#diff-ee5e07fb784e146cdf755807a977157d503f7831af09f9bd668a5ae971469b1d (I'm going to have to add a method to do unit testing on specific items, like the value validation regex). It takes awhile, since I was trying to avoid overloading the Wiki servers, but it does get the job done.

This seems to download taginfo ( https://taginfo.openstreetmap.org/download/taginfo-db.db.bz2 ) not from Data Items @Vorpalblade77-kaart: Mateusz Konieczny (talk) 09:42, 9 November 2020 (UTC)

@Mateusz Konieczny: Oops. Looks like I forgot to commit it. Fixed (along with the link).Vorpalblade77-kaart (talk) 14:16, 9 November 2020 (UTC)

@Vorpalblade77-kaart: Thanks! Is there any way to download info for a specific tag, without downloading all pages for wikidata items? Mateusz Konieczny (talk) 22:54, 7 December 2020 (UTC)

I answered this down below in "complex and error-prone parsing of the wiki markup", but here is a link to the section in the page that I used: https://wiki.openstreetmap.org/wiki/Data_items#API_access_and_querying . I did not write that script with an eye to only downloading one item, unfortunately. Vorpalblade77-kaart (talk) 23:32, 7 December 2020 (UTC)

Thanks! Mixing this into code will be a bit ugly, but it will work, thank you! And sorry for missing it... Mateusz Konieczny (talk) 09:02, 8 December 2020 (UTC)

Creating presets

I'd like us to start working on presets. I've created the first one at Q21415, based on the existence of a similar one at iD. Right now not much can be added because we need more properties, and we should probably discuss which properties we will need. Is @Yurik the only property creator? Pizzaiolo (talk) 03:10, 8 November 2020 (UTC)

@Pizzaiolo: I'm a data administrator now, so I can create properties too. However, this would be a rather complex project. Perhaps you could start a proposal in the Proposal: namespace about what you'd like a preset item to look like? Then we could figure out how these items should coexist with the schema-builder and id-tagging-schema projects, which have grown quite sophisticated and well-used over the past couple years. – Minh Nguyễn ^💬 18:21, 19 May 2023 (UTC)

"complex and error-prone parsing of the wiki markup"

Introduction has claim about "complex and error-prone parsing of the wiki markup".

Can anyone demonstrate getting information from data item that is simpler than getting values from infobox for a given tag?

For example: given landuse=forest answer whatever it is a valid tag on unclosed way.

I just wasted one hour just on trying to get id of data item given key or key+value pair and failed for now, with https://phabricator.wikimedia.org/T269635 as sole outcome. So this claim about simplicity seems untrue to me, and I am starting to consider removing it.

Mateusz Konieczny (talk) 22:53, 7 December 2020 (UTC)

If you are directly querying the Wiki, use https://wiki.openstreetmap.org/w/api.php?action=wbgetentities&sites=wiki&titles=Tag:landuse=forest&format=json . From each dict entry, you can use the `id` key to get the id. You may want to append &languages=en to remove extraneous languages (change the `en` to the appropriate two letter code, but you may just want to append |language_code). Otherwise, I've got a database that I can send you that I generated from scraping wiki data. It is very basic, but it works for what I need. Vorpalblade77-kaart (talk) 23:03, 7 December 2020 (UTC)

> Introduction has claim about "complex and error-prone parsing of the wiki markup".

I can't find this sentence. Does somebody add deleted it?

--Pyrog (talk) 08:10, 8 December 2020 (UTC)

"Tools, such as iD editor and Taginfo are now able to get tag information without complex and error-prone parsing of the wiki markup." (the second line of a page) Mateusz Konieczny (talk) 08:32, 8 December 2020 (UTC)

> I just wasted one hour just on trying to get id of data item given key or key+value pair and failed for now

With a SPARQL query this is quite simple. Unfortunately the SPARQL endpoint (aka Sophox) is down.

--Pyrog (talk) 08:10, 8 December 2020 (UTC)

Well, obviously I am interesting in something that works. And setting up my own SPARQL server is definitely more complex that anything wiki based. And as demonstrated, centralized server has its problems - far worse that using a parsing library Mateusz Konieczny (talk) 08:34, 8 December 2020 (UTC)

Here is code extracting text from specific tag (via template at wiki page): https://github.com/matkoniecz/data_item_spillover_cleanup/blob/master/template_extractor.py

Here is code extracting text from data item: https://github.com/matkoniecz/data_item_spillover_cleanup/blob/master/data_item_extractor.py

Note that data item extraction is not finished at all and for many cases it is capable of detecting that there is some data, not of extracting any data. Note that if for some reason you would want to extract machine readable tag lists (in say seeAlso) the code for templates would become far more complicated. But for now claim about "complex and error-prone parsing of the wiki markup" seems false, as long as you use dedicated parser (what OBVIOUSLY should be done) Mateusz Konieczny (talk) 11:35, 9 December 2020 (UTC)

@Mateusz Konieczny: I corrected the article's instructions for dumping an item's data and also added instructions for using Special:EntityData, which may be more straightforward for some needs. – Minh Nguyễn ^💬 18:51, 19 May 2023 (UTC)

Prohibited/allowed

I would propose to change "is allowed" "is prohibited" on https://wiki.openstreetmap.org/wiki/Property:P33 https://wiki.openstreetmap.org/wiki/Property:P34 https://wiki.openstreetmap.org/wiki/Property:P35 https://wiki.openstreetmap.org/wiki/Property:P36 This language is too strong, Data items like OSM Wiki have advisory role, it is not something that must be obeyed by mappers Mateusz Konieczny (talk) 19:22, 9 April 2021 (UTC)

Do you think of renaming Item:Q8000 and Item:Q8001? Something like "is common" instead of "is allowed", and "is unusual" instead of "is prohibited"? Chris2map (talk) 19:42, 9 April 2021 (UTC)

Yes, exactly! Thanks for good names, I had no ideas here. Mateusz Konieczny (talk) 20:25, 9 April 2021 (UTC)

wiki used "may be on" and "should not be on". I have nothing against changing the wording of the wiki and dataitems but it is not a good idea to have nuances of wording between 2 tools that are supposed to present the same information. Marc marc (talk) 12:49, 12 April 2021 (UTC)

statement that "Taginfo is now able to get tag information by parsing data items instead of parsing the wiki markup"

true ? a random example shop=erotic
the wiki page doesn't have a description in french
the data item have a description in french
taginfo don't show the description in french Marc marc (talk) 12:41, 12 April 2021 (UTC)

Tools like Taginfo are able to do this, but Taginfo is not using data items. Similarly, iD (from what I remember) ignores OSM Wiki and is using solely data items Mateusz Konieczny (talk) 16:12, 12 April 2021 (UTC)

British vs American / US English

Please clarify in the documentation what language "en" / "English" means in the data items; British English or American / US English? Data items have additional fields for British English but not for American / US English. Some tools (especially editors) support different localizations. iD seems to interpret the "en" / "English" values as American / US English, but {{ValueDescription}} seems to interpret them as British English. What is the correct place for descriptions in American / US English in the data items (if they differ from British English, e.g. "center" instead of "centre")? I think "en" / "English" should be used for American / US English and the British descriptions should be put into the fields for "British English" (if they differ); I think it is usual like that; but it was disputed ->here --Hufkratzer (talk) 15:04, 13 October 2021 (UTC)

Related iD-discussion: [1] --Hufkratzer (talk) 14:30, 18 January 2022 (UTC)

The choice of languages and dialects in the data items is the list supported by Mediawiki. At the moment the items only use “English” unqualified for English in general but that could be changed. --Andrew (talk) 18:40, 18 January 2022 (UTC)

@Hufkratzer: Like much software, MediaWiki uses en as the language code for American English when determining the interface language, with en-gb representing British English. However, Wikibase maintains a separate list of languages to be used as label/description/alias languages, and yet another separate list of languages for any statement whose property has the data type "monolingual text", such as documentation wiki pages (P31); both these lists include both en-gb and en-us. This means en can be a compromise "universal English" – not that such a thing exists, but it's consistent with other language such as Spanish. – Minh Nguyễn ^💬 18:15, 19 May 2023 (UTC)

In my list of languages shown on Special:Preferences only "en", "en-GB" and "en-CA" are available, no "en-US" (also no "es-ES" or "de-DE", only "es", "es-x-formal", "de", "de-AT", "de-CH" and "de-x-formal"). I don't see any way to enter a description in US English. If descriptions in US English can't be entered, iD can't show them. What needs to be done? --Hufkratzer (talk) 00:02, 25 May 2023 (UTC)

@Hufkratzer: Correct, MediaWiki follows the industry practice of using an unqualified language code to represent a particular country's dialect of the language, ensuring some kind of fallback regardless of the browser's settings. Meanwhile, Wikibase follows a more academic practice of using the unqualified language code to represent the language as a whole, which means the user must specify a country code if they want a particular dialect. Thus, MediaWiki considers the code for American English to be en, while Wikibase considers it to be en-us.

The default list of label languages in Wikibase is primarily determined by the babel template on your user page, falling back to your interface language. You can always click "All entered languages" to reveal every language that has a label/description/alias for the item, or manually enter an language code into Special:SetLabelDescriptionAliases to see the information in that language.

However, en-us seems to be broken somehow. Wikibase recognizes it as a valid language code and lists its information, for example in colour (Q163), but doesn't know its name (try putting {{#language:en-us}} into Special:ExpandTemplates). Even though User:Minh Nguyen has a babel template that includes en-us, it only shows up by default if I manually set the interface language to American English by adding ?uselang=en-us to the URL. I suspect it's an issue with this wiki's configuration, because Wikidata and other wikis seem to have no problem recognizing American English.

Given these issues, it's probably not worth fussing with the en-us code; just put the American English in en for better interoperability with the software that would use data items. If infoboxes should prefer British English when pulling descriptions out of data items, then Module:DescriptionFromDataItem can be adjusted accordingly.

 – Minh Nguyễn ^💬 04:34, 25 May 2023 (UTC)

Category:Mismatched image

Unresolved

See Category talk:Mismatched image. maro21 17:48, 3 December 2021 (UTC)

The same story with Category:Mismatched osmcarto-rendering. maro21 20:31, 18 January 2022 (UTC)

It is in Module:DescriptionFromDataItem row 408, as far as I can spot it. --Chris2map (talk) 21:09, 18 January 2022 (UTC)

Properties for start and end dates of tag status

Hi, as Wikidata offers properties for start and end date (https://www.wikidata.org/wiki/Property:P580 and https://www.wikidata.org/wiki/Property:P582), maybe it could make sense to have such properties on OSM Data items, in particular to reference start/end dates of a tag status (like "this tag is deprecated since 01/01/2020"). Main use case being having a clear overview of deprecated tags and for how long they are deprecated. What is the process to create these properties ? Can someone with appropriate rights do it (or give me permission to do so) ? Best regards. --PanierAvide (talk) 20:49, 20 January 2022 (UTC)

Hi, I support this requestː this is much needed if we want to keep track of the evolution of the status over time. --Overflorian (talk) 08:34, 21 January 2022 (UTC)

I also support this. It could also be used with replaced by (P17) for deprecated items or possibly OSM Carto image (P39). --Henry572 (talk) 21:38, 18 January 2024 (UTC)

Data Items are removed from the wiki  ???

The Wikibase/EntityData extension seem removed, so it's impossible to edit/view any Data Items.

For example http://wiki.openstreetmap.org/entity/Q335 corresponding to key highway is missing.
Same for http://wiki.openstreetmap.org/Special:EntityData/Q335 or http://wiki.openstreetmap.org/Special:EntityData?id=Q335.

Note: Data Items are still searchable with Sophox : https://tinyurl.com/y5utlxbu

--Pyrog (talk) 09:25, 27 April 2022 (UTC)

https://github.com/openstreetmap/operations/issues/611 --Pyrog (talk) 10:25, 27 April 2022 (UTC)

Resolved: Mateusz Konieczny (talk) 09:23, 11 September 2022 (UTC)

Correcting permanent tag ID

@Yurik: I entered the wrong permanent tag ID for aeroway=aircraft_crossing (Q21977). How do I fix it? Andrew (talk) 07:04, 14 June 2022 (UTC)

You could cheat by adding one more P19 with the correct data and after that (when there exist two entries for P19) you can delete the first one. And also https://wiki.openstreetmap.org/wiki/Special:SetSiteLink/Q21977/wiki should be fixed. --Chris2map (talk) 20:05, 14 June 2022 (UTC)

Definition of Q6 (relation)

Please follow on Item talk:Q6. --Chris2map (talk) 10:23, 26 June 2022 (UTC)

Check for documentation pages

How can I check for misspelt names of documentation pages? Andrew (talk) 19:06, 24 July 2022 (UTC)

New data items "key prefix" and "key suffix"

As per Proposal:Documentation of key prefixes & suffixes I created the two new data items

• Item:Q22020 key prefix
• Item:Q22021 key suffix

to be used with Property:P2 instance of. – Where should we place this on the Data items page? --Chris2map (talk) 21:01, 8 August 2022 (UTC)

Recently added: prefixes and suffixes to Tag keys / instance of / Item / keys. --Chris2map (talk) 15:38, 5 February 2023 (UTC)

Languages not supported by Mediawiki

Unresolved

@Yurik: There are now documentation pages in Guadeloupe creole (Gcf:) [2]; however documentation wiki pages (P31) cannot be set in that language because Mediawiki doesn’t know about it. Andrew (talk) 18:45, 14 August 2022 (UTC)

@Wynndale: Guadeloupean Creole French is missing from the CLDR extension, even though it does have a name in CLDR itself. This affects several other languages too. GCF specifically has been a problem even outside of monolingual text languages in data items. The support code for {{Languages}} has to hard-code an autonym for Guadeloupean Creole French. For now, as a workaround, set the language to mis (unsupported language) and add a language code (P32) qualifier with gcf as the value (example). – Minh Nguyễn ^💬 08:46, 12 October 2022 (UTC)

Order

Is it just me or is https://wiki.openstreetmap.org/wiki/Item:Q4918 showing image at the end for some reason? Are data items showing properties in order of when they were added? Mateusz Konieczny (talk) 09:22, 11 September 2022 (UTC)

Same here, the image is placed at the bottom of the current parameter list - yes i assume the order position is based on the order of adding these data rows. Btw, for images it's needed to set they "Preferred rank" (by the icon upper lefthandside) so that the iD-Editor will show the images for tags next to the corresponding description texts after pressing the "i" information button . --MalgiK (talk) 17:53, 12 October 2022 (UTC)

@Mateusz Konieczny: I tried adding it to the property sort order but it doesn't seem to be taking for this particular statement in this particular item. I'm unsure why. – Minh Nguyễn ^💬 02:10, 1 May 2023 (UTC)

I see the two images next to each other, maybe it was just a caching issue? —Tacsipacsi (talk) 14:19, 1 May 2023 (UTC)

@Tacsipacsi: Yes, it's fixed now. – Minh Nguyễn ^💬 18:30, 19 May 2023 (UTC)

Yes, the order of display depends on the order of addition. maro21 15:00, 1 May 2023 (UTC)

@Maro21: Normally it should not depend on the order of addition. By default, it was based on the relative popularity of each property, but I've since fixed the sort order to something that hopefully seems more logical. – Minh Nguyễn ^💬 18:30, 19 May 2023 (UTC)

Yes, now they are sorted according to that order you specified (they weren't before). It's good. It's easier to find a specific property. maro21 19:14, 20 May 2023 (UTC)

Broken Wikidata ontology

If someone is interested in fixing subclass trees on Wikidata (fixing stuff like "light rail (Q1268865) is classified as being a data visualization (Q6504956)") then you are welcome at https://www.wikidata.org/wiki/Wikidata_talk:WikiProject_Ontology !

This is result of what I found by trying to validate OSM data and ended validating Wikidata.

There is too much of that, and I am not actually so interested in fixing it but maybe someone is more interested here? If that would be fixed it could be used for detecting invalid wikidata=* and wikipedia=* that should be rather subject:wikidata=* and subject:wikipedia=* Mateusz Konieczny (talk) 19:28, 12 October 2022 (UTC)

@Mateusz Konieczny: Just added myself to the Wikidata:WikiProject_Ontology. Seems you're quite active there, fantastic! I will need some time to understand the context on OpenStreetMap + Wikidata, but likely to be someone you can also ping EmericusPetro (talk) 22:47, 2 November 2022 (UTC)

Mysterious data item failure

https://community.openstreetmap.org/t/data-item-not-found-check-your-spelling-for-amenity-mailroom/5618 - help from someone understanding data items would be welcome Mateusz Konieczny (talk) 19:07, 17 November 2022 (UTC)

I assume the red message just occurs because there isn't a created data item for amenity=mailroom yet, see search. I'm on the way to create one... --MalgiK (talk) 19:24, 17 November 2022 (UTC)

Creation of a new item for amenity=mailroom is done, see: https://wiki.openstreetmap.org/wiki/Item:Q22107 - the red message should be disappear after refreshing the page amenity=*. --MalgiK (talk) 19:38, 17 November 2022 (UTC)

Error message when searching for a data item by Special:ItemByTitle

Resolved: Error was fixed. --Chris2map (talk) 16:10, 23 May 2023 (UTC)

When searching for a data item by Special:ItemByTitle there is an error in case item doesn't exist or - more precisely - there is no item linked to the page searched for. You get an error message like:

Internal error
[ef4c7871533a53f3a71e638d] 2023-01-29 11:21:55: Fatal exception of type "Error"

This error occurs since MediaWiki 1.39 update.

The issue is reported to OpenStreetMap Operations: https://github.com/openstreetmap/operations/issues/858

The Special:ItemByTitle functionality is helpful and useful when you want to create a new data item to make sure it doesn't already exist and set site links automatically. --Chris2map (talk) 15:36, 19 March 2023 (UTC)

The error has been fixed now. See github issue 858. Thanks to all involved! --Chris2map (talk) 16:10, 23 May 2023 (UTC)

Property sort order

I've implemented a property sort order so that the statements on each data item page appear in a more rational order instead of (seemingly) purely based on prevalence. Hope this order makes sense. I'm totally open to making adjustments. – Minh Nguyễn ^💬 02:11, 1 May 2023 (UTC)

Preferences > Gadgets

Do these gadgets "Prompt me for an optional edit summary when editing a data item" and "Data item editor" even work? I don't see any difference if I turn them on or not... maro21 18:54, 4 June 2023 (UTC)

The first one tries to add some additional comment to the normal automatical comment, but the length of the whole string seems to be limited, so it may be truncated; example from 2019: [3], I haven't used it since then. --Hufkratzer (talk) 19:50, 4 June 2023 (UTC)

Link to data item in description box

Is there a broader interest in having a link to the data item of a key prefix or key suffix in the description box that is shown on every language page?

See also Template_talk:KeyPrefixDescription#No_link_to_data_item.

For a draft see Sandbox 2023-06-08. --Chris2map (talk) 08:27, 8 June 2023 (UTC)

There is a new draft at Sandbox 2023-10-14.

I propose to implement it into Template:Description so we get the link in the description boxes of prefixes and suffixes. Do you have any comments? --Chris2map (talk) 17:32, 14 October 2023 (UTC)

Maybe making it consistent with links from regular tags and keys would make sense? Mateusz Konieczny (talk) 06:09, 15 October 2023 (UTC)

Having a consistent solution definitely makes sense. But there is no real link for the keys and tags either. The pen behind the description text is helpful, but you have to know that this is the link to the data item. And it only visualizes the difference between the descriptions, not the other parameters. - I would also like to introduce the proposed data item link for all description boxes. -- Chris2map (talk) 12:01, 15 October 2023 (UTC)

I prefer to have the link to the data item as pencil icons. I use them very often to correct descriptions between the article and the data item. "it only visualizes the difference between the descriptions" - description is the most important parameter; "but you have to know that this is the link to the data item" - people who use and edit data items know that:) People who doesn't use data items won't use it anyway or if they are looking the link to the data item, it is on the left. maro21 20:13, 15 October 2023 (UTC)

That's fine by me and we can leave the pen like that. For the prefixes and suffixes, however, this means that the Module:DescriptionFromDataItem has to be supplemented, which is not that easy (at least for me). Nevertheless, I also think it's good to have a "universal" link that is easily recognizable for every user. On the left (in the main menu) is only for English tag pages not other languages. --Chris2map (talk) 17:18, 17 October 2023 (UTC)

Yes, you can add this link. It's better than no link. maro21 22:49, 22 October 2023 (UTC)

Property to provide a link to corresponding category for a group

To me there is a lack of the possibility to provide a link at a group item to its corresponding wiki category, so if you view a data item, click on the group, view the group, and could go on to the category to look for the tags there. (The same as you click the group in the description box on a tag page.) It would require to set a link per language. Similar like the P31 links to the documenting pages. E.g. crafts (Q5149) would have links to Category:Crafts (en), Category:DE:Handwerk (de) and so on. Should we establish a new property for this? --Chris2map (talk) 18:39, 9 June 2023 (UTC)

Entries for Prefix

Yesterday I did some research on all the Data Items for Prefixes and it's quite a mess:

1) The blue prefix name in the page header:

A) with ":*" -> Item:Q227

B) with ":" -> Item:Q6178 + Item:Q22036 + Item:Q174 + Item:Q21974 + Item:Q5927 + Item:Q1200 + Item:Q5313 + Item:Q22029 + Item:Q22019 + Item:Q10855 + Item:Q22032 + Item:Q6131 + Item:Q550 + Item:Q5748 + Item:Q5983 + Item:Q5698 + Item:Q5439 + Item:Q7626

C) key name only -> Item:Q35 + Item:Q75 + Item:Q22204 + Item:Q247 + Item:Q11365 + Item:Q5374 + Item:Q19669 + Item:Q22220 + Item:Q6117 + Item:Q565 + Item:Q665 + Item:Q5734

2) Label in the first top table:

A) with ":*" -> Item:Q227

B) with ":" -> Item:Q6178 + Item:Q22036 + Item:Q174 + Item:Q21974 + Item:Q5927 + Item:Q1200 + Item:Q5313 + Item:Q22029 + Item:Q22019 + Item:Q10855 + Item:Q22032 + Item:Q6131 + Item:Q550 + Item:Q5748 + Item:Q5983 + Item:Q5698 + Item:Q5439 + Item:Q7626

C) key name only -> Item:Q35 + Item:Q75 + Item:Q22204 + Item:Q247 + Item:Q11365 + Item:Q5374 + Item:Q19669 + Item:Q22220 + Item:Q6117 + Item:Q565 + Item:Q665 + Item:Q5734

3) Instance (of):

A) "key" -> Item:Q75 + Item:Q21974 + Item:Q247 + Item:Q227 + Item:Q5374 + Item:Q6117 + Item:Q6131 + Item:Q565 + Item:Q5983 + Item:Q5439 + Item:Q665 + Item:Q5734

B) "key prefix" -> Item:Q6178 + Item:Q35 + Item:Q22036 + Item:Q174 + Item:Q22204 + Item:Q5927 + Item:Q120 + Item:Q5313 + Item:Q22029 + Item:Q22019 + Item:Q10855 + Item:Q11365 + Item:Q19669 + Item:Q22220 + Item:Q22032 + Item:Q550 + Item:Q5748 + Item:Q5698 + Item:Q7626

4) permanent key ID:

A) with ":*" -> Item:Q227

B) with ":" -> Item:Q6178 + Item:Q35 + Item:Q174 + Item:Q21974 + Item:Q5927 + Item:Q1200 + Item:Q5313 + Item:Q10855 + Item:Q6131 + Item:Q5748 + Item:Q5983 + Item:Q5698 + Item:Q5439

C) key name only -> Item:Q75 + Item:Q247 + Item:Q11365 + Item:Q5374 + Item:Q6117 + Item:Q565 + Item:Q550 + Item:Q7626 + Item:Q665 + Item:Q5734

5) permanent key prefix ID:

A) with ":*" -> nothing

B) with ":" -> nothing

C) key name only -> Item:Q35 + Item:Q22204 + Item:Q19669 + Item:Q22220

6) documentation wiki pages (I didn't do statistics anymore here):

A) with ":*"

B) with ":"

C) key name only

What are the correct entries and values?

Once a match is made, the items can be 2), 3) and 6) fixed by me. Administrators must do the rest. -- Lenochod (talk) 21:31, 10. August 2023 (UTC)

Thanks for bringing up this issue and for the analysis,
I think 1) and 2) can be collapsed in one point because the "blue prefix name in the page header" is "the label" for the language the page is rendered for, I think this is how wikibase works.
According to the relative section in this Wiki page the proper version should have:
2) label is always without ":" or ":*" (which makes key suffixes hard to find without a proper query)
3) instance is always "key prefix"
4) "permanent key ID" attribute is not present
5) permanent key prefix ID is always without ":" or ":*"
Extrapolating I think that if the same string is both a key prefix (or suffix) and a standalone key
then a new Data Item should be created for the key, and should be instance of "key" and have a "Permanent key ID" attribute. Not sure about this rule Ernsterwinwg (talk) 16:48, 11 August 2023 (UTC)

I agree with your definition, except for one point, 2) label: With the Proposal:Documentation of key prefixes & suffixes#Proposal Push-f and I proposed to use the ":" with the labels ("To prevent humans from confusing data items describing keys and data items describing key prefixes/suffixes, the latter should be labeled with trailing/leading colons."). So I would set label with ":" and ID without ":". --Chris2map (talk) 17:18, 14 August 2023 (UTC)

I updated diet (Q227) the way I suggest to notate the prefix names. --Chris2map (talk) 16:11, 23 August 2023 (UTC)

If I understand correctly the Proposal you linked does not specify explicitly the format for data items labels.
I also agree the suffix ":" is more readable especially when a key with the same name already exists. But it is currently not consistent with what is written on this wiki page.
Not sure which is the best solution here. Ernsterwinwg (talk) 16:26, 23 August 2023 (UTC)

Yes, the way I suggest isn't 100% implicated by the proposal. In the proposal discussion I came up with the suggestion of using ":" in the label of pre- and suffixes. My view or logic is:

Display combinations of key prefixes
Form	Notation
tag	Tag:name:*=*
key	Key:name:*
prefix	name:
permanent ID of a key prefix	name

--Chris2map (talk) 17:04, 23 August 2023 (UTC)

Repeating the initial list of user Lenochod to show the current state

The header displays the label so no. 1 is the same as no. 2.

1 & 2) The blue prefix name in the page header & Label in the first top table:	A) with :* → -empty- B) with : → contact: + diet: + drink: + payment:+ damage: + disused: + razed: + removed: + ruins: + demolished: + ruined:+ playground: + abandoned: + service:vehicle: + health_specialty: + language: + not: + destroyed: + emergency: + disease: + medical_system: + counselling_type: + communication: C) key name only → addr: + authentication: + planned: + seamark: + socket: + INEGI: + tiger + osak + no:
3) Instance (of):	See sortable table below.
4) permanent key ID:	A) with :* → -empty- B) with : → addr (Q35) + contact: (Q174) + damage: (Q1200) + disused: (Q5313) + razed: (Q5439) + removed: (Q5698) + ruins: (Q5748) + ruined: (Q5983) + demolished: (Q5927) + playground: (Q6131) + abandoned: (Q6178) + health_specialty: (Q10855) + destroyed: (Q21974) C) key name only → authentication (Q75) + payment (Q550) + planned (Q565) + seamark (Q665) + socket (Q711) + INEGI (Q5374) + tiger (Q5734) + osak (Q6117) + service:vehicle (Q7626) + language (Q11365)
5) permanent key prefix ID:	A) with :* → -empty- B) with : → -empty- C) key name only → addr + diet (Q227) + drink (Q247) + not (Q19669) + communication (Q22204) + no (Q22220)

--Chris2map (talk) 16:00, 14 October 2023 (UTC)

Table of key prefix data items

label	instance of	permanent key ID	permanent key prefix ID
addr:	key prefix	-	addr
authentication:	key prefix	-	authentication
contact:	key prefix	contact:	contact
diet:	key prefix	-	diet
drink:	key prefix	-	drink
payment:	key prefix	payment	payment
planned:	key prefix	planned	planned
seamark:	key prefix	seamark	seamark
socket:	key prefix	socket	socket
damage:	key prefix	damage:	-
disused:	key prefix	disused:	-
INEGI:	key prefix	-	INEGI
razed:	key prefix	razed:	razed
removed:	key prefix	removed:	-
tiger	key	tiger	-
demolished:	key prefix	demolished:	-
ruined:	key prefix	ruined:	ruined
osak	key	osak	-
playground:	key prefix	playground:	playground
abandoned:	key prefix	abandoned:	-
service:vehicle:	key prefix	service:vehicle	-
health_specialty:	key prefix	health_specialty:	-
language:	key prefix	language	language
not:	key prefix	-	not
destroyed:	key prefix	destroyed:	destroyed
emergency:	key prefix	-	emergency
disease:	key prefix	-	disease
medical_system:	key prefix	-	medical_system
counselling_type:	key prefix	-	counselling_type
communication:	key prefix	-	communication
no:	key prefix	-	no
construction:	key prefix	-	construction
delivery:	key prefix	-	delivery
note:	key prefix	-	note
GNS:	key prefix	-	GNS
opening_hours:	key prefix	-	opening_hours
school:	key prefix	-	school
service:bicycle:	key prefix	-	service:bicycle
was:	key prefix	-	was
fuel:	key prefix	-	fuel
capacity:	key prefix	-	capacity
recycling:	key prefix	-	recycling
building:	key prefix	-	building

Before we fix it, we should agree on how we want to write the IDs: With or without ":" for key prefixes? – In the small table above I suggested without ":". But I'm not completely sure myself. For human differentiation, ":" would probably be better. For software, without ":" is probably more logical. --Chris2map (talk) 16:00, 14 October 2023 (UTC)

I would say without, mainly because in this way we duplicating the information already contained in the property "instance_of".
I think that maybe would good for human readability if proper cosmetics i.e. postponing ":" to the label can be applied automatically based on the values of "instance_of", but I don't know if wikibase supports this. Ernsterwinwg (talk) 15:15, 23 October 2023 (UTC)

I think that's good and would continue setting permanent prefix ID without ":". --Chris2map (talk) 15:58, 23 October 2023 (UTC)

Maybe permanent key prefix ID without ":" and label with ":"? maro21 16:41, 27 October 2023 (UTC)

For now, that's my point of view, too. Anyone else with different view? --Chris2map (talk) 14:55, 28 October 2023 (UTC)

Link to taginfo on item page

IMHO it would be nice to have a link to taginfo on the item page of any data item. There are data items for tags having no own wiki page or having a redirecting page only, where there is no description box and no link to taginfo. E.g. maxstay:conditional (Q11670). Would a taginfo link be possible? @Minh Nguyen: --Chris2map (talk) 16:04, 12 October 2023 (UTC)

@Chris2map: Key:maxspeed:conditional should ideally be an independent article; then, you could simply click on the item’s header and see the taginfo statistics in the infobox. It would be possible to add taginfo statistics directly to the item’s page. This would need to happen as part of a gadget, such as mediawiki:Gadget-dataitemlinks.js. The gadget code can only be edited by an administrator, but you can copy the code to Special:MyPage/common.js and prototype a proposed change to the code. – Minh Nguyễn ^💬 06:03, 13 October 2023 (UTC)

OK, thanks for quick answer! I'll see if I can get a prototype working. --Chris2map (talk) 16:14, 13 October 2023 (UTC)

Data item property P17 replaced by

The following was moved here from User talk:Henry572

---

Hi! I saw your additions from replaced by (P17), e.g. Special:Diff/2648312. I have always added this property as a standalone entry (e.g. Item:Q225), not as a qualifier of status. --Chris2map (talk) 17:52, 17 January 2024 (UTC)

Thanks for notifying me. I thought that it might make sense because replaced by (P17) is only used on certain values of status and because the reference refers to both. I must admit that I have already encountered some problems, e.g. with lines (Q384) where a qualifier can't hold two values. Also, you seem to have much more experience with data items and if this is current practice, I will follow it and correct my edits accordingly. Maybe Data items should mention this. --Henry572 (talk) 18:16, 17 January 2024 (UTC)

I hadn't yet thought about the possibility of attaching P17 as a qualifier to the status. The few uses of P17 that I know of have been as a separate entry. I can't say how it was originally intended, but I find direct, separate use easier and I suspect easier to evaluate (for software). Comparable to required key or tag (P22) or different from (P18). P17 is not mentioned at all on the Data items page. This should be improved. We could move the discussion to Talk:Data items. --Chris2map (talk) 19:21, 17 January 2024 (UTC)

---

I agree that using replaced by (P17) separately is easier to interpret and enables it to have multiple values (and not having two competing schemes is good). In terms of documentation, I would propose to add the following table row to the table at Data items#Keys. In particular the reference only has to be specified once at status (P6) to avoid redundancy.

property	type	value example	description
replaced by (P17) Indicates that the current key, tag or relation type should not be used. Use the target item instead. Use references for the status, linking to status discussion.	Item	man_made=bridge (Q6694) bridge=movable (Q5711) On manufacturer:type (Q400): model (Q3655) --Henry572 (talk) 21:47, 18 January 2024 (UTC)	One or multiple keys that replace this one. The corresponding proposal (if existent) should already be linked as a reference for proposal discussion (P11) status (P6) with proposal discussion (P11). --Henry572 (talk) 21:15, 18 January 2024 (UTC)

I agree with Chris, that it is better to have it as a standalone property rather than a qualifier.

Just wondering if the two values listed for "replaced by" mean "OR" or "AND"... Like in the example you mentioned.

Sometimes it could be that one tag should be replaced by two tags: "something + something2", and in other cases it could be that a given tag is deprecated, but should be replaced by "something OR something2" depending on the context (correct me if I'm wrong). This makes the "replaced by" property could not be automatically interpreted correctly when there will be two values there. maro21 23:50, 17 January 2024 (UTC)

I would change description to "One or multiple keys that replace this one. The corresponding proposal (if existent) should already be linked as a reference for status (P6) with proposal discussion (P11).

Correct, I got confused there. --Henry572 (talk) 21:15, 18 January 2024 (UTC)

Done: diff. --Henry572 (talk) 10:09, 20 January 2024 (UTC)

The issue with 2 or more entries isn't solved: IMHO technical it is "OR". Same issue exists with the propertie P22 (required). Maybe we could create a qualifier to add to the entries and state "AND" or "OR". Alternatively we had to create new properties for the multiple "AND" cases, like "replaced by all of" or something like that. --Chris2map (talk) 20:42, 18 January 2024 (UTC)

"Maybe we could create a qualifier to add to the entries and state "AND" or "OR"." That sounds reasonable. Does Wikidata have something related? --Henry572 (talk) 21:15, 18 January 2024 (UTC)

What do you think of disused:building (Q3194) where I used combination (P46) as a qualifier for replaced by (P17) to combine two tags? Is this "tagging for the renderer" because "combination" is similar to "and"? --Henry572 (talk) 20:17, 20 January 2024 (UTC)

I would have set it more likely the other way around (disused=yes comb. building). But I don't think we can use P46 for a different purpose than it is intended. I suspect this could lead to issues when you want to read out or analyse data with external software. --Chris2map (talk) 20:56, 20 January 2024 (UTC)

New try: I created Disused building (Q22384) which is an instance of the above mentioned concept (EXPERIMENTAL) (Q4668). On disused:building (Q3194) replaced by (P17) the preferred rank is disused=yes (Q6096) as you said and with normal rank I added this new concept which requires the two tags.
Using combination (P46) for a different purpose might admittedly break some software, but now it's reasonable to assume that software will either just take the preferred rank or check if the values of replaced by (P17) are instances of key or tag and just skip the new concept (EXPERIMENTAL). --Henry572 (talk) 21:59, 20 January 2024 (UTC)

Duplicate groups

There are some groups that seem to be duplicates of others and thus are rarely or never used. I found ERROR: Invalid ID which looks the same as education (Q21945). A little script I wrote found no uses for the former and 16 for the latter. ERROR: Invalid ID and ERROR: Invalid ID also seem to be unused as there is already sports (Q4689).

In the first case, we should probably delete ERROR: Invalid ID while in the second case it might be possible to populate the more specific groups. On a general note, I have found no documentation which groups there are, maybe someone can point me towards some discussions or definitions. --Henry572 (talk) 18:47, 31 January 2024 (UTC)

I'm with you. For "education" see also Category_talk:Education_features#Category:Education. And "sports" should be fine as group for all activities. More specific categorization can be done by additional categories (outdoor activities, winter sports, etc.). --Chris2map (talk) 19:12, 31 January 2024 (UTC)

I've wanted to bring up this thread before, because I found some duplicate groups back in June last year. There are several groups with similar names. To ponder, are they separate groups or better to merge them into one:

• water [9] and water management [18] and waterways [43] and rivers [0, deleted already].
• marine [17], marine navigation [87], maritime [16] - maybe these should be separate groups but some "seamark:"s are in all of these groups.

I would like to hear your opinions on whether these should be separate groups or one.

Other groups:

• education_features group I nominated for deletion in June 2023, but the admin deleted the talk page, instead of the data item!
• The same story was with outdoor activities, winter sports, Piste Maps and sidewalks.

maro21 20:09, 31 January 2024 (UTC)

water

I think there is a large enough difference between water management and waterways to keep them separate. The items from water could then be sorted into one of those two categories (I just moved salt (Q661) to properties (Q4671) to align with the Key:salt page). --Henry572 (talk) 20:37, 31 January 2024 (UTC)

marine

The contents of marine look sufficiently different from those in marine navigation and maritime, while those two could be merged: they both include artificial objects made for navigation. --Henry572 (talk) 20:37, 31 January 2024 (UTC)

education, outdoor and sidewalks

I agree with the deletion. --Henry572 (talk) 20:37, 31 January 2024 (UTC)

education features, outdoor activities, winter sports, Piste Maps and sidewalks groups deleted. maro21 18:00, 1 February 2024 (UTC)