Changeset: 52344210
auto-matching wikidata tags based on wikipedia tags per @talk discussion. Further cleanup will be done using https://wiki.openstreetmap.org/wiki/Wikidata%2BOSM_SPARQL_query_service
Closed by nyuriks
Tags
created_by | JOSM/1.5 (12712 en) |
---|---|
source | wikidata |
Discussion
-
Comment from SomeoneElse
Here you added https://www.wikidata.org/wiki/Q2407197?uselang=en-GB to https://www.openstreetmap.org/node/598000917 (which is correct). Are you now going to remove it from https://www.openstreetmap.org/relation/957593 which you did in error in https://www.openstreetmap.org/changeset/44200317 which was the issue that I raised with you 10 months ago in https://www.openstreetmap.org/changeset/43749373 ?
Note that error likely applies to every change in that changeset. -
Comment from nyuriks
Andy, are you saying that neither Q2407197 nor en:Tibshelf should be attached to rel 957593 ? It the WD item is correct for both - it is both the city and the parish.
-
Comment from SomeoneElse
(re Tibshelf) as of 12 days ago it does now claim to be both a village and a civil parish; only 10 months after you added the wikidata entry to the relation.
Can you guarantee that all similar errors in wikidata have been similarly corrected? -
Comment from nyuriks
SomeoneElse, I cannot guarantee anything. Ever. I can only attempt to find existing errors in the data and expose them. So far, thanks to my efforts, thousands of major errors have been corrected. As I numerously stated, and you chose to ignore -- wikidata ID is simply a more permanent wikipedia ID, representing the same article. The wikidata item does not have to have ANY statements. None. And it would still be a valid ID, because it represents the same WP article. If it has an instance-of, it is a bonus. In some cases, there may be a more precise wikidata ID, but having a more generic one is not an error. At this point, I feel we are having endless debates over a non-issue. If you feel otherwise, lets set up a video hangout, possibly with others, and attempt to resolve it, rather than talking past each other.
-
Comment from SomeoneElse
> , thanks to my efforts, thousands of major errors have been corrected
You keep saying this. Can you provide a list? I've seen very few fixes to OSM data in these changes.Also, if wikidata and wikipedia IDs both identify the same object why add both? Just leave the human-readable one in OSM.
-
Comment from nyuriks
https://commons.wikimedia.org/w/index.php?title=Data:Sandbox/Yurik/OSM_objects_pointing_to_disambigs.tab&action=history -- every revision had entries that community fixed. There are many other places, but this is the easiest to show. Lately, people fixed it directly from my service. When first ran, disambig count was near a thousand, it dropped to 400, and later raised back to 800 with the newly discovered errors. I believe this is more than plenty of proof, but you are welcome to create a list if you want.
Your second argument has been refuted and explained ad nauseum on the @talk in multiple discussions of why this is a bad idea by multiple people. Not going to explain it again.
-
Comment from SomeoneElse
Re "every revision had entries that community fixed." I've not sure what that table shows, presumably a "disambig" is a wikipedia thing that we are supposed to know about in OSM? Do you mean wikipedia disambiguation pages where one word can have multiple meanings? My problem with "the community fixed this" is that could actually have been doing useful mapping instead - like mapping things not yet in OSM at all.
Re "explained ad nauseum" - you still haven't persuaded everyone to your argument (hence I presume the comment from someone on talk today about you "ramming things down people's throats").
OSM is a collaborative project; we need to work together and we can't just impose our views on other people who don't agree. We need to persuade, and you are failing to do that.
I'd suggest that you take a step back, take a break and let things settle for a while. Perhaps actually go outside and map something in the real world? -
Comment from nyuriks
You misunderstood. I used MediaWiki & Commons to store errors that I found in OSM. There were several people who went there to fix uncovered issues. Also, realize that there are plenty of people who gave up arguing - see last discussion https://wiki.openstreetmap.org/wiki/User_talk:Yurik Another point - I don't think adding crappy new edits manually is more important than keeping good data. I prefer less but better quality. And again - I have data to proove that it WAS bad quality, and now it has been improved. So perhaps visit my wikipedia improvement page and fix a few issues? Lastly, it is impossible to persuade everyone, especially for such a large community. And it doesn't need to.
-
Comment from SomeoneElse
> There were several people who
> went there to fix uncovered issues. ...
> https://wiki.openstreetmap.org/wiki/User_talk:Yurik
Based on the people who've edited that that'd be 2 people? Also comments there include "I would really advice to stop pushing for worldwide mechanical edits. It is obvious that people are really unhappy with that idea".
It is clear that you have not persuaded the community to your way of thinking.
- Derby (12009324), v10
- Kegworth (12815723), v9
- Maltby (13883499), v11
- Kirton Lindsey (21640818), v11
- Gainsborough (21641028), v5
- Lenton (26606697), v8
- Radford (26606698), v8
- Beeston (26606699), v7
- Bramcote (26606700), v8
- Bramcote Hills (26606701), v8
- Plumtree (26955537), v4
- Clifton (26983458), v4
- Ratcliffe-on-Soar (26984295), v7
- Breaston (26984344), v4
- Stapleford (26984573), v9
- Sandiacre (26984574), v7
- Chilwell (26984575), v9
- Stanton by Dale (26984576), v5
- Ilkeston (26984577), v9
- Louth (26984645), v4
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |