User talk:Yurik

From OpenStreetMap Wiki
Jump to: navigation, search

Default_language page?

Do I have permission to edit the default_language=* page to match the current proposal about default language formats? This is necessary if we are going to change the key to be default_language, to avoid confusion.

If you don't want the page changed, I can pick a different key like default:language, though it still will lead to some confusion if the proposal is approved. --Jeisenbe (talk) 01:01, 27 September 2018 (UTC)

@Jeisenbe, you never need permission to change any page in the wiki (with the possible exception of the user:*). That said, the current default_language=* documents how that tag should be used. You shouldn't change how it should be used until after the proposal is accepted. I would recommend copying the current page into the Proposed features/Key:default_language or some other such place, making all the needed adjustments to the current text, and getting the acceptance. Once done, you can simply copy it back over, possibly preserving any minor changes that happened since your initially copied it. --Yurik (talk) 01:37, 27 September 2018 (UTC)
I'm trying to be polite, and I also don't want to waste anyone's time by editing a page which will then be reverted. What I mean is that I am considering using default_language=* instead of language:default=* for the proposal about default language formats, which you commented on: Default Language Format. But I can't use this tag without changing the page to match the language of the proposal. Specifically, I would need to totally change the part about multiple languages. Alternately, we could move this whole page "Proposed_Features/default_langauge", because it has not yet been approved.--Jeisenbe (talk) 05:20, 27 September 2018 (UTC)
@Jeisenbe, appreciate it :) We have to consider the goals though. default_language has a very clear goal - to allow data users to know the language of the name tag. Given any OSM object with just a single name tag, default_language will allow you to convert object's coordinates to a simple language code, thus being able to intelligently use that single name tag. If you put two values in there, this goal cannot be reached, unless each name tag in that region always contains two name strings, e.g. separated by a dash. This is very rare, and I only saw it on the city names, not street names (I'm sure it does exist). Also, changing the meaning of the default_language would break any client that already uses it. I might have to re-read your proposal just to make certain I understood it correctly. --Yurik (talk) 05:29, 27 September 2018 (UTC)

SPARQL question

I see that you created SPARQL examples. I have two questions:

Is it feasible to generate list of wikidata entries that

  • have interesting (long or featured) articles on Polish or English Wikipedia
  • have coordinates or are otherwise described as mappable object
  • are without wikipedia/wikidata tag
  • are located in Poland or around some specific location


To avoid XY problem - I want to add wikidata entries but I am bored by processing at bunch of substubs without any interesting content. Also, trying to match major articles may help to detect missing OSM data.

Is it possible to get query result from using API? is mentioning only manual download

Mateusz Konieczny (talk) 08:32, 9 September 2017 (UTC)

Hi Mateusz, yes to all of the above :) First, you may want to take a look at the main WDQS (click "Examples" there) - it has a lot of Wikidata-only examples and info. Also some help links too. You may use the API directly (look in the browser debugger at the request it sends, and do the same). Its a simple GET request. Or you can use my python code, with endpoint. I will post the queries here in a bit. --Yurik (talk) 01:06, 10 September 2017 (UTC)
P.S. Mateusz, I wrote a query per above and added it to examples. --Yurik (talk) 02:44, 10 September 2017 (UTC)
P.P.S Wikidata does not store article length, but it has page views counts, and how many different wiki languages have an article on the topic. Both are very good indicators of which objects should be shown first.
Is it possible to exclude events? Note that I am not interested in limiting to subclasses of Q618123 (that should be easier, but many entries in Wikidata lack "instance of"). I tried in Wikidata Query Service
SELECT ?item ?itemLabel
  ?item wdt:P625 ?location.
  MINUS { ?location wdt:P31/wdt:P279* wd:Q1190554. }  # excludes events
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }

but it timeouts for some reason. I looked at examples but I failed one that excludes items that are subclasses of something and once I tried adapt others I ended with query above that for some reason has performance problems. What is the CPU safe way of excluding events, without excluding objects missing instance of? I prefer false positives, I have no problem with adding missing "is instance".

Modyfying query at SPARQL examples tinyurl y9ma6e3f or tinyurl 993o5sy (no direct URL, wikidata for some reason is using public link shortener typically used to hide spam) resulted in 504 Gateway Time-out.

