Also, there are almost 2,000 nodes without wikidata. Most likely, this is because wikipedia tag is broken, and might need to be removed. See them on a map.
MKnight, try this view - it should simply show you the map with all the dots. Zoom in and click on any of the dots - any you will see the object ID and some more information. Also, if you want, in the bottom right corner, there is a drop down to switch map into a table - similar to a list as before. Let me know if its easier. Thanks!
P.S. The old list had to be refreshed by hand. This tool’s data is updated every minute, and has many more capabilities.
MKnight, very sorry, I posted the wrong link above (fixed). The old query was for missing wikidata tags (also needs fixing). The disambig query is this one
Yes, the discussion is heated. On one hand, there are “data purists” - a conservative group of people who do not want changes. On the other, there are “progressives” - people who want to improve the system because they see benefit in innovation. The third group has not spoken yet - the data consumers. Data consumers have already expressed huge interest in Wikidata, but I think they feel they are not part of the community, and don’t want to speak up. Heh, it is getting a bit political
Not sure if this is an adequate summary of the discussion so far. Even folks who you call “conservative” haven’t expressed outright opposition to adding Wikidata tags, but object that large style kind of “(half-)automated dumping of wikidata tags into OSM” approach.
Yes right, it totally makes sense from a Wikimedia pov. It’s not at all clear if OSM benefits in a similar way by adding Wikidata (as an example see the points raised by Simon). The main reason, why I find OSM very interesting is because of all the geospatial data, less so, because there’s a wikidata link. I guess you really need to make your data consumers speak up, and present some of their compelling use cases. So far, really none of those I’ve seen made me think “wow, that’s pure awesome”.
Man sollte erwähnen, dass die Seite von nyuriks ziemlich nützlich ist, wenn man falsche Wikipedia-Tags entdecken und korrigieren möchte. Das kann man machen, ohne sich Gedanken darüber zu machen, ob wir wikipedia=* oder wikidata=* in unserer Datenbank haben wollen oder beides.
Wenn unser Node Georgenstein zur Wikipedia-Begriffserklärung Georgenstein verweist, dann ist das einfach falsch. Mit ein bisschen Wissen oder Recherche ist das aber schnell zum richtigen Georgenstein (Isar) und dem passenden Wikidata-Eintrag (sieht man links in der Spalte bei Wikipedia-Einträgen) umgebogen.
Wer das macht hat auf jeden Fall die Datenbank verbessert, ganz unabhängig von der Frage, ob wir die Tags überhaupt brauchen. Eines der beiden Tags kann man dann später immer noch löschen, wenn man das unbedingt will. Falsch waren vorher beide, danach sind beide richtig.
@mmd, hehe, agree, “conservative” is over-simplified definition I was simply referring to a general trend in all communities - you have those that want change, the faster the better, and there are those who want to slow down changes or possibly even reverse to the good old times. And often the same person can be on the different sides for different issues.
As for Wikimedia - to be honest, i have no clue how Wikimedia would benefit in a direct way from any of this. I know for a fact that at least two very well known OSM data consumers are using Wikidata to augment OSM data. Their primary interest is in multilingual labels, as that is the simplest thing to extract. (disclosure: while I was formally employed by WMF, I no longer am, and I do not support a lot of things they are going)
Mal ne Frage, die sich mir beim Thema stellt, es gibt POis, wo mir nicht ganz klar ist, ob die (wikipedia)disambiguish-page sinnvoller ist, als gar keine Seite.
An 'nem Beispiel: https://de.wikipedia.org/wiki/Jamel
Hier gibt es mehrere Optionen:
I would suggest “something else” – e.g. “related:wikipedia” tag. I think that whenever wikipedia doesn’t have a good entry, but there is some other page related to it, use the related:wikipedia & related:wikidata tags. Related wikipedia page may have a section about the object. Or it could be a list, or a disambig.
Schade, dass ausser Juri (thx!) sich keiner geäussert hat. Moment, keiner? Die Wochennotiz hat was:
Hierzu möchte ich verschiedene Dinge feststellen:
Ich hab die Diskussion nicht gelesen, da mein Englisch nicht sonderlich gut ist. Aber ich verstehe im Groben worum es geht;
ja, das mechanical Edit ist suboptimal, da es Unmengen an Fehlern in OSM hereinbringt [1]
nein, das mechanical Edit ist nicht suboptimal, da es Unmengen an “Fehlern” in OSM durch diesen Holzhammer überhaupt erst sichtbar UND korrigierbar macht.
es gibt eine parrallele Diskussion zum Thema, die ich mal wieder überhaupt nicht verstehe: https://forum.openstreetmap.org/viewtopic.php?id=59910 hier geht es wie in zig ähnlichen unsäglichen Diskussionen darum, irgendwelche Tags (hier wikidata) als überflüssig bis unnütz zu brandmarken. Ich halte diese wie auch ähnliche Diskussionen für zeit-und kraft-bindend. Der typische Wikipedia-Relevanz-scheiss. Jeder (Pro-)Aktivist bringt seine persönlichen Hassvorlieben ein und am Ende wurde viel diskutiert ohne Ergebnis und ohne Relevanz (oder im schlimmsten Fall mit einem “Konsens” zum Löschen unbeliebter Tags). Das brauchen wir in OSM unbedingt auch noch!!11eins
[1] das halte ich allerdings für legitim, da es die Korrekturen einfacher macht. Versions/History-aufblähdingsi etc.halte ich für mimimi. Juri hat sich in der Vergangenheit immer um Öffentlichkeit und Mitstreiter bemüht, so dass Probleme der Art innerhalb kürzester Zeit behoben wurden. Klar kann man das vielleicht mit den 3 Hanseln bei Maproulette etc. auch erledigen, aber nicht in der Qualität und Quantität.
Dein Fähnchen dreht sich auch irgendwie im Wind so wie es dir gerade passt.
Ich erinnere mich an eine Aussage, dass man einzelne Fehler nur beheben darf, wenn man das gesamte im Blick hat und alle Fehler eines Objekts erkennt. Es wäre als Mapper unsere zentrale Aufgabe.
Weder Import nach nachgehende “Korrektur” können hier den Anspruch halten.
Mein Argument damals war, dass etwas fehlerhaftes, unsichtbares durch die Fehlerkorrektur ja erst sichtbar wird. Jetzt ist es auch dein Argument, auch noch gleich für Automatische Edits, wow. Wir lernen anscheined alle dazu.
Ähnlich interessant finde ich auch diesen Fall. Dort wurde anscheinend in Wikipedia etwas aufgegliedert was eigentlich einen Oberbegriff hat. In dem Fall wäre die Seite also irgendwie auch korrekt.
Vielleicht sollte man da auch unterscheiden zwischen “related” und “noch nicht vorhanden”.
Bei ersterem fände ich die Variante von nyuriks nicht schlecht, weil man so auch direkt auf Seiten verweisen kann wo der Punkt vielleicht nur ein Unterbegriff ist. Dessen Bedeutung dürfte auch nicht vergehen, selbst wenn dann eventuell ein direkter Verweis auf einen bestimmten Artikel dazukommen sollte.
Zweiteres ist murks, da hilft einem dann meist die disambiguation page auch nicht. Außer wenn es dann vielleicht irgendwann angelegt wurde.
(ja ich weiss, das kann man sich auch aus dem Query holen, nur wenn die aus dem Query verschwinden, wäre es bspw. interessant, wie das jeweils gelöst wurde)
#/media/File:Grevesm%C3%BChlen-cap-arcona-friedhof-umfriedung.JPG){kind=link}