ArchivübersichtEdit

Tipp Wondreb-Aue (Q28924855)Edit

Wenn du dich bei den "VIP-Bezeichnungen" vertippt hast oder auch wenn ein Gebietsname geändert wurde, kommt ja vor: Man kann in der history auch den Eintrag nehmen, in dem die ganzen Labels ergänzt wurden [1] und auf einen Schlag rückgängig machen. Geht schneller udn meistens bleiben dann nur ein, zwei Labels übrig, die man noch einzeln ändern muss (die Sprachen vom Anlegen des Items). Holger1959 (talk) 04:46, 14 March 2017 (UTC)

@Holger1959:, danke die Idee hatte ich auch als ich etwa schon die Hälfte der Änderungen durch hatte ;)--Derzno (talk) 07:43, 14 March 2017 (UTC)

GeoNames-IDsEdit

Hallo :)

Ich hab die GeoNames-IDs von Steinbrüche am Schmausenbuck (Q54759745), Steinbruch nordöstlich von Happurg (Q54811125), Steinbruch in der Flur Kesselgrub (Q54811129) und Huberfelsen in Alfeld (Q54811159) entfernt, weil sie keine gültigen GeoNames-IDs sind. Ich weiß leider nicht, was die richtige Eigenschaft dafür wäre. Wenn es noch keine passende Eigenschaft gibt, kann man einen Vorschlag unter Wikidata:Property proposal machen.

Einen kleinen Hinweis noch: Das erste Wort der Beschreibung sollte nur großgeschrieben sein, wenn das Wort normalerweise großgeschrieben ist (mehr dazu unter Help:Description).

- Nikki (talk) 17:51, 26 June 2018 (UTC)

Danke für deine Aufmerksamkeit. Es war nur ein Flüchtigkeitsfehler und hätte eigentlich zu "Bayerische Geotop-ID (P4266)" gehört. --Derzno (talk) 04:22, 27 June 2018 (UTC)

DupeEdit

Hallo Derzno, haben wir schon im Sortiment: Q58462630 = Q30539488. Gruß, --Achim (talk) 18:07, 11 November 2018 (UTC)

Achim danke für die Info, ist "merged". --Derzno (talk) 18:26, 11 November 2018 (UTC)

Kraftshofer Forst (Q59528003)Edit

Leider hast du bei deinem Import keine Quellen einbezogen - bei diesem LSG sagt CDDA daß es 1978 erstellt wurde, dein Import aber sagt 2000. Vermutlich war 2000 eine Neuausweisung durch einen neuen Landschaftsplan, die deine Quelle fälschlich als Erstausweisung annimmt - manchmal hat aber auch CDDA Unfug-Daten. Per Google konnte ich auf die Schnelle aber nur die Wikipedia-Liste list of protected landscape areas in Nuremberg (Q19961992) als Quelle für 2000 finden.

Nachtrag - Wöhrder See (Q59527570) ebenfalls. Ich habe es jetzt erstmal so geändert als wäre deine Quelle Wikipedia, und diese Quelle vermutlich falsch. Übrigens - die CDDA-Daten gibts als CSV-Datei unter [2]. Ahoerstemeier (talk) 10:17, 13 December 2018 (UTC)

@Ahoerstemeier:, die Angabe ist nicht falsch und ich hab dir dazu ausführlicher auf der DIS in WP geantwortet. Die CDDA Listen kenne ich aber nutze sie nicht (mehr) da ich die Quellenlage und Wege nicht kenne. Sie hinken auch der Realität stark nach und ändern sich für meinen Geschmack viel zu oft. Daher lösche ich auch ab und an wenn ich es als "Fundstelle" finde. --Derzno (talk) 14:51, 13 December 2018 (UTC)

FFH-Gebiet - SPA vs. SCIEdit

Bei deinem Import der FFH-Gebiete scheinst du einige mit dem falschen Typ versehen zu haben - z.B. Spreckenser Moor (Q60685074) war als Special Area of Conservation (Q1191622) eingetragen, ist aber (noch) nur ein site of community importance (Q796174). Gestern hatte ich auch schon eines. Die spannende Frage - gibt es eine andere Möglichkeit als händisch dem Link von Natura 2000 site ID (P3425) zu folgen, um die richtigen Typen und derren Start/End-Daten einzutragen? Ahoerstemeier (talk) 08:54, 22 January 2019 (UTC)

Ich hab bei allen Gebieten pauschal FFH-Gebiet eingetragen und sollte es auch so lassen. Das rechtliche stimmt nur die Teile sind bereits in Karten und Infos ohne Status als FFH eingetragen. Alles andere verwirrt nur noch mehr. Wo man den Status abgreifen kann, keine Ahnung :(. --Derzno (talk) 09:05, 22 January 2019 (UTC)
Ich habe da nicht wirklich Ahnung was die beiden Stati bedeuten und vor allem unterscheidet, aber es könnte auch sein daß die deutsche Übersetzung das Problem ist - "FFH-Gebiet" kann man ja auch als Sammelbegriff für SAC und SCI interpretieren, aber die einzige Oberklasse ist Natura 2000 protected area (Q15069452) und die bezieht Special Protection Area (Q2463705) mit ein. Ahoerstemeier (talk) 13:00, 22 January 2019 (UTC)

Vogelschutzgebiet Fiener Bruch (Q19964060)Edit

Warum hast das von mir aufgespalteten Item wieder zusammengemanscht? Der Wikipedia-Artikel ist über beide FFH-Gebiete, das Item kann dann doch nicht halb über das Brandenburgische (WDPA, Natura2000-ID) und halb über beide (Gemeinden, Wikipedia/Commons-Link) sein! Ich habe mir schon was dabei gedacht als ich mir die Mühe gemacht habe die auseinanderzuziehen. Ahoerstemeier (talk) 21:39, 6 February 2019 (UTC)

Ich schau mir das nochmal an. Die Struktur in WP int. mich erhrlcih gesagt nicht (mehr). Da macht eh jeder was er will was ich gerade an den Kategorien sehe. Was sollte eigentlich dieser ganze [[Q|Q16887380}} Zauber? Meinst du das blickt noch irgend jemand? By the way wir sollten uns dann mal eine "Definition" auf die Projektseite schreiben, wie wir mit solchen "all in one" Gebieten umgehen. Das Problem kommt bestimmt immer wieder hoch. Ich freue mich schon auf die Naturwaldreservate. --Derzno (talk) 05:11, 7 February 2019 (UTC)
Nachtrag, wieso schraubst du eigentlich ab und an am Rang von site of community importance (Q796174)? Wenn es da einen Grund gibt, sollte auch das dokumentiert werden. --Derzno (talk) 05:15, 7 February 2019 (UTC)

Ergebnis: Zum Fiener Bruch gibt es ein Naturschutzgebiet (163095) im Landkreis Jerichower Land in Sachsen Anhalt, zwei Vogelschutzgebiete (555537454) in Sachsen-Anhalt und Brandenburg sowie ein SAC (555518984) in Sachsen Anhalt. Die beiden SPAs sind nur durch die BL Grenze getrennt haben aber unterschiedliche WDPA Nummern. Anmerkungen: Bei anderen Überschneidungen über BLs gibt es meist nur eine Nummer. Das NSG (163095) liegt im Vogelschutzgebiete (555537454) nur in SA. Das SAC (555518984) ist nicht deckungsgleich mit dem SPA (555537454) in SA und es scheinen nur Gräben zu sein. Teilweise überlappt es sich mit dem NSG. Damit hast du Recht, für jedes dieser vier Objekte ist ein eigener Datensatz notwendig. Ob die auch wirklich logisch zusammen gehören, lasse ich mal offen. Nur weil sie den gleichen Namen haben, sagt das nicht aus. Die ganze Ecke dort scheint dort Fiener Bruch zu heissen da gibt es auch noch einen weiteren Artikel in WP, der aber m.E. unvollständig ist. Mich würde es nicht wundern, wenn es es dort im Gebiet noch mehr SGs unter anderem Namen geben würde wie LSG, ND etc. Leider finde ich die BfN nicht mehr und mit dem SA Geoportal komme ich auf die Schnelle nicht zu diesen Infos. Tut mir leid für den unötigen Merge und bevor ich das wieder heile mache, bitte Kommentar ob ich nochwas übersehen habe. . --Derzno (talk) 06:19, 7 February 2019 (UTC)

Es kommt ja öfter vor, daß wegen Kreis- oder Gemeindegrenzen logisch zusammengehörige Naturräume in mehrere rechtlich getrennte aber gleichnamige Schutzgebiete aufgeteilt sind, die dann hier einzelne Items sein müssen. Auch schon ohne WP-Politik wirkt es seltsam, daraus verschiedene Artikel zu machen, und wenn die WP das macht, dann das müssen wir auch abbilden - einfach ein NSG auszeichnen und das an den Artikel binden wäre falsch, deswegen die Krücke mit group (Q16887380), die dann auch zu den Teilen verweist. Neuerdings packe ich auch noch Wikipedia article covering multiple topics (Q21484471) als zweites instance of (P31) hinzu. Denk vor allem an die Kategorien auf Commons, wo man mit der Infobox dann leicht navigieren kann, und man dann schnell sieht daß in der Sammelkategorie eigentlich keine Bilder liegen sollten. Grenzwertig wird es dann wenn die beiden Teile stark unterschiedlich groß sind, dann könnte man dann doch den Sammelartikel an das größere der beiden hängen... Wenn du eine bessere Idee hast wie das Item zu einem Sammelartikel aussehe sollte, dann können wir das gerne im Projekt diskutieren, oder eben mein bisheriges Vorgehen dokumentieren.
Das mit dem Rang von Special Area of Conservation (Q1191622) war wohl der Versuch abzubilden daß das FFH-Gebiet eben (noch) kein SAC ist, also keine falschen Daten zu haben und trotzdem deinen Query zu erhalten. Ich arbeite mich gerade Kreis für Kreis durch NRW und erzeuge die fehlenden NSGs und linke die an die Natura2000-Gebiete und verfeinere/korrigiere dabei auch die Daten wo nötig, dabei fliegen in ein paar wenigen Fällen die SAC-Statements raus eben weil sie definitiv falsch sind. Falls dir in den Queries jetzt welche fehlen, dann deswegen. Bitte füge die dann nicht wieder ein, der richtige Weg wäre den Query an die Daten anzupassen und nicht umgekehrt. Ahoerstemeier (talk) 16:31, 7 February 2019 (UTC)
Ich hab alles reverted, schau bitte nochmal darüber. Leider durchblicken in diesen Konstrukt kann ich immer noch nicht. Wenn ich das schon nicht kann, wie soll das dann ein Newbie/Weniguser verstehen. Ich hatte schon viel Spass und blöde Kommentare wegen relativ einfachen Includes bei Listen in WP und wurde deswegen fast auf VM gezerrt. Da müssen wir uns was einfacheres einfallen lassen. Keep it simple (KIS).
Zu WP, was soll ich dazu noch sagen? Wenn ich solche Aktionen oder solche Diskussionen lese, bleibt mir nur noch Kopfschütteln. Frag mich nur, warum sich alles um geographische Zuordnungen dreht. Ein Schutzgebiet wird nach "Sachlage" ausgewiesen und das ist nicht abgebildet. Ich selber halte mich aus den Kategorien in WP zukünftig komplett raus. Der Ton dort ist unterirdisch, ich hab die nicht angelegt, ich brauche diese CATs nicht und was sich die Wächter da jetzt auskäsen wird uns in WD wohl kaum treffen. an könnte glatt meinen, Kategorien wären das Wichtigste in WP. --Derzno (talk) 07:31, 8 February 2019 (UTC)

FFH-Verortung in NRWEdit

Da ich gerade systematisch alle NSGs in NRW hier einpflege, jeweils ein Kreis nach dem anderen, gehe ich immer die Verknüpfung zu den FFH-Gebieten an die zum Glück auf den jeweiligen NSG-Infoseiten vom Landesamt steht. Daher brauchst du die Verortung für NRW nicht zu machen, die kommt mit der Zeit von mir. Ahoerstemeier (talk) 17:31, 13 February 2019 (UTC)

Zuständigkeitsbreich von NSGEdit

Ich sehe, dass du zu den NSG in in mehreren Bundesländern das Brundesland als applies to jurisdiction (P1001) einfügst. Hast du das genau nachgeprüft? Im LNatSchG NRW heißt es "§ (4) Die Betreuung der besonders geschützten Teile von Natur und Landschaft obliegt unbeschadet des § 3 Absatz 1 Nummer 2 den unteren Naturschutzbehörden. Soweit besonders geschützte Teile von Natur und Landschaft im Eigentum des Landes stehen, kann die oberste Naturschutzbehörde eine abweichende Regelung treffen.", demnach müsste in jedem Einzelfall nachgeprüft werden, wer zuständig ist. --GPSLeo (talk) 17:08, 11 March 2019 (UTC)

@GPSLeo:, ich hab mich an diese DIS gehalten. Extra geprüft habe ich nichts. --Derzno (talk) 18:51, 11 March 2019 (UTC)
Bei FFH-Gebieten ist das auch korrekt, für die ist immer die oberste Naturschutzbehörde(also das Land) zuständig. Für die meisten anderen Schutzgebietstypen ist, außer in den Stadtstaaten, in der Regel die untere Naturschutzbehörde(meist beim Landkreis) zuständig. --GPSLeo (talk) 19:19, 11 March 2019 (UTC)
Dann werde ich das wohl bei NSGs/LSGs rauslöschen. Das prüfen von xTausend Gebieten in den VOs ust mir zu viel. --Derzno (talk) 19:23, 11 March 2019 (UTC)
Wenn bei located in the administrative territorial entity (P131) der Landkreis angegeben ist, könnte zumindest der übertragen werden, dürfte in 99% der Fälle korrekt sein, aber das Bundesland sollte raus. Achso, bevor du noch einmal quickstatements darüber laufen lässt, ein Admin kann den ganzen Stapel einfach für die Stapel-ID zurücksetzen. --GPSLeo (talk) 19:34, 11 March 2019 (UTC)
@GPSLeo:, ich habe gerade ein paar NSGs in BY geprüft. Meist liegt es in der Verantwortung der Bezirksregierungen (die über den LKRs stehen) und in manchen Fällen sogar beim Land. In Worten um das verbindlich einzutragen ist jede VO anzusehen und das ist mir echt zuviel Arbeit. Ich schmeiss daher applies to jurisdiction (P1001) in den von mir bearbeiteten BLs raus. --Derzno (talk) 08:27, 12 March 2019 (UTC)
Ja man muss sich auf jeden Fall für das Land das jeweilige Landesnaturschutzgesetz angucken und dann eventuell häufig noch in die Verordnungen. Aber ich denke applies to jurisdiction (P1001) wird sowieso kaum verwendet, besser wäre es dann auch dort auch nicht die Verwaltungseinheit anzugeben, sondern für die entsprechende Behörde ein item an zu legen. --GPSLeo (talk) 09:24, 12 March 2019 (UTC)

Theikenmeer (Q1300352)Edit

Hallo Derzno, hier wurde das "Naturschutzgebiet Theikenmeer" mit dem darin befindlichen See "Theikenmeer" vermischt, der aber nur einen kleinen Teil des NSG ausmacht. Kannst Du das bitte korrigieren? Nach dem Hochladen meiner Bilder gibt es nun beide Kategorien bei Commons. Gruß, -- Ies (talk) 09:21, 13 March 2019 (UTC)

@Ies:, ich habe es geändert und jetzt auch für den See ein eigenes Label Theikenmeer (Q62055334) angelegt. Wenn du zum See noch Infos hast, bitte dort eintragen. --Derzno (talk) 15:24, 13 March 2019 (UTC)
Danke! -- Ies (talk) 16:01, 13 March 2019 (UTC)
Gerne und das Problem mit den Mix NSG zu geografischen Objekten gibt es leider sehr oft. In Wikidata zumindest halten wir sowas sortenrein auseinander (oder versuchen es zumindest). --Derzno (talk) 16:07, 13 March 2019 (UTC)

Lageprobleme bei GeotopenEdit

Hallo Derzno, bin über zwei Geotope an der falschen Stelle gestolpert, [3] und [4]. Meine Vermutung bei den falschen Längenangaben: die führende Null aus der Quelle Umweltatlas in Kombi mit irgendwelchen Skriptproblemen könnte das Problem verursachen. Könntest du bitte überprüfen, ob das ein weitgreifenderes Problem ist und es ev. an allen Stellen fixen? lg --Herzi Pinki (talk) 08:21, 9 May 2020 (UTC)

Servus Herzi Pinki, ich kann da eigentlich kein Problem sehen. Vielleicht hab ich auch dein Problem nicht richtig verstanden. Beispiel: Q87744059 Buckelflur der Reschbergwiesen W von Farchant (180R054). Die Original Koordinate lautet im Steckbrief; 47.528327° N 11.079634° E und wird dann über Wikidata als 47.528327°, 11.079634° (47° 31′ 41.98″ N, 11° 4′ 46.68″ E) angezeigt. Bitte das Format der Dastellung dabei beachten. WSG ist nicht gleich WSG. Ob jetzt die Original Koordinaten im Steckbrief auch korrekt sind, kann ich natürlich nicht sagen. Wenn man den Kartenausschnitt des Steckbriefs visuell mit dem der OSM Karte vergleicht (westlich Grubenkopf), ist das schon etwa die selbe Ecke. --Derzno (talk) 05:41, 10 May 2020 (UTC)
ok jetzt hab ich es verstanden. Muss mal versuchen nachzuvollziehen was und wann das passiert ist. Könnte aber ledier ein paar mehr betreffen. --Derzno (talk) 06:27, 10 May 2020 (UTC)
Glücklicherweise hat sich das Problem in Grenzen gehalten. Es kam durch Excel rein und hat nur die neuen in 2020 eingebrachten Geotope betroffen. Es waren in Summe 8 und sind jetzt alle (auch in WP) gefixed. Danke nochmal fürs melden. --Derzno (talk) 07:27, 10 May 2020 (UTC)

Danke für's Verstehen und für's Beheben. Ich bin nur zufällig drüber gestolpert, weil die zwei obigen Koordinaten unerwartet in Österreich gelegen sind. Ich hätte nicht gewusst, wie das systematisch finden. lg --Herzi Pinki (talk) 11:54, 10 May 2020 (UTC)

Lageprobleme bei FlächengebietenEdit

Ich schiebe noch nach: Salzach und Unterer Inn (Q60765948), Salzach und Inn (Q61018165), Inschutznahme des Bärnsees und seiner Umgebung als LSG (Q59643689), Karwendel mit Isar (Q60765236) haben mE auch falsche Koordinaten. Kannst du bitte neben der Korrektur auch noch gucken, ob da ebenfalls ein systematisches Problem vorliegt? lg--Herzi Pinki (talk) 15:25, 12 May 2020 (UTC)

Hallo Herzi Pinki, das Problem ist bekannt. Bei diesen Objekten handelt es sich um "flächenhafte" Schutzgebiete. Geotope sind (meist) nur punktuell. Bei flächenhaften wird derzeit "irgendein Wert" der Fläche in eine Punktkoordinate gewandelt. Das erfolgt mal so, mal so und wurde meist aus CDDA/WPDA Daten übernommen. Da kann so eine Koordinate auch schon mal ausserhalb vom betreffenden Gebiet liegen. Das Problem wäre eigentlich nur lösbar, wenn wir mit "shapes" arbeiten könnten, die die Geometrien abbilden. Ein Beispiel wäre Sandfluren bei Volkach, Schwarzach a.Main und Sommerach (Q15843949) mit OpenStreetMap relation ID (P402) Zumindest bei WD ist mir keine Methoden bekannt ausser sogenannte "Relationen" (OpenStreetMap relation ID (P402)) (wenn dort überhaupt vorhanden) aus OpenStreetMap einzubinden. Aber da gibt dann auch noch andere Probleme auf die ich öffentlich lieber nicht eingehen möchte. Ich hab mal User:Ahoerstemeier und User:GPSLeo mit in die DIS in der Hoffnung einer tragfähigen Idee. --Derzno (talk) 04:13, 13 May 2020 (UTC)
Gerade bei flächigen Schutzgebieten mit mehreren Teilflächen kann es passieren, dass diese externen Quellen eine Punkt ausgewählt haben, der gar nicht im Schutzgebiet liegt. Ich hatte sogarschon eines, wo der Punkt in Polen lag, ein paar Kilometer nach Osten verrutscht. Bei flächigen Objekten eine Koordinate auszuwählen ist immer willkürlich, man kann es noch mit Qualifiern etwas abmildern - z.B. spezifiziere ich bei Städten gerne mit applies to part (P518) city hall (Q543654), aber dazu müßte es in einem Schutzgebiet erstmal ein "Zentrum" geben. Shapes kann man zwar auch einbinden über die Property geoshape (P3896) und einer geojson-Datei auf Commons, das ist aber sehr mühsam und die Shape-Daten müssen natürlich auch in einer passenden Lizenz sein. Zumindest in der Commons-Infobox erscheint der Umriss übrigens auch dann, wenn in OSM das Wikidata-Tag gesetzt ist, damit gehen dann auch "Ways" und nicht nur "Relations". Für einen längeren Text siehe auch User:John Cummings/Map data. Ahoerstemeier (talk) 07:35, 13 May 2020 (UTC)
Ja genau, das mit den shape Lizensen ist ein Problem. Manche BL geben die und CCx frei, andere eben nicht. Und dann ist das noch OSM die sowas wie Wege und Relationen gerne mischen. Alees nicht so einfach. --Derzno (talk) 07:40, 13 May 2020 (UTC)
Soweit ich das in OSM verstehe werden Relations nur dann benutzt, wenn es keine einfach zusammenhängende Grenze ist, also wenn es Teilgebiete gibt oder Exklaven. Wenn es als eiinfache Linie darstellbar ist, dann wird auch noch "Way" benutzt. Und dann kann man nur von OSM nach Wikidata linken, nicht umgekehrt. Ahoerstemeier (talk) 07:56, 13 May 2020 (UTC)
Genau so ist es! Ich hab mal als Hilfskrücke in OSM über einen "way" als eine "Ein-Element-Relation" gelegt. War keine gute Idee und hatte die Wächter der Regelgeber gleich an der Backe. GGf. müsste man dann ein Prop für way anforden, aber ob sich das wirklich lohnt? So viel SG sind in OSM eben wegen den unklaren Lizensgedöns nicht angelegt worden. --Derzno (talk) 08:01, 13 May 2020 (UTC)
Was die Koordinaten an geht ist das bei den NATURA-2000 Gebieten noch am klarsten, da ist der Punkt immer die Mitte eines Kastens, der das Gebiet komplett enthält, genau das führt halt auch bei solchen Formen zu diesen weit entfernten Punkten. Was die Shapes an geht, die stehen unter CC-BY, können also problemlos auf Commons geladen werden. Braucht halt nur ein Skript, die in das korrekte Format zu bringen. --GPSLeo (talk) 08:34, 13 May 2020 (UTC)

Zeitstellung?Edit

Von dir stammt die häufige Beschreibung "vorgeschichtlicher Zeitstellung" (z. B. in Siedlung in Hartenstein (Q58330510)). Müsste es nicht "vorgeschichtlicher Zeit" heißen? Den Begriff "Zeitstellung" hab ich noch nie gehört, und der Duden auch nicht. Steak (talk) 13:23, 3 August 2020 (UTC)

Servus Steak, der Begriff Siedlung vorgeschichtlicher Zeitstellung wird vom Bavarian State Office for Monument Protection (Q812412)) verwendet. Siehe Liste --Derzno (talk) 14:02, 3 August 2020 (UTC)
Ah okay. Seltsam, aber dann kann man das natürlich so lassen. Steak (talk) 14:18, 3 August 2020 (UTC)