Mateusz Konieczny (talk) 06:08, 13 September 2017 (UTC)

You are using the wrong subject - it should be ?item, or in my example - ?wd: FILTER NOT EXISTS { ?wd wdt:P31/wdt:P279* wd:Q1190554 . } But yes, it does take too long. It might work faster if replace circle service with the coordinate filter, like I did here (last commented portion). --Yurik (talk) 06:45, 13 September 2017 (UTC)
Thanks! I tried bbox, but it is failing even in the simplest case:
SELECT ?osmId ?wdLabel WHERE {
   ?osmId osmm:loc ?loc .
   BIND( geof:longitude(?loc) as ?longitude )
   BIND( geof:latitude(?loc) as ?latitude )
   FILTER( ?longitude > 19 && ?longitude < 20 && ?latitude > 50 && ?latitude < 51)
} LIMIT 10

is it a hardware limitation or is something wrong wrong with my query? And thanks for featured articles query, I already used it to add some links and read interesting Wikipedia articles Mateusz Konieczny (talk) 08:30, 13 September 2017 (UTC)

I think its failing because there are so many points, and that query requires a sequential scan through the whole DB. That's why there is a box and circle geo services developed by Wikidata. The sequential filtering works well after the results are already small enough. The service on the other hand seems to be doing small geo-indexing, but it does it first, before the filtering. Need to look at it more. --Yurik (talk) 10:41, 13 September 2017 (UTC)

SPARQL question II

Sorry for bothering you but I have other query that fails for an unknown reason:

I wanted to find on Wikidata human settlements in Poland with teryt code and exclude already linked from OSM to check whatever wikidata import using teryt ids for matching may be useful

SELECT ?item ?itemLabel
   ?item wdt:P31 wd:Q486972.
 		?item wdt:P4046 ?teryt
   # There must not be an OSM object with this wikidata id
   FILTER NOT EXISTS { ?osm1 osmt:wikidata ?wd . }
   # There must not be an OSM object with this wikipedia link
   FILTER NOT EXISTS { ?osm2 osmt:wikipedia ?sitelink . }
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
 } LIMIT 10

Run it (edit query)

Query return 0 elements, what is surprising given that there are elements that should match.

For example and (I checked lack of matches with )

I used following query adapted from one examples to check that both osm node representing Grodno and its Wikidata entry are in database:

SELECT ?marketLoc ?marketName (?amenity as ?layer) ?osmid WHERE {
   VALUES ?place { "hamlet" }
   ?osmid osmt:place ?place ;
         osmt:name ?marketName ;
         osmm:loc ?marketLoc .
   # Get the location of Grodno from Wikidata
   wd:Q673875 wdt:P625 ?myLoc .
   # Calculate the distance,
   # and filter to just those within 5km
   BIND(geof:distance(?myLoc, ?marketLoc) as ?dist)
   FILTER(?dist < 5)

Run it (edit query)

so it seems that there is a bug in my TERYT query. Is it something obvious? Mateusz Konieczny (talk) 16:35, 13 September 2017 (UTC)

Mateusz, the first query is a bit wrong - you used different variable names - ?item and ?wd, instead of the same one. Also, you don't need "Filter exists" - you can simply list both statements. No need to filter out sitelinks because they are not connected to the rest of the query. And lastly, you don't want just the "instance of a human settlement", you want "instance of a human settlement or anything that is a sub-sub-sub... class of a human settlement".
SELECT ?item ?teryt ?itemLabel WHERE {
   ?item wdt:P31/wdt:P279* wd:Q486972 .
   ?item wdt:P4046 ?teryt .
   FILTER NOT EXISTS { ?osm1 osmt:wikidata ?item . }
   SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en" }
} LIMIT 10

Run it (edit query)

--Yurik (talk) 22:00, 13 September 2017 (UTC)

Wikidata fixing - my noSPARQL tool

It seems that you are interested in the topic and it may give ideas for more quality checks and data import possibilities - I created it before I was aware of SPARQL, main benefit is that it allows thorough listing of issues in a given location without running multiple SPARQL querries. Main problem is that it is not using proper database import (it is downloading individual wikidata entries), as result it is not feasible to run worldwide reports Mateusz Konieczny (talk) 08:03, 2 October 2017 (UTC)

Hi @Mateusz Konieczny, yes, seems we do have some functional overlap there :) Please take a look at Wikipedia Link Improvement Project - I'm putting together all sorts of issues that have been discovered so far. I think your github README should point just to that page, not my old OSM_wiki tag problems or quality control queries. The SPARQL_examples page is mostly used from inside the service itself - it shows up as the "examples" dialog there (try it, its cool :)) Also, there is a big (and somewhat ... heated) discussion at the @talk mailing list that you might be interested in.
Lastly, lets see if we can create SPARQL queries for all of your validations - allowing people to query directly, and to see up to date info is fairly important. BTW, if you know ruby, it would be awesome to help improve MapRoulette a little bit - so that we can upload some of these challenges there. Currently maproulette is missing one important feature - ability to store OSM ids. If it allows it, we can upload objects, and allow users to link to those objects.

