User talk:Yurik

From OpenStreetMap Wiki
Jump to navigation Jump to 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 https://osm.wikidata.link/ 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 http://88.99.164.208 using API? https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/Wikidata_Query_Help/Result_Views 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 http://88.99.164.208/bigdata/sparql 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
WHERE
{
  ?item wdt:P625 ?location.
  MINUS { ?location wdt:P31/wdt:P279* wd:Q1190554. }  # excludes events
  SERVICE wikibase:label { bd:serviceParam wikibase:language "en". }
}
LIMIT 10

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
 WHERE
 {
   ?item wdt:P31 wd:Q486972.
   FILTER EXISTS  {
 		?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 https://www.openstreetmap.org/node/1589969137#map=19/53.97112/14.54503 and https://osm.wikidata.link/Q673875 (I checked lack of matches with http://overpass-turbo.eu/s/rGW )

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 - http://www.openstreetmap.org/user/Mateusz%20Konieczny/diary/42385 https://github.com/matkoniecz/OSM-wikipedia-tag-validator. 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 - https://github.com/nyurik/osm2rdf --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 https://blog.mapbox.com/support-for-arabic-and-portuguese-in-mapbox-streets-5a9690dabff4) Mmd (talk) 06:53, 3 October 2017 (UTC)

Change of parser limits

Hi Yuri,

Thank you for openstreetmap/chef/commit/6694697e2851ac362546d34cf12f146633be3782 GitHub. I found it by accident, it would have been nice if you would have posted that at Talk:Wiki or at https://forum.openstreetmap.org/viewforum.php?id=52. 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)

Translations

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)


Yurikbot

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

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)

KeyDescription

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
<image_caption text>
Description
<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

https://wiki.openstreetmap.org/w/index.php?title=Item:Q6634&diff=1725192&oldid=1724953 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)
For example, most of the time the confusion happens on images in the template. If we remove the image, the template shows one image from somewhere. But that's not a big problem. Most of the time the existing image it's fine and shouldn't be changed. By the way, one of these days we should remove the "description=" field completely in ValueDescription template on pages (not in the template itself), right? Because we have now the same text duplicated in 2 pages, for example in Pt:Tag:amenity=table and Item:Q5823. That leads to confusion. About French it seems I got late here, User:Fanfouer took care of that. Zermes (talk) 20:06, 12 March 2019 (UTC)
The remaining page descriptions in "pt" are fixed. By the way and just for curiosity, any plans to get rid of all fields on pages of ValueDescription template? For example the actual situation to entering data in all languages about if a tag is applied to node, area, relation... is nonsense, this info should be in wikidata/item or something like that (one of these days I will try to understand those pages...). Zermes (talk) 20:25, 12 March 2019 (UTC)
@Zermes: we can make specific image to appear for a specific language (e.g. see traffic_sign (Q2090) (P4)). The image description could also be moved to the data item using a monolingual string (same as we use to link data items to wiki pages -- traffic_sign (Q2090) (P31)). Yes, I do hope we move all of the {{KeyDescription}} parameters to the data items, and iD editor already uses it directly, but unfortunately TagInfo still scans wiki page directly to try to get the info out. I hope someone could update TagInfo to stop scraping wiki markup, and use data items instead. --Yurik (talk) 20:41, 12 March 2019 (UTC)

Yurikbot "Tag template cleanup"

Hi Yuri, I looked at some changes from your recent bot run and would like to offer some criticism:

  • I believe that edits such as [2][3][4] which produce no visible change and don't meaningfully simplify the source code should be avoided. They inflate a page's history for little benefit. Doing that alongside other edits would be ok, but several dozen of your bot's recent edits only remove vertical bars after a key.
  • I'm not sure that all links to key and tag pages should use {{Tag}}. I would use the tag template when talking about a tag, but the page title when talking about the page itself. I haven't noticed any changes by your bot where this distinction mattered, though.