"part #4 of cultural heritage D-n-nn-nnnn-n in Bavaria, Germany"Edit

Somehow the labels of items like Burgkapelle (Q98589559) seem suboptimal. Q98588602 looks like you added the German label and alias as description. --- Jura 14:05, 23 August 2020 (UTC)

Jura not sure what kind of problem you have with. Maybe you can provide an example what's your wish and we can discuss. --Derzno (talk) 14:22, 23 August 2020 (UTC)
  • See [5]. Maybe Wikidata:Forum can help you getting the (mostly German) labels right. --- Jura 07:48, 25 August 2020 (UTC)

https://quickstatements.toolforge.org/#/batch/40458Edit

  1. What's the meaning of these 6000 top-level statements such as Schloss (Q883530) series ordinal (P1545) "0"?
  2. Also: what's the matter with labels being changed from, in this example, "Schloss Wiesenthau" to mojibake such as "Cultural heritage D-4-74-175-7 in Wiesenthau" ([[6]]))? If it's about the language: enwiki has a good number of high-quality articles using "Schloss", so that seems perfectly acceptable, even if some high-profile ones have translated names (*Neuschwanstein Castle*). (Edit: I just noticed Jura1 had mentioned this issue already. (Hey Jura, great to finally agree on something with you :)). So, this would seem to constitute the example you were asking for.)
    1. Another example: St. Andreas (Q41294974) is a church, and it had the perfectly multilingual label "St. Andreas". Changing that to this random string ("Cultural heritage D-4-78-165-297 in Bad Staffelstein") is just destructive.
    2. Jugendfreizeitheim (Q27991468), currently Feuerstein Castle and linked to a high-quality page of the same name on enwiki will be relabeled "Cultural heritage D-4-74-121-62 in Ebermannstadt" later in this QS-batch...
  3. Similar: I'm *really* not sure it's useful to change descriptions from "building in Aufseß, Bavaria, Germany" to "Cultural heritage monument in Bavaria, Germany" (changeset). It's a designated monument, yes. But just because you happen to have a list of those doesn't make that the single most pertinent fact about these buildings. Just reading "cultural heritage monument", very few people will have an (accurate) idea of what it is. "Monument" evokes the Lincoln Memorial more than the White House. Just saying "old building" would be more useful to be honest, and many of these items have statements that would allow to infer far more useful descriptions, such as "18th-century church".

--Matthias Winkelmann (talk) 02:13, 24 August 2020 (UTC)

Matthias Winkelmann, first of all, I'm working currently together with Ordercrazy to clean up the Bavarian cultural heritages. The long term goal of this task is to get a maintenance script for the more as 5000 lists in Wikipedia. The database was pushed a couple years ago by bot into WD and since that time nearly nobody took care about these data somehow. Currently we have a lot of wrong, incomplete, missing reference, doubles, stupid instance of (P31), rubbish and obsolete data. We are talking from appr. 150k of data sets and hope you’ll understand that this couldn’t be tracked manually and optimized for every data specifically. You’re right from time to time the former label/description would be fitting much better. Now in detail back on your comments. 1. The series ordinal (P1545) is a marker to show up the level of an object. We have on top (marked as 0) the “main” object with having an own Bavarian geotope ID (P4266) number. The number has to be used only once. In some cases the object is split into others and hanging below the main. They have no own Bavarian geotope ID (P4266) and will be linked together with part of (P361) / has part (P527) See Mauer (Q98585970). Currently we have a nice mix. Sometimes below this main object up to 30 sub-objects will be used, which was handled by different people in a different way leading to many constrains. So every known Bavarian object will get a series ordinal (P1545) from 0 … x. 2. As mentioned above, unfortunately you are right but these are only single cases and I can’t check all details manually. If you have another idea to sort out such a useful naming automatically let me know or feel free to revert such specific cases. In general in >95% en label still missing and if you are working with tools you will get only q…. numbering and that is definitely not helpful not knowing anything behind. At the end every dataset have to have de and en label set. The accurate naming is only in a minimum of the data and mostly by objects having an article in behind. 3. Same as 2, do you expect I’ll translate 150k of data from German in English? If you have a proposal with a much better naming based on data availability with numbers, location, German text I can change please let me know. The data are in a very bad shape and I’ll guess we will be busy for month to have a useable database to make maintenance easier. The lists in Wikipedia are weak either and very limited people working on these nearly 5000 lists. So we have the choice to find a way to automate or keep it as it is. The price for is sometimes that better content get lost but this is related to the advantage from my view acceptable. I can make my life also easier and don’t need to do something here and keep the data a it is. Let me ask differently, above the issue with replacing in some cases better EN labels with generics what is your concern and consequences I’ll missed? I didn’t saw you working somehow in the area of Bavarian monuments. As said the data was moved in 2017 and nearly nobody took care about to clean up and make it useable. I would highly appreciate if you see such special cases that you will help to turn back. best regards --Derzno (talk) 04:35, 24 August 2020 (UTC)

It's great you're trying to work on that data, and I have no specific interest (I only really need even the smallest Bavarian village to be linked to the name it had ca. 1939, which is probably similar to your frustration). I do have a general interest and prefer higher quality data over lesser quality.
As far as I can tell, you're using series ordinal (P1545) for your (/our) purposes to keep track of the different parts that make up a single "ensemble" monument? Or, at least, that's the practical effect because I can't really see a way how a consumer would understand the scheme.
As such, it just doesn't belong in a top-level statement, and especially not in the label. Mauer (Q98585970) is "Mauer". And if it's necessary for it to even exist here, it should be labeled "Mauer", or "Östliche Begrenzungsmauer", or whatever someone would use in a sentence like "... have to paint the <label> this week".
How about:
part of (P361)
  Pfarrhaus (Q41403711)
series ordinal (P1545) "2"


add value
That way, the series ordinale is linked with the actual series, in a way that people might understand intuitively.
As an alternative, and in case you need this data stored with the item only temporarily, maybe a "scratchpad" property would actually make sense, where anybody could store temporary markers, and keep that out of the "real", user-facing properties.
As for labels and descriptions: After checking a few dozen that were changed in the batch (as opposed to newly added), I am rather firmly of the opinion that at least on balance, but close to in almost every case, the previous label and description are better. So I would suggest to not change existing labels and description, and instead only add them where none currently exist. If I understand you correctly, that would be your first choice as well, and it's technical difficulties that prevent you from doing that?
I don't know your workflow, but I would usually assume people check existing values before overwriting them? With, say, OpenRefine, this is possible with point-and-click only. If you tell me what technology/programming/language/etc you use, I can try to put together something that would filter out items with existing data. It's unfortunate that QuickStatement does not offer this functionality. --Matthias Winkelmann (talk) 05:18, 24 August 2020 (UTC)
Matthias Winkelmann ok I'll see your point. It'll be similar to other generic probs been used somehow. I'd made Pfarrhaus (Q41403711), Nebengebäude (Q98584556) and Mauer (Q98585970) as an example. Is this what you're looking for? --Derzno (talk) 05:37, 24 August 2020 (UTC)
Yes, that structure looks good. I would prefer more time invested into one good entity for each of these, instead of individual items for each tiny part, most of which will contain little information. But that's somewhat of an individual preference and you're doing the work, so you get to decide.
Something similar for the labels: if in doubt, just leave it blank, maybe? It's absolutely fine for such things to be missing, and everyone understands there will forever be data missing. But "bad" data gives a completely different impression. I don't have any data on this, but my impression is that low-quality data scares away people thinking about using the data, and is far more frustrating to encounter for regulars. Could just be me, though!
Anyway... Thanks for your understanding of my nitpicking, and sorry for starting your week with criticism. --Matthias Winkelmann (talk) 06:02, 24 August 2020 (UTC)
Matthias Winkelmann, I'll fix my workflow to cover the "order issue" but the allready uploaded ones I'll fix later on. My todo list is pretty overloaded and quickstatement blocks me when a job runs in the background and keep me away from other manuall sorting work. I have to push out. Also I'll find a way to keep description and label out of the game if allready filled. But it makes my life not easier to get rid of all the rubbish in the data. Anyhow, it is as it is. Concerning my workflow, OpenRefine is a powerfull tool but don't help me here. I have 3 sources of data. First the official ones from BLfD, second lists in wikipedia and third this nightmare here. I need to combine an extract and using a local database (Access) for. Before pushing out data I have to run an own perl-script to compile Access output to wikidata and/or wikipedia table style. --Derzno (talk) 04:56, 25 August 2020 (UTC)

BLfD-Objekte und CommonscatEdit

Hallo @Derzno, Ordercrazy: vielen Dank für die Anlage der Wikidata-Objekte. Es wurden jetzt über die BLfD-ID aus Wikidata-Objekt und Commonscat wieder einige davon mit den bestehenden Commonscats verbunden (diese sollten sich früher oder später unter Commons:Category:Cultural_heritage_monuments_in_Bavaria_same_as_Wikidata wiederfinden, ebenso sollte von Pi bot in allen verbundenen Commonscats eine Wikidata-Infobox hinzugefügt werden). Verbindet ein Benutzer einen neu angelegten Artikel mit einer mit einem Wikidata-Objekt verbundenen Commonscat über "Links hinzufügen", so wird der Artikel damit dem bereits bestehenden Objekt zugeordnet. Eine keinem Wikidata-Objekt zugeordnete Commonscat hätte zur Folge, dass ein weiteres Wikidata-Objekt angelegt würde (nur mit den Sitelinks zu Artikel und Commonscat), unabhängig vom bereits existierenden Wikidata-Objekt für das Denkmal, sodass weitere Dubletten entstehen würden.

Mögliche Dubletten finden sich unter Commons:Category:Cultural heritage monuments in Bavaria not in Wikidata wo in der Commonscat eine BLfD-ID hinterlegt ist, die aber nicht im zugehörigen Wikidata-Objekt eingetragen ist. In einigen Fällen gab/gibt es für diese Commonscat/Artikel-Objekte ein zweites Wikidata-Objekt, dass die BLfD-ID eingetragen hat, nicht aber den Link zur Commonscat bzw. zum Artikel.

Weitere mögliche Dubletten finden sich unter Wikidata:Database_reports/Constraint_violations/P4244#"Unique_value"_violations (ca. wöchentliche Aktualisierung) bzw. auf Property_talk:P4244 unter "Eindeutiger Wert" -> SPARQL (jeweils aktueller Stand).

Derzeit noch unverbundene Commonscats sind unter Commons:Category:Cultural heritage monuments in Bavaria without linked Wikidata, Abweichungen unter Commons:Category:Cultural heritage monuments in Bavaria different from Wikidata zu finden.

Unter Commons:Category:Cultural heritage monuments in Bavaria with known IDs finden sich derzeit rund 22.000 Kategorien (rund 1.000 mehr als im Jänner 2020). Siehe auch de:Benutzer:M2k~dewiki/FAQ#Wie_ist_das_mit_bestehenden_Wikidata-Objekten_und_unverbundenen_Commonscat_und_Artikel_(inbesondere_Baudenkmäler_in_Bayern)_?. --M2k~dewiki (talk) 23:28, 26 August 2020 (UTC)

Servus M2k~dewiki, danke das erklärt einiges. Kann man diesen Doublettenbot für ein paar Wochen stoppen?
Ich bin gerade dabei, das ganze Feld aufzuräumen, da sich bisher auch keiner darum gekümmert hat. Wir wollen endlich mal den Brückenschlag zwischen Wikipedia Listen und Wikidata schaffen und diese Massen von Listen automatisch pflegbar machen. Das wird aber sicher noch länger dauern. Mein Workflow ist, WD Objeket ergänzen, auch mit den sub Teilen die "Gehört zu", ehemalige BD aussortieren, fehlende Daten ergänzen (Koordinaten, Einzelnachweise, verlinkung zu Listen, richtige Verortung, Doubletten entsorgen ...). Da kann ich nich auch noch einen Bot brauchen der mich mit Arbeit versorgt. Commons gugg ich mir im Moment nicht an und keine Ahnung wie man das stoppen könnte. Die Wartungskat zu P4244 kenn ich aber arbeiet die nicht direkt ab. Ich mach das lokal mit meiner Datenbank, da kann ich alles bessser/schneller rausfieseln was ich wissen muss/will. Wenn du dich gut auskennst kannst du geren helfen die Problemfälle mit abzuarbeiten. Listen dazu kann du gerne haben von mir --Derzno (talk) 04:17, 27 August 2020 (UTC)
Hallo @Derzno, Ordercrazy: mir ist diesbezüglich kein Bot bekannt. Die Dubletten entstehen, wenn ein Benutzer einen (neuen) Artikel mit einer (noch unverbundenen) Commonscat über "Links hinzufügen" verbindet. Dann gibt es ein Objekt mit den Sitelinks und ein zweites Objekt mit der BLf-ID. Zuletzt hatte ich im Jänner 2020 einige hunderte derartige Dubletten zusammengeführt. Siehe auch de:Benutzer:M2k~dewiki/FAQ#Wie_ist_das_mit_bestehenden_Wikidata-Objekten_und_unverbundenen_Commonscat_und_Artikel_(inbesondere_Baudenkmäler_in_Bayern)_?. Weitere mögliche Dubletten finden sich unter unter Commons:Category:Cultural heritage monuments in Bavaria not in Wikidata und Wikidata:Database_reports/Constraint_violations/P4244#"Unique_value"_violations. Verhindern kann man das nur dadurch, indem man neu angelegte Wikidata-Objekte ohne Sitelinks mit den bereits vorhandenen Commonscats verbindet bzw. sobald weitere neue Commonscats laufend angelegt werden (seit Jänner 2020 wurden rund 1000 neue Commonscats zu diesen Objekten angelegt), diese ebenfalls mit den nunmehr bestehenden Denkmal-Wikidata-Objekten verbindet. --M2k~dewiki (talk) 09:04, 27 August 2020 (UTC)
Lass mich erst mal den Rest meiner Arbeiten machen, dann mach ich mir mal eine Kopf wie wir das lösen können. Im Moment fliegt aber schon einiges raus aus den Wartungslisten durch meine Putzaktionen. Ganz leer werden wir die aber niemals bekommen. --Derzno (talk) 07:23, 28 August 2020 (UTC)
(ping auch an @DALIBRI, Giorgio Michele, Jean-Frédéric, Mfchris84, GFreihalter, Rufus46: zur Info). --M2k~dewiki (talk)

Bulk creation of items with problematic English labels: please cease creating further items with problematic English labelsEdit

Please cease creating further items with problematic English labels. Can I count on you? It's not acceptable to consider correct labels as "nice to have" as you mentioned in Wikidata:Project_chat#Label_and_"part_#3_of_cultural_heritage_D-1-62-000-3976_in_Bavaria,_Germany".

If not, I will ask an admin to look into this.

To cleanup the damage you have done to the database, please start fixing English labels and move them to descriptions. --- Jura 07:50, 30 August 2020 (UTC)

I notice you continue to create more such items, despite being asked not to Q98769252, Q98769253. --- Jura 07:24, 31 August 2020 (UTC)
Frankly spoken, you drives me crazy! What hasn’t understood that I’ll change the label and description? The discussion has started according and should looks like. If you are opening this discussion on many places than this is not my problem. Bavarian monuments are a German topic and should discuss in this Forum. Above this I have not seen any proposal nor even yourself on en-forum. Only telling me it’s not acceptable and I’m an idiot. What make it worst, with your canvassing you bring other not involved people making changes which are fill up again the violations of Bavarian monument authority ID (P4244). Great job, thank you! Believe me, I’m close to delete all English labels and description of “my new ones” and keep it empty. So you’re happy and can put in whatever you want. Personally I don’t need it. Back to your new items, I have now completed all the missing remaining elements with old style and one more or less doesn’t count. I’ll change all after discussion has finished and hope it is clear now for you either. --Derzno (talk) 07:56, 31 August 2020 (UTC)
Can you be slightly more explicit in your commitment? On project chat you wrote that corret labels would be "nice to have". Since the problem was first raised, you could have finished the cleanup a week ago.
I think it was someone else who told you that you are an idiot. Sorry for such an experience here at Wikidata.
I asked people on the German language forum to help you to work out labels and descriptions in German (so at least they are correct, before you try to translate them) as my explanation/sample and that of another user in English doesn't seem help. Clearly https://www.wikidata.org/w/index.php?title=Q41403711&diff=1263980467&oldid=1263927735 or https://www.wikidata.org/w/index.php?title=Q41294974&diff=1264181591&oldid=1264060898 is not ok, even in German. https://www.wikidata.org/w/index.php?title=Q98650695&oldid=1267322236 already leads to oddities at Commons. --- Jura 21:54, 1 September 2020 (UTC)
First of all I'm not interested in any finger pointing or who told what in the history. My intention is to look forward and learn only from history. So let’s stop here discuss things not helping to move on. I'd started by yesterday night a couple tests to exchange label according your rule and went as expected in issues. The main issue is, that it doesn’t' work to have in German and/or English same combination of label and description more as ones. I can not change the input, it is as it is and could change only usage and combination. Why this blocked, I don't know and have a personal view on this (never had this in my SAP life with millions of datasets) but we cannot change. So I'll need to test more options to get rid of this issue because the length is limited to 250 letters in description. This is already too short in German text descriptions. For the English ones, I'll try now Label: object (only what it is, no relation to something else) and description as cultural heritage # (BLfD-ID) in (territory), Bavaria. If this will be not work till weekend I'll clean up all English labels/descriptions and keep it empty. And please keep in mind, I’ll have 160k data and not a couple ones to maintain. So this will take time. --Derzno (talk) 04:25, 2 September 2020 (UTC)
Could you please stop messing up english labels (like Bamberg Cathedral (Q5924)) --Hjart (talk) 14
08, 4 September 2020 (UTC)

EmailEdit

Hallo Derzno, ich habe gerade auf Deine Email von gestern geantwortet, aber jetzt von Deinem Mail-Provider so eine recht kryptische Fehlermeldung bekommen. Ist bei Dir etwas angekommen? Viele Grüße! —MisterSynergy (talk) 21:37, 1 September 2020 (UTC)

Servus MisterSynergy, ich habe nichts bekommen und ping dich mal hier mit email an. --Derzno (talk) 03:51, 2 September 2020 (UTC)

We sent you an e-mailEdit

Hello Derzno,

Really sorry for the inconvenience. This is a gentle note to request that you check your email. We sent you a message titled "The Community Insights survey is coming!". If you have questions, email surveys@wikimedia.org.

You can see my explanation here.

MediaWiki message delivery (talk) 18:45, 25 September 2020 (UTC)

Weicholdswald (Q62987358)Edit

Kannst du die Koordinaten von Weicholdswald (Q62987358) überprüfen - der Punkt liegt deutlich außerhalb des Waldes, während die anderen drei gleichnamigen Schutzgebiete alle im Wald positioniert sind. Ahoerstemeier (talk) 08:34, 4 October 2020 (UTC)

Ahoerstemeier, die Daten stammen von https://fgrdeu.genres.de/index.php?id=1580&L=0 und sind dort mit N50.7909630 E13.7807660 angegeben. Leider wahrscheinlich auch hier das alte Problem mit Flächen, die auf eine Punktkoordinate reduziert werden. Hab auch keine genauen Daten (shape files) über die Ausdehnung des Waldes. Die Punkte liegen auch m.E. nicht soweit auseinader und ich würde daher die Ur-Daten so lassen --Derzno (talk) 08:08, 5 October 2020 (UTC)