P.S. I know it sucks to duplicate efforts, lets coordinate better :) --Yurik (talk) 18:23, 2 October 2017 (UTC)

  • Wikipedia Link Improvement Project - thanks! (I found it already, in fact that was why I am writing this).
  • "should point just to that page, not my old OSM_wiki tag problems or quality control queries" - fixed!
  • "Lastly, lets see if we can create SPARQL queries for all of your validations" - that would be a good idea Mateusz Konieczny (talk) 05:08, 3 October 2017 (UTC)
@Mateusz Konieczny, LOL: " rely on service that may be hard to replicate once it stops working" -- that's a very strange argument. Every service is only good while it works! :) On the other hand, anyone can set up a clone of that service - --Yurik (talk) 05:16, 3 October 2017 (UTC)
"that's a very strange argument. Every service is only good while it works!" - yes, but I think you will admit that this service is probably less stable than wikidata API. Thanks for the link! I will try setting this up. Mateusz Konieczny (talk) 05:28, 3 October 2017 (UTC)
On topic of mailing lists - I looked at it and I would really advice to stop pushing for worldwide mechanical edits. It is obvious that people are really unhappy with that idea, and it has potential to not merely end with no edits done and massive amount of discussion but also with backslash ("lets delete all wikidata", "completely ban bots") Maybe try discussing this ideas with local community? Mateusz Konieczny (talk) 05:29, 3 October 2017 (UTC)
@Mateusz Konieczny, I agree, at this point I am simply trying to educate people of what it is, and what benefits it provides. Seems like the loudest are the ones who also have the least understanding of it. Funny how all the more advanced data consumers have already switched to it - Mapbox, Openmaptiles, etc. It has a huge benefit, but because it looks like a "number", and not all tools support it yet, people are afraid of "some number of the devil" that is added. I thought that my initial request, followed by a discussion, followed by a 4 days of quiet time could be considered as settled. But apparently some people decided to jump on it after the discussion. Oh well. As for your github, please change the wording about "only works while it works" - same can be said about OSM itself :) --Yurik (talk) 05:42, 3 October 2017 (UTC)
I removed tautology from github readme. "people are afraid of" - I think that most people are afraid of ending bot happy like Wikidata or Cebuano wikipedia. What is understandable, given different style/targets/situation. Mateusz Konieczny (talk) 06:28, 3 October 2017 (UTC)
@Mateusz Konieczny, its always important to go for the "golden middle". English Wikipedia has used countless bots, and has become the most successful project. OSM is extremely anti-bot. ceb-wiki is a joke. I think its a mistake to go into either extreme. --Yurik (talk) 06:39, 3 October 2017 (UTC)
I'm sure pushing wikidata in such a large scale effort will change that overall attitude towards bots or more genereally speaking what is considered to be automated edits. NOT. People are per se not anti wikidata (even you keep on reiterating the same argument over and over). Maybe you should use a more piecemeal approach so people have a chance to gain more trust and confidence in more automation. This however might end up in a way that a more local mapper community driven approach would be favored, and automation is still considered to be fundamentally flawed (e.g. because the data you use for reasoning is already crappy). I really wonder why you take the burden of adding all this wikidata on your own. It's really the local communities who should take ownership and you can support them via your toolset (like you already do). There were several bots in the past that really messed up data, such as xybot. I believe people have good reason to be very sceptical, given how easily you can screw up data. Leveraging wikidata for multilanguage labels like Mapbox does looks like the first step, I'm sure there are plenty of other use cases ahead :) (see Mmd (talk) 06:53, 3 October 2017 (UTC)

Change of parser limits

Hi Yuri,

Thank you for Blacktocat.svg openstreetmap/chef/commit/6694697e2851ac362546d34cf12f146633be3782. I found it by accident, it would have been nice if you would have posted that at Talk:Wiki or at Please do not get me wrong! I am absolutely happy with that. Reading pages like Category:Pages with too many expensive parser function calls you get the impression that people waited for that change for years. Now, these pages need to be adjusted.
Thanks again
PS: I am more than happy to help you with something I just do not know a lot about the technical setup behind OSM (that is why I have never made a change or added a PR). --Tigerfell This user is member of the wiki team of OSM (Let's talk) 18:30, 27 September 2018 (UTC)

@Tigerfell thanks for the heads up. Sorry I was not aware that was impacting anyone else, or that the community was waiting for it. I only saw it with regards to the recent Lua changes. I will make sure to post these things to the form. BTW, a heads up -- the searchbox change has just been merged, so it should bring back the original functioning of the searchbox dropdown. --Yurik (talk) 20:40, 27 September 2018 (UTC)

Great! Thanks again! --Tigerfell This user is member of the wiki team of OSM (Let's talk) 21:49, 27 September 2018 (UTC)


Thanks for the tips! I will try to help as much as I can. --Милан Јелисавчић (talk) 21:29, 28 September 2018 (UTC)

Thanks!!! --Yurik (talk) 21:37, 28 September 2018 (UTC)

Wiki extensions for displaying maps

Hi Yuri,

I am currently searching for a well-crafted MediaWiki extension for this wiki that allows displaying multiple maps in an article. We had some discussion already at Talk:Wiki#Map_extensions, tried out the installation of "Maps" extension, and failed.

One alternative mentioned was the "Kartographer" extension. We have the following requirements:

  1. Dependencies towards a singular website should be avoided (see issues with Simple image MediaWiki Extension).
  2. dropped
  3. No extensions that require an arbitrary amount of maintenance or self-coding (missing coding/maintenance capacities in the wiki).
  4. Ability to display Standard tile layer map rendering.
  5. If the extension allows maps from non-open sources, there must be a setting to disable accessing this source for the whole wiki.

Since you were involved in Kartographer, can you tell me if it can fulfil these requirements? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 11:32, 22 October 2018 (UTC)


Hi Yuri, I have seen you are running the bot Yurikbot which seems to create wikidata style items in the wiki from taginfo data. Is there documentation what this bot does specifically? --Dieterdreist (talk) 18:37, 9 November 2018 (UTC)

Hi Dieterdreist, please take a look at the OpenStreetMap:Wikibase and search for the word "bot". I plan to write up a much bigger post, and upload all the bot code shortly (currently in the process of cleaning it up). Thanks! --Yurik (talk) 19:19, 9 November 2018 (UTC)

About labels

Can you define what is a label, description, aliases and where it can be used? I'm not sure what can or can't be edited. For example, in english label bridge:structure - can it translated to мост:структура or Структура моста? Maybe I need to leave it empty? Does any changes to it do something to wiki? —Preceding unsigned comment added by XnL (talkcontribs)

We probably should create a guide on how to edit these things. In theory, everything can be edited, but probably shouldn't :). But in short, if we look at building:fireproof (Q114):
  • Each "key" data item must have permanent key ID (P16) = building:fireproof. This MUST NOT change. Ever. (only exception - if you created it by hand and made a typo, so you can fix the typo right after creating it, but not after). Think of P16 the same as the permanent string ID of the entry, same as "Q114" that cannot be changed by design. If it needs changing, create a new data item, and set the old entry's status to deprecated, and add a property to indicate redirection (I don't think we have created a property like that yet, TODO)
  • The English label is almost always set to the same value as P16. This makes it easy to write {{O|Q114}} in this wiki, which shows as building:fireproof (Q114). In theory, iD or other editors could show the label in addition to the P16. For example, an editor could show огнеупорность здания (building:fireproof) (for RU), plus the description. Also, labels will be used for searches -- when the user wants to add a new tag, a popup will show the list of available keys, searching label/description/aliases. In general, I would recommend adding a very short localized label describing the concept in one/two words. Also, I think labels should NOT be capitalized.
  • The description should be a short (under 250 characters) text that gives the most important information. It should not cover all the nuances - we have wiki pages for that. Description is the most important for localization, and should be translated first if possible. I think description should be properly capitalized, and make full sentences with an period at the end.
  • Aliases ("also known as") is just like labels, but there could be more than one for every language. They are mostly used for searching. Not capitalized.

--Yurik (talk) 21:52, 6 December 2018 (UTC)

Hi Yurik, reading your comments an my last edit, i think the above description about labels should be clarified that one should use the same key=value syntax as the english original but in the respective language. Until your comment I was under the assumption that once you have a fixed data item, the label just gives you the meaning of the tag in one or two words (in english or every other language) while the description gives you a very brief definition, for example highway=motorway is defined as the data item, so the English label would be just motorway while the German label would be Autobahn serving as a direct translation leaving the description field for further information on how the exact meaning of the tag is defined in osm.--Kjon (talk) 07:32, 8 December 2018 (UTC)
Kjon, you do raise a valid point. Label is a tricky thing because of this duality. Historically, many key and tag pages have defined "nativekey" and "nativevalue", thus matching the key=value in English. I do hope that we at some point can switch presets (features) to the data items, in which case the "motorway/autobahn" would be the label of the feature, and highway=motorway would be the label of the tag. Description on the other hand is fairly straightforward already - it essentially states what either the key or the key=value means. Perhaps I should clarify that labels at this point is a copy of nativekey/value until we figure out the rest of it. Thanks for helping! Lets do a proper guide for this somewhere :) --Yurik (talk) 07:53, 8 December 2018 (UTC)
From my discoveries the description does not have such a clear meaning as it is often mis(?)used as a straight translation of the feature.--Kjon (talk) 16:43, 8 December 2018 (UTC)


