Die 2 place-Node sind der typische Murks: sie sind nicht mit der zugehörigen Grenzrelation verbunden, sonder stehen “irgendwie” parallel dazu.
Wie man dies richtig löst, spreche ich im Forum immer wieder an, vgl. auch User:Jo Cassel/Gemeindegrenze - OpenStreetMap Wiki
Mit wikipedia + wikidata hat dieser ganze Murks eigentlich nicht zu tun.
Thats allright for (all) other OSM-Objekts, für example this building Relation: Reichstagsgebäude (2201742) | OpenStreetMap
with wikidata + wikimedia_commons + wikipedia (+ image from wikimedia_commons - unfortnuately without correct Tagging)
I am going to assume that answer is “no clear consensus, noone really cares about this specific topic, you can add either or neither but do not look for existing objects to for example add wikidata to wikipedia or add matching wikipedia to wikidata”
I’m not as experienced as @Jo_Cassel, so confined to the second issue:
“Schwarzenberg (Breidenbach)” is very bad. No one is using that. Well I know this one only for Schwarzenberg (Saarbrücken) – Wikipedia , the least important of the list of mountains with this name. It’s just the same for two villages with the same name like “Eiweiler”
But it would be different in the case of “Neustadt an der Weinstraße”, that’s the official name.
Meine Erfahrung: wikidata dient primär wikimedia, weil es in den wikimedia-Projekten die Einbindung passender Geodaten ermöglicht (was ich völlig ok finde und unterstütze).
Von wikipedia, wikimedia_commons + image dagegen profitieren die OSM-Daten und ihre Nutzer unmittelbar.
Will sagen, wenn ich z.B. einen “Beispielberg” um wikimedia-Tags ergänze, dann recherchiere und nutze ich alle Passenden - das ist für mich handwerklich sauberes Arbeiten
(und die konkrete Lemmatisierung, die (Klammer-)Schreibung des passenden Wikipedia-Artikeltitels ist dabei völlig wurst).
Personally, when adding tags linking to Wikimedia I prefer using wikidata and think that wikipedia is not necessary. I assume that this thread’s question also extends to the use as suffix (e.g. artist:wikidata, operator:wikidata, …).
wikidata:
Stable: (As long as no user on Wikidata has made a mistake) Items are not repurposed and their Q-IDs are not changed. They are also less likely to be deleted than Wikipedia articles due to less strict notability criteria.
Unique preferred identifier: There’s exactly one preferred identifier. In contrast, the values of wikipedia referring to the same concept might differ depending on the Wikipedia language edition linked to (e.g. de:Paul Schneider (Künstler) vs. en:Paul Schneider (artist)). Items on Wikidata might be merged into other ones and in this process converted into redirects, but this can be checked for by QA tools or bots and affected values can replaced with the redirect’s target.
Easier to query: It’s easier to use TagInfo (though, it would be great if it were able to natively resolve Q-IDs and display their label), Overpass and Sophox with wikidata
Wikimedia’s Map-service, which is for example used for drawing geolines in Wikimedia-projects only supports wikidata and I highly doubt that it would be feasible to also support wikipedia due to the shortcomings mentioned above.
Superset: There are many more Wikidata items than there are Wikipedia articles and (at least for the German language edition) every article has an associated Wikidata item.
When linking OSM elements to Wikimedia projects I typically only add wikidata because wikipedia can be easily inferred from it by bots. However, I do not think that it would be worthwhile to add wikipedia (not even automatically) due to the redundancy.
// Heads-up: I’m a Wikidata contributor so obviously I’m somewhat biased.
Unique preferred identifier: There’s exactly one preferred identifier. In contrast, the values of wikipedia referring to the same concept might differ depending on the Wikipedia language edition linked to (e.g. de:Paul Schneider (Künstler) vs. en:Paul Schneider (artist)).
you can have only one wikipedia article for a wikidata item (and language), and IIRR every article can be linked only once, so you might end up with wikidata items that are dealt with in a wikipedia article but it cannot be linked.
People (as many wd examples go) are quite easy compared to things in the world, like a church or museum (institution, building, site?) or a city (administrative or socio-cultural?) and you can expect that there will be several items (rightfully) for what is all dealt with in the same wikipedia article (and also the other way round, Berlin during the Nazis will have its own article and if will also refer to berlin as wikidata object, maybe not directly), while it doesn’t happen with people. I guess there are ways around this in wikidata by relating objects to another but more often it seems wikidata objects are deemed to remain strongly related to wikipedia articles because they have grown like this and it would be too much work to separate them and somehow destroy the “order” of 1:1 relationship
In this case one would normally link the Wikidata item to a redirect page. E.g. there’s a Wikipedia article „Amtsgericht Beispielingen“ which mainly covers the eponymous court but also has a section about the „Amtsgerichtgebäude Beispielingen“ that it is located in (quite common in German Wikipedia). In Wikidata, there should¹ be two items: one for the court and one for the building. The former item would link to „Amtsgericht Beispielingen“, the latter to „Amtsgerichtgebäude Beispielingen“ which is a redirect to „Amtsgericht Beispielingen#Gerichtsgebäude“.
However, you are right that as of now there’s not always a redirect page in Wikipedia which can be linked to the Wikidata item (and I’m not sufficiently familiar with the individual Wikipedia communities’ stances on creating them for Wikidata purposes). So wikipedia tags linking to sections (i.e. include #) are not always replaceable with wikidata. I’m not too sure about the extent to which links to sections are desirable in OpenStreetMap as they are even less stable than article names and if sections are renamed or removed this can only be reconstructed by looking through the article history (in contrast, article moves and deletions are easier to reconstruct since they are recorded in a separate log).
¹ Courts and their buildings are quite often conflated due to various botched imports but are slowly untangled and split into two items.