There's no need to go back and change anything, but maybe you can consider these concerns in the future. --Tordanik 17:55, 4 March 2019 (UTC)

@Tordanik: thanks for the feedback! Sorry for the spam - I am doing multiple minor cleanups at once, and sometimes a tiny change like that slips through. I do try to make all relevant changes at once, but I am also a bit hesitant to do too many changes at the same time using a bot -- if it makes a mistake, I can easily track it down and revert. Combining too many changes at the same time could result in some hidden mistakes that might slip through. (Note that I review every change the bot makes by watching the change log).
WRT {{Tag}} -- I mostly do it to fix translations and readability. Some links like [[FR:Tag:something=else]] are hard to read (they really should be something=else without the "FR:Tag"). But the bigger issue is that when a page is translated, people will often forget to change the link (making them point to English), or they will change them to a translated page even if that page does not exist - e.g. from [[Key:something]] to [[DE:Key:something]]. You could keep an eye on all such links by hand to make sure they exist, point to English when they do not, and update it when the target page is translated, it is far simpler to always use either {{Tag}} or {{TagKey}} - making the links automatic, and always pointing to either local or English.
See mycurrent replacements (lots of regexes :) ). --Yurik (talk) 18:30, 4 March 2019 (UTC)

Template Deprecated

See Tag:shop=baby care - it is not supporting new linking syntax in the ambox warning ("This feature has been labeled as deprecated. The recommended replacement is: tag:shop=baby_goods." in red box) but bot edited it anyway Mateusz Konieczny (talk) 21:58, 27 March 2019 (UTC)

Thanks @Mateusz Konieczny:, will fix. TBH, I didn't even realize that text at the top contained the new tag information - the text in the infobox typically gets most of the attention. We might want to even simplify it, or make it reference the infobox. But I will fix it regardless. --Yurik (talk) 22:34, 27 March 2019 (UTC)
Thanks in advance for fixing it! Mateusz Konieczny (talk) 22:49, 27 March 2019 (UTC)

Videos on YouTube

Hi Yurik, would you mind licensing your videos on YouTube under a free CC license? I'd like to reupload them to Commons, as they are useful and in-scope for that project (and can be embedded and watched here directly, without external links). Pizzaiolo (talk) 04:26, 29 March 2019 (UTC)

@Pizzaiolo: thanks! I haven't realized YouTube supported CC-BY. Changed on all of them, and set the defaults so I won't forget the next time. --Yurik (talk) 04:54, 29 March 2019 (UTC)
@Pizzaiolo: P.S. could you also upload this one? We are actually using it in Sophox page. Thanks! --Yurik (talk) 04:56, 29 March 2019 (UTC)
Here you go! 1 2 3. If you're inclined, you can upload them to Commons as well in the future, or simply reupload them with this simple tool: https://tools.wmflabs.org/video2commons -- Cheers! Pizzaiolo (talk) 14:51, 30 March 2019 (UTC)
Huh, I just noticed this wiki doesn't show videos. Do you know what can be done about that?
Pizzaiolo (talk) 00:09, 31 March 2019 (UTC)
@Pizzaiolo: I think we need to add TimedMediaHandler extension. --Yurik (talk) 00:21, 31 March 2019 (UTC)
P.S. I just filed a request for it - please +1. --Yurik (talk) 00:33, 31 March 2019 (UTC)
Awesome, thanks! Pizzaiolo (talk) 00:59, 31 March 2019 (UTC)

Tags placed by mistake

Hi, thanks for the comment. Right now I am removing the labels that I had placed by mistake. Regards! --Nahu FF (talk) 05:40, 30 March 2019 (UTC)

Clearing items

Hi! Edits done by the bot like this and this are probably something we want to avoid. Pizzaiolo (talk) 00:26, 1 April 2019 (UTC)

@Pizzaiolo:, ah yes, those are the nasty ones I need to figure out how to avoid. The issue is that you created those data items by hand, so when the bot analyses the history of the item to see what parts of it was changed by users, it does not see that you added a description or label in language X, so it assumes that it was bot itself that added it, thus it can be removed. The fix is fairly straightforward - add or modify description after you create the item, or better yet - lets figure out how we can make bot create these items for you, and then add whatever info is needed. --Yurik (talk)
@Pizzaiolo: P.S. undoing bot edit is not enough -- it will simply do it again. Instead, just copy/paste the description you want using the regular data item description editor - then it will never be overwritten. Also, you can always reach me on OSM Slack (as @nyurik). --Yurik (talk) 01:32, 1 April 2019 (UTC)
Perhaps as a workaround, you can tell your bot not to overwrite anything when there is no wiki article, only a data item. Might be a good temporary fix. Pizzaiolo (talk) 01:50, 1 April 2019 (UTC)

Useless image

Probably edit like https://wiki.openstreetmap.org/w/index.php?title=Item:Q115&diff=1835541&oldid=1831312&rcid=&curid=205779 can be run automatically across entire Wikidata Mateusz Konieczny (talk) 08:09, 8 April 2019 (UTC)

Requirements for bridge:movable

Hi Yuri, your bot added a requirement for bridge=movable to the bridge:movable data item, and you manually followed up on that by removing it as a combination. Where did the bot source that information from? I believe it's incorrect, as the introduction of the English Key:bridge:movable page explicitly says that "this key may be used without tagging bridge=movable, to indicate a formerly movable bridge that has been fixed shut". This sentence was also part of the approved proposal. --Tordanik 17:58, 11 April 2019 (UTC)

@Tordanik: great catch! I saw it in DE:Key:bridge:movable and thought that DE was more up to date, but it seems it is incorrect (updated). I rolled back all the other languages. The bot should auto-update things within the next few minutes (it now runs all the time, monitoring the recent changes). --Yurik (talk) 18:57, 11 April 2019 (UTC)

Deletion policy

Dear Yurik,

We would like to invite you to voting in the case of the proposed Deletion policy for wiki pages and files. Based on the input of several contributors, we drafted a deletion policy over the span of two and a half months. Among other things, the policy proposes a centralised discussion page for all cases which are not mentioned explicitly.

Kind regards, EzekielT

PS: I wrote this message on your talk page, because you were mentioned in a long dispute about deleting in 2018 and 2019 which now led to this policy draft. — EzekielT (talk) 21:11, 16 April 2019 (UTC)

leisure=park discussion issues

Hi. I'm not sure if your the right person to discuss this with, if not just let me know and I'll contact another admin or something, but I'm being harassed by another user on the discussion page for leisure=park. So, I was wondering if you could step in as admin and tell the user to follow the etiquette rules. Since my repeated requests for him to have fallen on def ears. His user name is Stevea. Aside from repeatedly trying to control the perimeters of the discussion, he's also brought up my spelling issues that are due to a learning disability when I said repeatedly I didn't want to talk about it, he also called me an arrogant autocrat simply for asking the question. I'd appreciate it if maybe he was encouraged to not participate in the discussion anymore. Since I already know what his opinion about the topic is and I'd like other people to not be turned off from commenting because of his endless screeds. Name calling really isn't OK either. I'd like the overall discussion to be more civil then he's acting. Thanks. --Adamant1 (talk) 06:03, 19 April 2019 (UTC)

Feedback request

Can you look at https://wiki.openstreetmap.org/wiki/Template_talk:ValueDescription#How_one_may_hide_unwanted_image_description and https://wiki.openstreetmap.org/wiki/Template_talk:ValueDescription#Where_this_template_may_be_edited.3F ? Template that you last edited is a bit broken and I was unable to even locate its code Mateusz Konieczny (talk) 16:56, 29 May 2019 (UTC)

Apparently incorrect bot edit