I think it would be good to add the |Main article = parameter to the template with a link to this article.
Then you could use the |group = parameter to link to the category with the same name. Currently, my categories are in "keys without group", which is not true. --Władysław Komorek (talk) 10:47, 10 December 2018 (UTC)

Could you give an example of a page that has "keys without group" ? --Yurik (talk) 15:09, 10 December 2018 (UTC)
Based on "DescriptionCategoriesLang" -> "|keys without group=Opis klucza według kategorii".
natural=* -> Category:Pl:Opis klucza według kategorii. --Władysław Komorek (talk) 16:11, 10 December 2018 (UTC)
Could you join OSM chat and ping @nyurik - we could discuss it directly (there are over a thousand OSMers there already). I am not exactly sure I understood the "main article" point. The category is already being generated (i removed it from the page, but it gets added automatically anyway). The issue is inside the {{Description}} itself -- I will have to remove category generation from there, as it is not aware of some Pl-related stuff. --Yurik (talk) 17:22, 10 December 2018 (UTC)
<image_caption text>

<some description>
Main article: Railways
Group: Railways
Used on these elements
Documented values: 39

Also forgot to write to you that in "Relation Description" template, there is no |nativekey = only |nativetype = similar to |type =. --Władysław Komorek (talk) 18:24, 10 December 2018 (UTC)

Sophox plant challenge

Hi Yurik. I think the link to the plant challenge over at Sophox#Current_Challenges might be broken. Either that, or the challenge has been completed. Pizzaiolo (talk) 12:42, 14 December 2018 (UTC)

Pizzaiolo thanks, yes, most of them need to be fixed because Sophox used to have Wikidata together with OSM in the same database. Now Sophox has to make a federated query to Wikidata service to get that data. --Yurik (talk) 21:35, 14 December 2018 (UTC)

Category:Mismatched_Key_or_Value -- confusing?

I noticed Category:Mismatched_Key_or_Value, and I found where it's added in the Lua module; but I don't understand what that condition is, exactly, or how to fix it. I suspect it of being due to bugs in the Lua module... is that right? JesseFW (talk) 06:44, 22 December 2018 (UTC)

