Carnildo, thanks, totally forgot about this issue - I have easily found all affected items using relation["wikipedia"~"#"]["wikidata"]["admin_level"];
query. That said, these are not incorrect Wikidata IDs, they are simply less then accurate, and should be improved. The currently used Wikidata ID represents "all the topics as discussed in the linked Wikipedia articles". This is not very good, and should be improved by creating the more specific Wikidata IDs. I will work on improving them further.

oops, uploaded all instead of just poland ( which is the majority of these) :( Sorry about that.

SomeoneElse, yes, I am working on it. You can always reach me on IRC - "yurik".

@SK53, sorry not sure what you mean. I looked at Newton - osm.org/relation/6488382 - seems to be in order and matching the Wikipedia article. I couldn't find Netwon CP, only Newton Valence osm.org/relation/3344971 - if you think there is an error, let me know with links, I will try to fix it.

Sorry about this one, I meant to break it into smaller ones. All these are admin_level=6 relations with Wikipedia links being redirects.

@SomeoneElse, thanks, makes sense. I am trying to finish admin-level=6, whose leftovers are scattered around the globe. Do you know an easy way to select an area in JOSM, and from it select all participating relations? This way I can upload one area at a time.

My colleague helped me with this nice query - gets all of the admin/sub-admin/sub-sub... regions for any country. We could add some other fun things like geo coordinates for validation, or just compare with the names. https://www.wikidata.org/wiki/User:Yurik/Admin_regions

Btw, please comment there with your opinion. I am not personally too sure the legal argument has merit (referencing something by its ID vs copying a significant portion of the database - I suspect only later has the database legal protection in some jurisdictions, but IANAL), but the stability argument has been made repeatedly by many people. Plus having two way links are bound to create data consistency issues.

LOL :) https://www.wikidata.org/wiki/Wikidata:Properties_for_deletion#OpenStreetMap_Relation_identifier_.28P402.29 - i repeatedly said that property should be deleted, but some insist that it is needed because it is hard to do database joins (causing data duplication and ambiguity and mistakes instead) :(

Woodpeck, I have already stopped changing any objects except the admin levels regions 1-6, and even those I have greatly slowed down, and began reviewing most of the auto-resolved wikidata IDs. I will cease further automodifications, and instead concentrate on getting wikidata tags quality review for the admin levels.

Thanks, fixed. I will review all admin levels vs wikidata very soon - there is a lot more cleanup work to do, esp because there are some WD entries that represent multiple things.

fixed two more dups - osm.org/changeset/43815558 - the rest (957519,957520 - Barnby Moor CP, and 1976182,4077796,1976184 European walking route E2 - seems legit. We don't need to have a perfect 1:1 between wikidata and osm - just like WP links, multiple objects in OSM can point to a single object in WD.

P.S. posted my thoughts at https://forum.openstreetmap.org/viewtopic.php?pid=618646#p618646

SomeoneElse - https://forum.openstreetmap.org/viewtopic.php?pid=618646#p618646

I posted a long reply to https://forum.openstreetmap.org/viewtopic.php?id=56436 but it is pending moderator approval. I tried to explain both my method and reasoning. I simply locked the volatile Wikipedia link as a Wikidata ID - I have not touched the objects that did not have a Wikipedia tag already. Having a wikidata id on the object would allow it to be inserted into wikipedia article - https://www.mediawiki.org/wiki/Help:Extension:Kartographer#GeoShapes_external_data

Understood, I will mostly work on high level objects (admin level <= 6) - those are easy to check, and provide the most interest to me.

@woodpeck, thanks for the heads up! I was using the JOSM's Wikipedia plugin - "Fetch Wikidata IDs" command to lookup IDs for rels and ways which had Wikipedia tag already. In the process I also uncovered a number of plugin bugs, some of which are now fixed. The process was not automated - rather I would pull an area I was interested in using a query relation["wikipedia"]["wikidata"!~".*"]["boundary"]({{bbox}}); add WD tags, and upload just the WD changes. In any case, I will slow down on changes until the community agrees, and until the JOSM plugin resolves the pending bugs.

Hi, thanks for looking into it!
The first issue is really about Wikipedia vs Wikidata linking -- sometimes WP article covers both the village and civil parish, while WD item claims it is both, but it is really about just one meaning. Do we really want to link to both is an open question - IMO only WD link is needed, as it is more precise, and WP can be extrapolated from WD. On top of it, there are already tens of thousands of incorrect WP links in OSM, while WD is much more stable, making WD much more desirable.
In a way, having multiple rels with the same WD ID is not really wrong - because there is always 1:1 between WP and WD, so if there was a WP link, it implicitly had a WD link as well. Specifying a more exact WD is, of course, an improvement of the data quality that is clearly a goal.
Is there a way to query for multiple relations that share the same WD id? This would be useful to sort them out.

SomeoneElse, I fixed the first one - it should have had a different Wikidata ID, as well as a different (more prescise) Wikipedia link. osm.org/relation/195384 I cannot figure out why the second pair have identical WP and WD links, without being identical. The WP article doesn't give any details either.

SomeoneElse, thanks, good catch. I'm trying to get the Wikipedia and Wikidata tags in sync. Seems that the Wikipedia tag have been set to an identical value on both. I will investigate - maybe only one of them should have it?