https://wiki.openstreetmap.org/w/index.php?title=Item:Q112&diff=1861052&oldid=1835539 Mateusz Konieczny (talk) 10:12, 14 June 2019 (UTC)

thanks, reverted, debugging... --Yurik (talk) 12:34, 14 June 2019 (UTC)

Redirections and Data items

Hi,

I would like to discuss two recent reverts [5] and [6]. I think that they created the following problems

Both pages are redirects and now contain text.
I consider this bad, because people will miss the information there. Either the information is available on a page without a redirect or there should be no information apart from the redirect. The current situation is confusing to me.
The edit was applied inconsistently.
The English and Russian version feature information, but the German and the Czech do not? They are plain redirects.

What did you intend? Is this related to the Yurikbot updating Data items? --Tigerfell This user is member of the wiki team of OSM (Let's talk) 10:01, 16 June 2019 (UTC)

@Tigerfell: I agree that we should remove these pages, but only after we fully migrate to the data items. In the mean time, there are hundreds of redirect pages that also contain a {{KeyDescription}} or {{ValueDescription}} pages. The main blocker for migration is the taginfo - it is still parsing wiki pages directly, instead of using the data items. Also note that currently if you remove a description from a page, it will be removed from the data item automatically - this is something I will need to stop doing at some point. --Yurik (talk) 13:37, 16 June 2019 (UTC)
Okay, I see. My judgement might be wrong, but reading taginfo/taginfo/issues/248#issuecomment-424641549 GitHub I would rather say that the Taginfo people are not that interested in including Data items in their system. --Tigerfell This user is member of the wiki team of OSM (Let's talk) 07:00, 17 June 2019 (UTC)
@Tigerfell: "community acceptance" is a complex term :) that comment was made almost a year ago, and since then there were tens of thousands of community edits by over 50 individuals, so I guess that question has been settled :). The bigger question is when it will get implemented, and by whom -- I'm not a ruby expert :(. Also, as of today, we now have all the redirect info in the data items, closing the last piece of missing info in the data items vs taginfo stuff. --Yurik (talk) 18:10, 17 June 2019 (UTC)
I am one of 50 people who edited items, and it should not be interpreted that I support them. Mateusz Konieczny (talk) 20:43, 18 June 2019 (UTC)

Duplicate data item, remove or change site-link procedure? Is Yurikbot not checking for existing tags while data-item process?

Hi Yuri,

it seems I was faster than your bot by creating a manual data item, but your bot was faster than me to set a site link. The whole story:

  • I created a new wiki page [1] and instantly afterwards I created a corresponding data item [2]
  • Later on I did add several P's to this data item [2]
  • As a final step, I tried used the function [4] to link [2] to the wiki page [1]
  • But I got a wiki-system error, because the wiki page [1] was already linked to another (your the bot created it) data item [3]

Why did your bot not check, if there is already an existing item for "traffic_sign=DE:274.1" (maybe even not site-linked yet) available, during the data item creating process of data item [3]?
I couldn't manage to change the site-link of wiki-page [1] from item [3] to item [2]. Is there any way to do that?
Now there are two data items for the same tag "traffic_sign=DE:274.1". How is the procedure to delete one of them?

--MalgiK (talk) 17:29, 30 June 2019 (UTC)

Hi @MalgiK:, thx for the thorough report :) The bot uses sitelink as the ID of the item - so in a way it did check that there are no conflicting data items, it just didn't see it as a conflict. It does run through all the data items to fix them a few times a day, e.g. to fix the missing sitelinks. In this situation, I guess it did not know that the data item you created was for that key, so it went ahead to create a dup -- this is not that big of a deal - I simply used Special:MergeItems to redirect both IDs to the same data item. Usually, it is best to let the bot create data items, and simply modify (i.e. translate) them afterwards. Any properties/values you edit by hand will never be updated from the wiki pages. --Yurik (talk) 19:01, 30 June 2019 (UTC)

Is Yurikbot source code available?

At least part that updates data items? So in case of bot going down (happens with basicaly all bots run by individual) Wikidata items can be still updated based on Wiki edits? Mateusz Konieczny (talk) 08:05, 5 July 2019 (UTC)

@Mateusz Konieczny: metabot is the correct link. The update_data_items.py starting point is ran automatically on the sophox server (but could ran anywhere). The metabot subdirectory contains all of the components. Feel free to add it to the Data items if you think it should be there somewhere. Thanks! --Yurik (talk) 10:24, 5 July 2019 (UTC)

Is Yurikbot running?

Yurikbot hasn’t updated anything in a week. Is it still going? --Andrew (talk) 19:21, 26 July 2019 (UTC)

Thanks, I restarted it. --Yurik (talk) 01:23, 29 July 2019 (UTC)

Yurikbot isn’t running again. --Andrew (talk) 14:37, 19 January 2020 (UTC)

Yurikbot has made no edits for a week. --Andrew (talk) 20:16, 6 July 2020 (UTC)

Yurikbot appears to be permanently down ( https://wiki.openstreetmap.org/wiki/Special:Contributions/Yurikbot ) Mateusz Konieczny (talk) 16:37, 9 December 2020 (UTC)

Thanks!

Thanks a lot for setting up and running the update bot. I really like the way data items are integrated and enhance our structure.--PangoSE (talk) 09:24, 18 November 2019 (UTC)

ValueDescription, data items, Category:Mismatched onRelation and user pages

It seems that one of your edits created Category:Mismatched onRelation. It seems useful, I tried fixing some problems already. But would it be possible to exclude user pages from it? Mateusz Konieczny (talk) 11:21, 17 January 2020 (UTC)

It is possible -- https://wiki.openstreetmap.org/wiki/Module:DescriptionFromDataItem has a function getCategories which could return nil if there are no categories to be added - e.g. if the current page is not in the main or language namespace (like DE:, FR:, etc). This could be determined in the constructor function, where it parses the current title using Module:OsmPageTitleParser. While this probably should be fixed, I see there are only 3 items like that - so not a significant issue just yet (I'm not against it, just might not have time soon to address it). --Yurik (talk) 22:41, 17 January 2020 (UTC)
It is not a huge problem, but I want to empty this category :) Mateusz Konieczny (talk) 22:43, 17 January 2020 (UTC)

Source of Q10919 item (key:hgv_75) creation

For details see here: https://wiki.openstreetmap.org/wiki/Item_talk:Q10919#Source_for_item_Q10919_? --MalgiK (talk) 22:32, 21 January 2020 (UTC)

invalid "implies" claim

https://wiki.openstreetmap.org/w/index.php?title=Item:Q5822&diff=1833105&oldid=1829604 - why this bot added invalid "implies" and claimed that it comes from wiki page? It is not coming from the Wiki page Mateusz Konieczny (talk) 09:54, 28 December 2020 (UTC)

Yurikbot

Would it be possible to revive Yurikbot? Because updating data items manually is neither easy nor pleasant. Actually, only editing descriptions manually is reasonably fast, but e.g. hardly anyone adds a link to a newly created page. maro21 21:40, 28 April 2022 (UTC)
@Yurik: Would it be possible to run the bot? maro21 22:08, 21 May 2023 (UTC)

data items

Proposal:Documentation of key prefixes & suffixes has been approved, so please:

  • create a Property for "permanent key prefix ID"
  • create a Property for "permanent key suffix ID"

? See https://wiki.openstreetmap.org/w/index.php?title=Wiki:Requests_for_administrator_attention&oldid=2385432#Proposal_followups where it was requested

Mateusz Konieczny (talk) 06:30, 3 September 2022 (UTC)

Retrieved from "https://wiki.openstreetmap.org/w/index.php?title=User_talk:Yurik&oldid=2529962"