JesseFW, this category shows all Key:... pages that have a value=... parameter. I suspect this a mistake, so either 1) the page should be renamed and it should use {{ValueDescription}}, or copy some of the page content to the corresponding Tag page, or simply remove the value= parameter. In many cases, this is due to the "yes" values, e.g. cabin:rental=* vs cabin:rental=yes -- there is little value in having them as separate pages, but we should have them as individual data items. I'm also on OSM Slack @nyurik. --Yurik (talk) 06:50, 22 December 2018 (UTC)
Cool, that makes sense -- could you expand the description on the category page to mention that? JesseFW (talk) 17:38, 22 December 2018 (UTC)

Translation of key-value pairs Translating tags does not seem very useful to me, since they must be added in the DB in English. Why was this added? —M!dgard [ talk ] 13:19, 24 December 2018 (UTC)

@M!dgard take a look at Pl:Tag:emergency=fire_alarm_box - it has nativekey=awaryjne and nativevalue=skrzynka_przeciwpożarowa. For now, I copied that data into the label, but we should have a more in-depth discussion about it. The goal of nativekey/nativevalue is to help mappers who don't speak English. On the other hand, using label for this is not good from the data structure perspective -- it is not reliable for analysis. Moreover, I hope that we start using data items as presets - e.g. emergency=fire_alarm_box (Q6634) would have its instance of (P2) set to both a tag (Q2) and to feature (Q7564), and the label would be changed to fire alarm box (with aliases used for alternative names). iD editor would then simply query for all such items, and will use localized labels + description to show them properly. So the question if we want to keep native key/value is still unclear -- we do not have any tools to my knowledge that use them. --Yurik (talk) 18:31, 24 December 2018 (UTC)
So this translated label is purely to help people understand what the literal meaning of the key-value pairs is. That's okay. I assume you put it as the label for now because creating a property for it and having the translations in a statement would result in a lot of text you don't understand that you can't hide.
I very much support the goal of machine-readable tag descriptions. See also this SotM 2010 talk. I think Wikibase didn't exist yet at the time. —M!dgard [ talk ] 18:56, 25 December 2018 (UTC)

Structured data

1. I created a tag item (surface=concrete) and I felt the need for these properties:

Why would it need regex? We already have value validation regex (P13), but it is for keys, e.g. population (Q574), not specific tags. Refinement is a bit ambiguous - it could either be that one tag requires another tag to be present, or it could mean that it is a more specific tag of another one. I'm all for creating such thing, but lets discuss it on Talk:Data Items. --Yurik (talk) 19:53, 26 December 2018 (UTC)
Regex: aha, that was what I was looking for. I added an alias to make it easier to find. Refines: ah, great that there's a dedicated talk page, I hadn't found it. —M!dgard [ talk ] 21:47, 26 December 2018 (UTC)

2. I find the items Q3 through Q6 (node, way, area, relation) confusing. They aren't disjoint: areas are always be ways and (for multipolygons) relations. It would make sense to give area “subclass of: pseudo-element” instead of “element”. In my opinion it would make sense to also create concepts for the data types that iD uses (free-standing points, nodes (of lines and areas), lines, areas, non-multipolygon relations) and link the “use on …” to those. Data that links the iD data types to the real OSM elements could also be created. —M!dgard [ talk ] 12:58, 26 December 2018 (UTC)

node (Q3),way (Q4),area (Q5) are now obsolete, and will be deleted soon. The relation type (Q6) is used to identify relation types, see [1]. --Yurik (talk) 19:53, 26 December 2018 (UTC)
Okay, I added an obsoletion warning in the descriptions, I saw that just today people were translating them to German and Ukrainian. —M!dgard [ talk ] 21:47, 26 December 2018 (UTC)

3. How does P9 key type work? I found Q8 well-known values, but no other values. Q464 name=* has “key type: well-known values”, but to my knowledge this is completely wrong, no? —M!dgard [ talk ] 12:58, 26 December 2018 (UTC)

key type (P9) was mentioned in the talk page. See types of keys. This is still a work in progress, and we should probably introduce more. restaurant (Q646) i a tricky one, because it does have many well known values like name=McDonald's (Q7304). We need to think of the best way to represent those.
In general, my primary goal is not to invent new stuff (just yet), but replicate what we already have in a number of systems - like lists of tags on the wiki pages, iD presets, JOSM validations, etc. This doesn't mean we shouldn't try new things, but if we do too many new things, we will simply create another system to take care of, instead of any kind of consolidation. --Yurik (talk) 19:53, 26 December 2018 (UTC)
I assume you meant name (Q464). :) In my view, one should never assign meaning based on a name. I wasn't aware that there are pages like Tag:name=McDonald's but to me they don't make sense: there may well be restaurants called "McDonald's" or close variants that aren't part of the well-known chain. In Belgium we maintain an index of common chains at WikiProject_Belgium/ChainStores. Anyway, this is a bit off-topic.
Aha, I hadn't found Data_Items yet. —M!dgard [ talk ] 21:47, 26 December 2018 (UTC)

Moving pages with items

Could you explain what happens when a page with an item is being moved? Seems the item is moved along with the page but not being noticed? Could not find it after the move. --Polarbear w (talk) 10:32, 12 February 2019 (UTC)

@Polarbear w data items have a "sitelink" parameter, which stores a corresponding wiki page title. When set, you will see a OpenStreetMap Wiki item link in the left toolbar on the wiki page, but only for the "primary" wiki page (we can only store a single sitelink per data item). So ref (Q599) sitelinks to Key:ref, but not to FR:Key:ref. Note that the {{KeyDescription}} template can still find the right data item on the FR page because it uses Key:ref as a lookup ID, and shows a gray pencil icon next to description in the right infobox.
In Wikidata, when a page is renamed, sitelinks are updated automatically to the new page title. For OSM wiki, this would be bad because sitelink is used as a lookup ID, so when you renamed Tag:natural=moss to Proposed features/Tag:natural=moss, I had to manually revert the corresponding data item sitelink change. This way natural=moss (Q7656) can still be found when needed by iD editor or other wiki pages. Hope this helps! --Yurik (talk) 18:18, 12 February 2019 (UTC)

Need ES help with long descriptions

Hello Yurik, I have modified the descriptions of the pages in Spanish listed here, now the descriptions have a maximum of 250 characters. --Ovruni (talk) 20:30, 13 February 2019 (UTC)

Re: Need Pt help with long descriptions

Hi, thank you for warning me about that. I noticed that in a few of them while I was testing iD. Your list is useful and I will fix them. By the way, I noticed a few days ago iD shows the tag description present in wikidata pages if they exist and not the tag description in OSM wiki pages, so every time we change a description in this wiki we should change that information in wikidata page too? Zermes (talk) 00:00, 15 February 2019 (UTC)

@Zermes thanks! Data items are updated automatically whenever i run my bot. Eventually I will automate it to run on every wiki change... until at some point I hope we will remove all parameters from the {{KeyDescription}} and {{ValueDescription}}. You can already try it -- if you remove all parameters on some key or tag page, and click "preview" (instead of saving), you will see that the sidebox will take all the info from the data items. --Yurik (talk) 00:51, 15 February 2019 (UTC)
Thank you for the info. I noticed that too... At first, I think it drives people crazy (happened a bit to me), since some info isn't really in the page we are editing and we think "where the hell this came from?" :-) Zermes (talk) 01:19, 15 February 2019 (UTC)
@Zermes thanks, driving people crazy has never been my intention, and I think it should be fixed :). I added a gray "pencil" icon right after the description, but I am sure we could add more of those gray pencils or perhaps some other way? Which values specifically caused the confusion?
Clearly we should keep all infoboxes in sync between languages - otherwise it creates a lot of confusion between users - especially for the multi-lingual regions - e.g. if you are Switzerland, should you follow French, Italian, German, or English documentation? BTW, this doesn't mean that all regions should have the same rules - e.g. IIRC noexit=* should not be used on ways in Germany (but we may want to have a better way to document it rather than just using German language as the indicator). Currently we still have a per-language customization in data items, see Item:Q501#P34, but I hope we can get rid of them soon. --Yurik (talk) 01:51, 15 February 2019 (UTC)
P.S. @Zermes - amazing to see all PT items are gone! Only 2 remain - I updated the list. Do you know whom to ping about French? Thanks! --Yurik (talk) 02:10, 15 February 2019 (UTC)