Wikipedia Diskussion:WikiDaheim/Archiv 2019

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Wikipedia Diskussion:WikiDaheim/Archiv 2019#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Wikipedia_Diskussion:WikiDaheim/Archiv_2019#Thema_1

Rückblick und Ausblick WikiDaheim 2018/19 am 17. Jänner in Wien

Hi! Am 17. Jänner findet in der WMAT-Geschäftsstelle um 18 Uhr eine Besprechung zu WikiDaheim statt, um das letzte Jahr zu besprechen und die Weichen für dieses Jahr zu stellen, z.B. was den Umfang und das Format des Fotowettbewerbs betrifft. Bei Interesse bitte einfach hier in die Liste eintragen. LG, --Braveheart ^{Welcome to Project Mayhem} 13:56, 8. Jan. 2019 (CET)

• Vorläufige Agenda - bitte einfach Punkte hinzufügen, falls etwas wichtiges noch nicht abgedeckt wird
  • Diskussion des letzten Jahres, inklusive Statistiken
    • Karte von Ailura von Österreichgrenzen einbinden
    • Agruwie Wettbewerbszeitraum auf wikidaheim.at ankündigen; statt 1. Platz Kellergassen -> Sonderpreis Kellergassen (es gibt keinen zweiten Preis)
  • Besprechung der auf dieser Diskussionsseite aufgebrachten Punkte, darunter
    • Änderungen am Fotowettbewerb hinsichtlich der Masse und Qualität der Fotos
    • Integration von Tag des Denkmals
  • Structured Data für den WikiDaheim-UploadWizard
    • Vorbefüllen der Structured Data mit Informationen aus WikiDaheim wie etwa "Feuerwehrhaus"
    • Zusätzliche Felder im UploadWizard zum Verknüpfen von Bildern mit Wikidata-Item zu dem Objekt
      • Option, abstrakte Beschreibungen hinzuzufügen
      • Vorbefüllen der abstrakten Beschreibungen
    • Phototouren mit vorbefüllten Metadaten zum Event?
    • Sprachenabhängigkeit - wie nach Wikidata-Items in einer anderen Sprache als Deutsch suchen?
    • Nutzung der Metadaten zum Check/Wartung/Einbindung der Mediendateien
  • Verwendung von Wikivoyage als einfachere Bearbeitungsplattform für Touristikverbände/Gemeinden?
  • ...

Ich nehme teil

• --Braveheart ^{Welcome to Project Mayhem} 13:56, 8. Jan. 2019 (CET)
• --Raimund Liebert (WMAT) (Diskussion) 14:11, 8. Jan. 2019 (CET)
• --Kanisfluh (Diskussion) 15:19, 8. Jan. 2019 (CET)
• --Regiomontanus (Fragen und Antworten) 06:56, 9. Jan. 2019 (CET)
• --Herzi Pinki (Diskussion) 22:32, 11. Jan. 2019 (CET) (gibt es einen Link zu structured data und was du genau meinst?, zur Vorbereitung - der link oben ist ja nicht mehr als ein buzzword mit highlevel Erklärung)
• ...

leider nein

• --doppelt gebucht :-( --K@rl du findest mich aber hauptsächlich im RegiowoikiAT 10:32, 9. Jan. 2019 (CET)

Vergleich Vorjury WD AT mit WLM DE

@Haeferl, Regiomontanus:, in AT haben sich 15 Menschen für die Vorjury angemeldet, in DE 38. In AT nahmen 14700 Bilder am Bewerb teil, davon wurden 3000 von den Hochladern von der Vorjury ausgenommen, bleiben 11700. In DE 25800, davon wurden 9500 von den Hochladern von der Vorjury ausgenommen, bleiben 16300. Vergleicht man die Bevölkerung 1:10 und nivelliert den Hochladezeitraum mit 3:1 Monaten, so entsprächen die 11700 in AT 39000 Bildern in DE (HoHo!), also wurden in AT wesentlich mehr Bilder als in DE hochgeladen, wenn man die Zahlen auf vergleichbar rechnet. Bei einer Bewertung des Hochladezeitraums von 1:2 wären das sogar ein Erwartungswert von 58500 Bildern in DE gegenüber den tatsächlichen 16300 Bildern. Wenn man die Bevölkerungsanzahl und den kleineren Hochladezeitraum von 1 zu 3 Monaten verrechnet, beträgt der Mobilisierungsgrad der Fotografen in DE nur etwa 42 % von dem in Österreich. Für jeden Vorjuror und jede Vorjurorin blieben im Schnitt 780 Bilder in AT und 429 in DE Bilder pro Durchlauf zu bewerten. Das heißt, die Vorjuroren in AT, Haeferl, da hattest du Recht, hatten pro Durchlauf und Kopf 82 % mehr Bilder zu bewerten als in DE. Vergleich man die Zahlen aber bei einer fiktiven gleichen Hochladedichte (Bilder pro Einwohner, 11700 zu 39000 Bilder), so ergibt sich eine fiktive Mehrbelastung des einzelnen deutschen Vorjurors von 32 %. Man kann aber hoffen, dass sich mit zunehmender Hochladedichte auch mehr Vorjuroren finden werden. Die Hochladedichte lässt sich a priori schlecht abschätzen, so wurden in AT 75 % mehr Bilder hochgeladen als noch 2017.

Man kann das also auch anders sehen, entweder hatte AT zu wenige Juroren für die gleiche Anzahl an Durchläufen wie DE (bei gleicher Belastung), oder in AT wurden für die vorhandenen Juroren einfach zu viele Bilder eingereicht (bzw. zu wenige von den HochladerInnen von der Vorjury ausgeschlossen). ME ist die freiwillige Mitarbeit von Juroren nur schwierig einzufordern und vorherzusagen, einfacher ist jedenfalls eine Begrenzung der Anzahl der teilnahmeberechtigten Bilder. Nochmals anders ausgedrückt, können die deutschen Vorjuroren bei den obigen Zahlen und bei gleicher Belastung fast doppelt so viele Bewertungsdurchläufe machen, als unsereiner.

Realiter wurden in DE mindestens 8 Bewertungen pro Bild abgegeben (8,8 im Schnitt), in AT wurde jedes Bild mindestens 6 Mal bewertet (lt. email von Braveheart vom 30. Oktober), 6,5 im Schnitt. Damit wurden in AT etwa 76050 Bewertungen abgegeben, in DE etwa 143440 oder 5070 pro Vorjuror in AT bzw. 3775 pro Vorjuror in DE. Damit war die reale Arbeitsbelastung der Vorjuroren in AT etwa um 34 % höher (und nicht um die oben errechneten 82 %). Hervorzuheben sind ManfredK und Sebastian Wallroth, die sich jeweils an beiden Vorjurys beteiligt haben.

Bitte nachrechnen und ev. korrigieren. lg --Herzi Pinki (Diskussion) 00:51, 9. Jan. 2019 (CET)

Vielen Dank für die Auswertungen. Beeindruckend ist die Entwicklung der Juryprozesse in Deutschland und in Österreich. Aus einem Mehrtagesmarathon für einige Juroren ist auch in Deutschland jetzt ein Teamwork mit einem zweistufigen Juryprozess geworden. 6,5 Bewertungen pro Bild bei WikiDaheim sind bei so vielen Bildern ein beachtlicher Wert. Wenn man bei der Vorjury noch etwas verbessern will, gibt es grundsätzlich zwei Möglichkeiten:

• Mehr Beteiligung von Jurorinnen und Juroren in der Vorjury bzw. Verlängerung des Juryprozesses (durch früheren Beginn).
• Weniger Bilder für die Vorjury z. B. durch Selbstbeschränkung bzw. verstärkte Benutzung der Kategorie "not for prejury" (nicht für die Vorjury) für Duplikate, Beiwerk wie Informationstafeln etc.

Darüber hinaus könnten durch Einbindung von mehr Leuten in die Vor- und Nachbereitung Synergien erzielt werden. --Regiomontanus (Fragen und Antworten) 06:54, 9. Jan. 2019 (CET)

Den Mehrtagesmarathon gab es trotzdem. --Ailura (Diskussion) 09:25, 9. Jan. 2019 (CET)

Die Frage ist auch, ob man beim Wettbewerb selbst durch konkretere Vorgaben die auszuschließenden Bilder erhöhen kann, was ich persönlich bezweifle, weils der hochladenden Person selbst nix kostet, Bilder für den Wettbewerb einzureichen. --Braveheart ^{Welcome to Project Mayhem} 11:16, 9. Jan. 2019 (CET)

Mich kostet ein Foto im Schnitt 10 Minuten Bearbeitung, wenn ich schnell bin. Da ist Hinfahren noch gar nicht gerechnet. Insoferne ist es nicht ganz gratis, Bilder hochzuladen. Ich hab mal den Vorschlag gemacht, Bilder nach zwei Bewertungen unterhalb einer gewissen Punkteanzahl einfach per Algorithmus für weitere Bewertungen auszuscheiden. Ist aber nicht verstanden worden bzw. auf Wohlwollen gestoßen. Ein aktives Nominieren statt eines aktiven Nicht-Nominierens würde die Anzahl der für den Wettbewerb nominierten Bilder auch radikal senken, allerdings mehr Ansprüche an Neulinge stellen. lg --Herzi Pinki (Diskussion) 18:42, 9. Jan. 2019 (CET)

Ja, die Ansprüche für Neulinge würden steigen, sofern wir nicht alle TeilnehmerInnen mit weniger als xy Fotos nicht automatisch am Wettbewerb teilnehmen lassen. Lass uns das am besten nächsten Donnerstag besprechen und konkreter ausformulieren, inklusive dem Vorschlag mit der Punktebewertung (wo ev. auch Structured Data helfen könnte). LG, --Braveheart ^{Welcome to Project Mayhem} 12:43, 11. Jan. 2019 (CET)

Da es aber gar keine Vorgabe gibt, wie viele Bewertungsdurchgänge von der Vorjury zu absolvieren sein sollten, würden vermutlich 5 auch reichen. Das Ergebnis des Prozesses von Jury und Vorjury und Sondervoten wird durch mehr Durchgänge ab einem gewissen Punkt nicht mehr besser. Unzufriedene auf allen Seiten gibt es auch bei 100 Durchgängen. --Herzi Pinki (Diskussion) 02:56, 14. Jan. 2019 (CET)

Feuerwehrhäuser und andere Themen

wenn auch viele wissen, dass Feuerwehrhäuser mein Thema sind, aber vielleicht kann man das noch etwas in der Erklärung ausweiten auf andere Beispiele von öffentlichen Bauten, wie Gemeindehäuser, Schulen, Kindergärten o.ä. - was vielleicht auch ein Thema wäre, sind die 100.000 Kreisverkehre, die für andere ganze Bücher hergeben, warum nicht für uns auch. Nicht nur in NÖ wurden durch erwin viele errichtet, auch in den anderen Bundesländern. --K@rl du findest mich aber hauptsächlich im RegiowikiAT 19:59, 15. Jan. 2019 (CET)

Stimmt, danke für den Hinweis :-) --Braveheart ^{Welcome to Project Mayhem} 10:58, 16. Jan. 2019 (CET)

Structured data

So viel ich weiß gibt es ab März einzelne (ausgewählte) Pilotprojekte zu Structured Data, z.B. Sammlungen von Kulturgütern, die dann im 2. Halbjahr 2019 evaluiert werden. Ob das für uns schon reif ist bzw. helfen kann? Prinzipiell kann ich es mir vorstellen, aber jetzt schon? --Regiomontanus (Fragen und Antworten) 23:34, 11. Jan. 2019 (CET)

Wann kann WMAT eine Schulung anbieten? Muss wohl erstes Quartal sein. Evaluierung im 2. Halbjahr käme zu spät, außer wir wollen uns mit bleading edge technologie auseinandersetzen. Allein schon das neue Feature der Captions macht den Upload-Wizard noch unfreundlicher und fehleranfälliger für die HochladerInnen, d.h. es muss mit erhöhtem Nachbearbeitungsaufwand gerechnet werden, siehe Commons:Commons:Village_pump#Good_practice_? (en.). Und bis Sommer kommt da noch was dazu, vermutlich auch im UW. Vielleicht sollten wir jeden Bewerb 2019 erst mal sistieren? Ohne klares Konzept, was die Benutzung von structured data für WD bedeutet, und wie das umzusetzen ist, kann die Entscheidung nächste Woche zu structured data eigentlich nur Nein heißen. Kann jemand bis Montag so ein Konzept erstellen? lg --Herzi Pinki (Diskussion) 02:07, 12. Jan. 2019 (CET)

@Braveheart: Was SD betrifft, worum geht es?

1. dass die Uploader mit dem Upload auch SD erfassen?
2. dass irgendjemand SD für alle Objekte von WD zur Verfügung stellt und diese dann dem Uploader helfen, den Upload richtig zu machen?

--Herzi Pinki (Diskussion) 18:24, 12. Jan. 2019 (CET)

@Herzi Pinki: Primär darum, dem Bild im UploadWizard mehr Informationen mitzugeben bzw. dem Benutzer dies zu ermöglichen. Verknüpfung mit Wikidata-Item wäre auch angedacht. Im Idealfall hätten wir eine Checkliste, die die Benutzer mit SD befüllen können. Theoretisch würde das den Check danach einfacher bzw. obsolet machen? LG, --Braveheart ^{Welcome to Project Mayhem} 08:28, 16. Jan. 2019 (CET)

Ist doch illusorisch, dass sich Wettbewerbsteilnehmerinnen aktiv mit dem Ausfüllen der structured data beschäftigen. Will man das, muss nachgearbeitet werden und dazu braucht es die entsprechende Workforce. Verknüpfung mit WD wäre auch angebracht - heißt was beim Bild? Dass, dort wo in WD ein Bild fehlt, dieses unter der Property Bild (P18) eingefügt wird, oder was anderes? lg --Herzi Pinki (Diskussion) 10:23, 16. Jan. 2019 (CET)

So wie es von den SD-Verantwortlichen klingt, ist das nicht illusorisch, sofern das Ausfüllen von SD z.B. die Kategorien ersetzt. Momentan wären wir in der Lage (wenn wir morgen beschließen sollten, das das einen Versuch wert ist), dem SD-Team unsere Wünsche und Anforderungen mitzugeben, die diese bis April/Mai umsetzen würden. Im Konkretfall würden mir spontan folgende Anforderungen einfallen:

• Verwendung von SD statt Kategorien, d.h. Eingabe auf Deutsch und entsprechend benutzerfreundlicher gestaltet - die Kategorien würden sich dann automatisch aus den SD-Werten ergeben
• Mitgabe von SD-Werten aus der WikiDaheim-Oberfläche für die Bilder
• Verknüpfung mit dem Image-Property(P18) auf Wikidata. Dafür muss man sich aber erstmal die Datenlage ansehen, bei den Denkmalen wird das sicher net so einfach :-/

LG, --Braveheart ^{Welcome to Project Mayhem} 10:57, 16. Jan. 2019 (CET)

Die SD-Verantwortlichen versuchen ihr Ding zu pushen. Nach dem Rollout der Captions würde ich denen maximal 50 % glauben. Für dem Ersatz der Kategorien durch SD würde es einen Communityentscheid brauchen, siehe Commons:Commons_talk:File_captions#Category_captions.

Wie würden sich die Kategorien automatisch aus den SD Werten ergeben? Es ist nicht mal klar, ob beides parallel existieren soll oder ob SD die Kategorien ersetzen soll. Und was primär und was sekundär ist.

Wie können wir auf etwas verlinken, was in SD den Kategorien entspricht und in den Tabellen massenhaft als commonscat eingetragen ist?

Die Mitgabe von SD Werten aus der WikiDaheim-Oberfläche für die Bilder: schön und gut, aber wo kommen diese SD-Werte her? Ich erinnere daran, dass auch irgendwelche Bilder mit Themenbezug Österreich hochgeladen werden können. Wie schaut das aus bei vermuteten fehlenden Bildern wie Schulen, Friedhöfen, Sportplätzen, wo wir annehmen, dass praktisch jeder Ort darüber verfügt und wo wir aus dem Fehlen eines Bildes in einer bestimmten Kategorieschnittmenge einen Eintrag in WD machen, aber im Prinzip fast nix über das Objekt wissen (wir vermissen Schulen, aber sind das Volksschulen, Hauptschulen, etc. wissen wir nicht, bei Sportplätzen kann das eine Kegelbahn, ein Fußballplatz oder ein Basketballkäfig sein, WD weiß das nicht)? Aber selbst bei Denkmälern u.a., wo kommen die SD Werte her: z.B. ein naturdenkmalgeschützter Baum bräuchte mindestens einen Ort und eine Species, Public art einen Ort, einen Titel, ein Jahr und einen Künstler (der Künstler steht in den public art Listen, aber es gibt nicht für jeden Künstler eine WD-Eintrag. Wer soll die machen, oft haben wir nur den Namen?), ein Denkmal einen Typ (Schloss, Pfarrhof, Stadtmauer, Bildstock, etc., die Information gibt es nicht strukturiert).

Die Mitgabe von SD Werten aus der WikiDaheim-Oberfläche für die Bilder: wie geht das konsistent bei alternativen Hochlademechanismen (direkt über die Listen, andere Uploader)? Wenn nicht, wer macht die Nacharbeit?

Du überzeugst mich nicht. lg --Herzi Pinki (Diskussion) 11:59, 16. Jan. 2019 (CET)

Ich bin nicht hier, um dich zu überzeugen - mir gehts um die Möglichkeiten, die SD bieten würde. Wenn wir morgen draufkommen, dass SD für uns nix bringt, werden wirs auch net machen. --Braveheart ^{Welcome to Project Mayhem} 13:43, 16. Jan. 2019 (CET)

P.S.: Und ja, wie schon vorher angedeutet, wirds ohne sinnvolle Wikidata-Informationen zu den Objekten wenig für SD zu tun geben. --Braveheart ^{Welcome to Project Mayhem} 13:45, 16. Jan. 2019 (CET)

Wo sollen die sinnvollen Wikidata-Informationen zu den Objekten herkommen, und wer verbindet die Friedhöfe, Basketballkäfige, Linden und Mosaike mit den entsprechenden WD-Einträgen?

Welche Möglichkeiten bietet SD konkret für Wikidaheim?

Was ich mir vorstellen kann: Jedes Objekt bekommt beim Upload soweit möglich eine oder mehrere Wikidata-IDs und damit implizit alle Properties aus dem entsprechenden Wikidata-Objekt. Die werden aber nicht kopiert, sondern immer direkt von Wikidata abgegriffen. Das würde der Information entsprechen, die jetzt in den Kategorien über die Wikidata Infobox angezeigt wird. Nur so lässt sich mit unvollständigen und fehlerhaften Wikidata-Enträgen arbeiten, ohne millionenfach Nacharbeit an den Bildern. Das sind zwar objektspezifische Properties, keine bildspezifischen Properties (Angaben zu Details, zu Aufnahmedaten soweit sie nicht aus den Exif-Daten eruierbar sind, etc., könnten bildindividuell hinzugefügt werden, aber das wäre ohnehin außerhalb des Scopes von Wikidaheim). Statt Commonscat-Einträgen müsste halt jemand die Wikidata-Einträge zu den Objekten erstellen. Ich fürchte, dass bei der Eingabe von SD über das Hochladeformular die Bedienung ähnlich ist wie bei Wikidata, d.h. jedes Property ist einzeln einzutragen. Verglichen mit einer Schnittstellenkategorie, die mit cat-a-lot mit einem Schritt auf viele Bilder gepickt werden kann, würde die Anzahl der notwendigen Aktionen bei einer Oberfläche a la Wikidata um zwei Ordnungen größer sein (1. viele einzelne SD-Properties statt Schnittstellenkategorie und 2. für jedes Bild extra).

Ich überlege das jetzt um mir vor morgen eine Entscheidung zurechtzulegen. Wenn wir das morgen inhaltlich diskutieren, dann fallen alle anderen Punkte unter den Tisch, oder wir machen open end. Bisher habe ich kein Konzept gesehen, aber nur über ein solches könnten wir entscheiden. lg --Herzi Pinki (Diskussion) 19:41, 16. Jan. 2019 (CET)

Nur eine Frage: Ich weiß, ich war bei der Besprechung ja net dabei, aber bietet SD schon tatsächlich eine nachhaltige Lösung als Ersatz für Kategorien, oder ist das ganze ein Pilot, der nächstes Jahr entweder wieder vergessen oder ganz anders ausschaut. Derzeit bin mir nicht sicher, dass das Newbies so zuzumuten ist, dass nicht für die derzeitigen User, die ja nicht unbedingt mehr werden (Herzi Pinki lässt sich ja nicht klonen ;-) mehr Arbeit entsteht, als es erleichtert. --K@rl du findest mich aber hauptsächlich im RegiowikiAT 14:21, 22. Jan. 2019 (CET)

Uploader mit Anmeldedatum

Hallo und @Raimund Liebert (WMAT): Mit https://quarry.wmflabs.org/query/30382 gibt es jetzt die Uploader zu WikiDaheim 2018 mit Anmeldedatum. Bei einigen alten usern scheint es kein Anmeldedatum zu geben. lg --Herzi Pinki (Diskussion) 16:19, 21. Jan. 2019 (CET)

Danke; allerdings scheint es beim Datum nicht anzuzeigen, wann das Benutzerkonto angelegt wurde, sondern wann es erstmals auf Commons aktiv war. Benutzer:Funke ist z. B. schon um Einiges älter als 2007-01-03. --Raimund Liebert (WMAT) (Diskussion) 16:26, 21. Jan. 2019 (CET)

Danke für die Kontrolle, ad Funke: https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Funke scheint überhaupt erst am 30. Jun. 2010 aktiv geworden sein. Daten vor 3. Okt. 2008 sein es nicht zu geben: https://meta.wikimedia.org/wiki/Special:CentralAuth?target=Herzi+Pinki. Vor Sul würde ich die Werte auch nicht ernst nehmen. Aber du hast auch Recht, vermutlich handelt es sich um das Datum des ersten Edits auf commons. Auf meta werden nochmals andere Daten geliefert, https://quarry.wmflabs.org/query/32836 als Muster.

Für die neuen Benutzer könnte es aber besser aussehen? Wie kriegst du das raus? --Herzi Pinki (Diskussion) 17:06, 21. Jan. 2019 (CET)

Für mich gibt es hier Daten ab 1. Juni 2008 (während ich mit diesem Benutzernamen seit 2. Dezember 2005 auf de aktiv bin). Für meinen alten Benutzernamen gibt es mit 17. März 2015 einen völlig sinnlosen Eintrag, denn das Passwort dieses Benutzers ist mit seit 2006 nicht mehr bekannt. --TheRunnerUp 08:22, 22. Jan. 2019 (CET)

Projektbesprechung am 14. Februar

Folgetermin zum Projektstart, wieder an einem Donnerstag, genauer am 14. Februar um 18 Uhr in der Geschäftsstelle von WMAT in der Stolzenthalergasse 7, 1080 Wien. Bitte in der nachfolgenden Agenda Punkte ergänzen:

• Feedback von Herzi Pinki
• Genauere Durchbesprechung der neuen Vorjury-Methode
• Einbindung von Wikivoyage
• Feedback zu Structured Data
• ...

Teilnahme

• --Braveheart ^Diskussion 21:16, 24. Jan. 2019 (CET)
• --Herzi Pinki (Diskussion) 00:58, 25. Jan. 2019 (CET)
• ...

Auf commons wird schon Teilnahme vorgeschlagen

Wenn man auf commons Denkmalfotos hochlädt, wird einem schon jetzt die Teilnahme an WLM 2019 (!, der Link führt dann zu WikiDaheim) vorgeschlagen.--Niki.L (Diskussion) 21:27, 17. Jun. 2019 (CEST)

@Niki.L: Danke für den Hinweis, habs auf Commons aus der Kampagne mal bis 1. Juli rausgenommen. --Braveheart ^Diskussion 09:59, 18. Jun. 2019 (CEST)

danke (nach BK). Es ist unklar, welche Wettbewerbe überhaupt stattfinden, wofür Preise ausgelobt werden und was die Beginn- und Endedaten der jeweiligen Wettbewerbe sind. Bekannt ist nur, dass WikiDaheim vom 1.7. bis zum 6.10. stattfindet. Campaigns haben mW keine Möglichkeit, einzelne Felder datumsabhängig auszublenden. Die Kategorie zur Teilnahme an WikiDaheim wird aber nur in diesem Zeitraum erzeugt, außerhalb hat das Feld und die Selektion keine Wirkung. lg --Herzi Pinki (Diskussion) 10:09, 18. Jun. 2019 (CEST)

Es wäre aber schön, wenn der Link irgendwann auf Wiki Loves Monuments 2019/Österreich führen könnte. --Herzi Pinki (Diskussion) 10:11, 18. Jun. 2019 (CEST)

@Regiomontanus: Die WLM-Seiten müssen wir bis Anfang Juli einrichten. --Braveheart ^Diskussion 10:13, 18. Jun. 2019 (CEST)

Danke für die Hinweise, ich kümmere mich darum. --Regiomontanus (Fragen und Antworten) 11:09, 18. Jun. 2019 (CEST)

@Braveheart, Herzi Pinki: Im Vorjahr hatten wir für den Sonderpreis zum Tag des Denkmals den Hochladezeitraum vom 1. September an bis 1. So. im Okt. wie WikiDaheim. WLM, d.h. die Denkmalfotos von WikiDaheim, war von 1. Juli bis zum 1. So. im Okt. Bleibt das so, also ist das mit WLM-International so kommuniziert? MfG --Regiomontanus (Fragen und Antworten) 15:07, 21. Jun. 2019 (CEST)

@Regiomontanus: Ja, war die letzten beiden Jahre davor auch schon so, dass WLM bei uns effektiv von 1. Juli bis 6. Oktober läuft. :-) --Braveheart ^Diskussion 17:55, 21. Jun. 2019 (CEST)

d.h. WikiDaheim, WLM (nicht national, ohne Jury, freihändige Auswahl), Tag des Denkmals sind die Bewerbe. Keine Innenansichten, keine Kellergassen, keine ... --Herzi Pinki (Diskussion) 18:17, 21. Jun. 2019 (CEST)

Die Kurzfassung verstehe ich noch nicht ganz. WLM: Warum nicht national? Warum ohne Jury? Es gab ja im Vorjahr auch eine Jury dafür. Den Juryprozess muss man noch optimieren, das haben wir in der Nachbesprechung gesagt. Sonderpreise sind wie im Vorjahr Innenansichten und Tag des Denkmals, wobei der TdD eine kürzere Einreichfrist (ab 1. Sept. 2019) hat, weil die Listen erst Mitte Juli bekannt sein werden. Einreichen kann man dann auch Bilder (aus den Listen), die schon vor dem 1. Sept. gemacht wurden, weil die Listen schon früher bekannt sein werden, aber der Einreich-Startpunkt ist der 1. Sept. Ich hoffe, wir können das so kommunizieren. Vielleicht gibt es dazu Vorschläge. MfG --Regiomontanus (Fragen und Antworten) 19:58, 21. Jun. 2019 (CEST)

Wieso machen wir WLM und Tag des Denkmals extra auch noch? Brauchen wir wirklich die paar Ausnahmen, die zwar im Rahmen des TdD bespielt werden, aber nicht denkmalgeschützt sind? --Braveheart ^Diskussion 12:51, 23. Jun. 2019 (CEST)

Mein Vorschlag ist, hier mal die 2018 auf 2019 zu ändern: [1]. Bwag 20:04, 21. Jun. 2019 (CEST)

Danke für den Hinweis, ist korrigiert. --Braveheart ^Diskussion 12:51, 23. Jun. 2019 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: --Braveheart ^Diskussion 13:33, 1. Jul. 2019 (CEST)

WikiDaheim-Sticker

@Herzi Pinki, Regiomontanus, Ailura, Braveheart, AleXXw: Mir ist eine Idee für WikiDaheim gekommen: Wir könnten Stickers mit einem QR-Code, darin integriert dem WikiDaheim-Logo und vielleicht einem kurzen motiverenden Text drucken. Diese Sticker könnte man dann an noralgischen Stellen in der Stadt verteilen und so hoffentlich weitere Leute und/oder Fotografen ansprechen. Toll wäre, wenn man auf diese Weise motivierte Reisefotografen für das Projekt gewinnen kann, insbesondere, weil die einen ganz anderen und unvoreingenommen Blick auf die Orte haben. Rechts seht ihr einen ersten Vorschlag meinerseits. –Simon04 (Diskussion) 18:12, 9. Jun. 2019 (CEST)

Meinst Du damit auslegen oder wild kleben? Letzteres haben wir IIRC vor langer Zeit mal verworfen, weil verboten. Ich finde im Beispiel die roten Ecken zu ablenkend, der Rest gefällt mir. --Ailura (Diskussion) 19:08, 9. Jun. 2019 (CEST)

Wir konnten seinerzeit leider auch keine QR Codes mit WP-ball machen, da ...Although DENSO WAVE waives its rights to QR Codes as long as they follow the JIS or ISO standard, this is not necessarily the case with codes that do not follow the standard. DENSO WAVE may decide to exercise its patent rights against such codes. (siehe It is all right to use QR Codes with colors or an inserted illustration?) --Ruben Demus (Diskussion) 20:37, 9. Jun. 2019 (CEST)

Hallo, Simon, schöne Idee. Je länger ich mir das Bild ansehe, desto besser gefällt es mir. Aber offenbar ist es in dieser Form lizenzrechtlich nicht ganz gedeckt. Danke, Ruben, für die schnelle Reaktion. Ganz kenne ich mich allerdings noch nicht aus. Offenbar sind kreative Weiterbearbeitungen wie bei einer CC-Lizenz hier nicht gestattet. --Regiomontanus (Fragen und Antworten) 07:52, 10. Jun. 2019 (CEST)

Das Logo muss ja nicht mitten im QR liegen, kann auch so wie der Text WikiDaheim drunter sein. Ich geh übrigens nicht Sticker verteilen. lg --Herzi Pinki (Diskussion) 09:24, 10. Jun. 2019 (CEST)

+1, minus dem Stickerverteilen ;-) @Simon04:. --Braveheart ^Diskussion 16:32, 12. Jun. 2019 (CEST)

Unklarheit bzgl. Rathaus

In Radstadt wird das Rathaus / Gemeindeamt als fehlendes Bild in wikidaheim.at ausgewiesen, allerdings gibt es File:Rathaus Radstadt.jpg und mE ist das auch richtig kategorisiert. Wo ist das Problem? lg --Herzi Pinki (Diskussion) 07:13, 21. Jul. 2019 (CEST)

Die Kategorien und Bilder aus Town halls and municipal offices in Austria werden prinzipiell eingelesen und somit auch File:Rathaus Radstadt.jpg. In der Gemeinde Radstadt wurden alle Bilder sowie 3 Unterkategorie Ebenen hinunter eingelesen. In diesen wurde aber immer nur Audio und Videofiles sowie die Subkategorien mit den Suchkategorien abgeglichen. Das war bisher ausreichend, da bei einer Unterkategorie 'Rathaus Radstadt' ja ein Treffer wäre (selbst wenn diese nicht direkt auf Gemeindeebene sondern in commons:Category:Cultural heritage monuments in Radstadt wäre. Da das Foto hier aber neben anderen in der Kategorie liegt - Ich hätte es übrigens bei der manuellen Suche in der Gemeindeebene auf Commons ohne Insiderwissen über Denkmalschutz und Wikipedia sicher auch nicht wirklich dort vermutet oder gesucht... - wurde es somit auch nicht verglichen und angezeigt. Hat auch ein paar Jahre gedauert bis so ein Fall auftaucht. Testweise werden nun alle Fotos der 1. Unterebene zusätzlich zur Gemeindeebene ausgewertet. Der zeitliche Aufwand zum Auslesen und Abgleichen erhöht sich somit entsprechend. Wenn es unter 24h (bisher waren wir bei ca. 12-14) bleibt, so können wir das auch so lassen. Wenn er über große Gemeinden garnicht drüber kommt, dann melde ich mich noch mal. Es würde dann nur bleiben auf diese Bilder zu verzichten, manuell bestimmte Kategorien in großen Gemeinden zu überspringen, das/die Fotos zusätzlich in die Gemeindeeben zu legen bzw. dem entsprechende Objekt ein entsprechende eigene Kategorie zu spendieren. --Ruben Demus (Diskussion) 23:33, 21. Jul. 2019 (CEST)

Das Foto wird nun angezeigt. Mit ~17h für einen Durchgang noch ganz erträglich. Sollte somit erledigt sein? --Ruben Demus (Diskussion) 17:04, 22. Jul. 2019 (CEST)

Es waren mehrere Rathäuser. Nun erl.

Archivierung dieses Abschnittes wurde gewünscht von: Herzi Pinki (Diskussion) 18:00, 22. Jul. 2019 (CEST)

Bilderwünsche in WD

Wenn ich die Bilderwünsche in der WD app mit den Bilderwünschen in Simons Tool vergleiche, gibt es doch massive Diskrepanzen.

• https://tools.wmflabs.org/bldrwnsch/?filter=#12/47.2255/12.3307 und https://wikidaheim.at/, Gemeinde Neukirchen am Großvenediger.

Gibt es dafür eine Erklärung oder ist das ein Fehler? @Simon04, Thomas Ledl, Ruben Demus: lg --Herzi Pinki (Diskussion) 14:53, 21. Jun. 2019 (CEST)

Wikidaheim zeigt auch Objekte, für die es keinen Bilderwunsch (mehr) gibt. --Thomas Ledl (Diskussion) 21:52, 21. Jun. 2019 (CEST)

Ach ja, da fällt mir ein, die BW in WD sind ein veralteter Datenstand. Ob das die Differenzen erklärt? lg --Herzi Pinki (Diskussion) 22:41, 21. Jun. 2019 (CEST)

Glaub die momentanen Bilderwünsche stammen noch aus dem veralteten Stand von letztem Jahr, falls Ruben das noch nicht umgestellt hat. --Braveheart ^Diskussion 12:52, 23. Jun. 2019 (CEST)

Sollte mit der Abfrage auf die neue api nun behoben sein. Für in anderen Datenbeständen doppelt erkannte Objekte wird aber kein zusätzlicher Pin/Eintrag in den Listen neben den Tabellen erstellt. --Ruben Demus (Diskussion) 01:23, 1. Jul. 2019 (CEST)

Kellergassen: es werden nur die bereits bebilderten Gassen vorgeschlagen?

Auf der wikidaheim-Seite werden einem nur die bereits bebilderten Kellergassen vorgeschlagen: z.B. sieht man für die Gemeinde Ziersdorf nur die 19 Kellergassen, zu denen es in der wikipedia-Kellergassenliste bereits Bilder gibt; man sieht auf wikidaheim aber nicht die 5 Gassen, für die noch Bilder in wikipedia fehlen.--Niki.L (Diskussion) 11:13, 1. Jul. 2019 (CEST)

@Ruben Demus: Sieht aus, als ob nicht alle Einträge geliefert werden? Falls ja, muss man mit Bene klären, woran das liegt. LG, --Braveheart ^Diskussion 13:32, 1. Jul. 2019 (CEST)

Von der api werden meiner Meinung nach die richtigen Daten geliefert. Nachdem 5 Objekte fehlen und ebensoviele eine Überschneidung mit Bilderwünschen haben, fürchte ich, dass hier Bene in seinem Filter noch etwas korrigieren muss.--Ruben Demus (Diskussion) 14:44, 1. Jul. 2019 (CEST)

Ticket wurde auf Github erstellt und Bene zugewiesen - das Problem scheint sich auch nur auf die Filterung über das Kellergassen-Icon zu beziehen - wenn ich nur nach fehlenden Bildern filtere, sind die fehlenden Kellergassen dabei. --Braveheart ^Diskussion 15:29, 1. Jul. 2019 (CEST)

Wurde korrigiert, siehe Ticket #71. Hat bei mir nach einem Refresh der kompletten Seite funktioniert mit Ziersdorf. --Braveheart ^Diskussion 17:13, 2. Jul. 2019 (CEST)

super, danke! --Niki.L (Diskussion) 18:32, 2. Jul. 2019 (CEST)

Abgegangene Objekte

Vielleicht kann man Objekte die nicht mehr existent sind, irgendwie herausfiltern. Ich habe nur geseh, dass bei der Zollegstätt-Kaserne an der jetzt ein ganz anderes Gebäudes steht ein Fotowunsch ist. --K@rl 13:00, 5. Jul. 2019 (CEST)

@Karl Gruber: Das ist genau eine jener Fragen, die ich für mich nie richtig klären kann - wollen wir diese Objekte ganz rausnehmen, obwohl es einen Fotowunsch gibt? Gäbe es nicht theoretisch Personen bzw. Organisationen, die im Besitz von Bildern der Kaserne wären? Wäre es nicht auch angebracht, die heutige Verwendung nachzuweisen?

Zumindest technisch gesehen kann man die relativ einfach rausfiltern, wenn in Wikidata ein Auflösungsdatum angegeben ist. --Braveheart ^Diskussion 13:29, 5. Jul. 2019 (CEST)

Zu deiner Frage nach Bildern, da gibt es sicher welche, allerdings nicht unter freier Lizenz. ich finde sowas immer in der http://topothek.at auf die ich im Regiowiki immer verlinke und ich mit dieser auch gut zusammenarbeite. Es arbeiten dort auch Wikipedianer mit. Aber solche links sind in Wikipedia nicht erwünscht - diese werfahrung habe ich schon öfters gemacht. --K@rl 15:38, 5. Jul. 2019 (CEST)

Ist z.B. bei diesem Bild nicht schon längst das Urheberrecht erloschen? --Braveheart ^Diskussion 12:24, 6. Jul. 2019 (CEST)

Ist möglich,aber mit Kopierschutz versehen ;-) - da tribulier ich nicht, denn es heißt /0 J. nach Veröffentlichung --K@rl 16:22, 7. Jul. 2019 (CEST)

Public Art

Kleiner Hinweis: Die Daten der Wikipedia sind bei den Listen von Linz nicht mehr aktuell. Ich habe unlängst einige Einträge in den Listen nicht mehr auf der Seite der Stadt Linz gefunden. z.b. [Kleinmünchen] [2] und [3]. Möglicherweise sind auch welche hinzugekommen, habe ich jetzt nicht überprüft. Gibt es eine Möglichkeit, die Daten automatisch zu prüfen? --Geiserich77 (Diskussion) 15:45, 4. Jul. 2019 (CEST)

@Geiserich77: Ah, vielen Dank für den Hinweis! Die Daten auf WikiDaheim beziehen sich auf die entsprechenden Listen in Wikipedia. Die Einträge müssten in der Liste entfernt werden, damit sie nicht mehr angezeigt werden - oder wir bauen ähnlich wie bei den Denkmallisten einen eigenen Abschnitt "Ehemalige Kunst"? LG, --Braveheart ^Diskussion 10:06, 5. Jul. 2019 (CEST)

Eigentlich entfernen wir keine Einträge (Relevanz vergeht nicht und so), sondern verschieben immer nur nach "ehemalige..". Weiß man warum die Sachen nicht mehr in der Liste stehen? Sind die wirklich nicht mehr da? --Ailura (Diskussion) 13:22, 5. Jul. 2019 (CEST)

Mir ist keine Möglichkeit bewusst, die Daten einfach & automatisch zu prüfen. Ehemalige bitte nach 'Ehemalige Kunstwerke' verschieben. lg --Herzi Pinki (Diskussion) 23:08, 8. Jul. 2019 (CEST)

Die Datenbank schneidet etwas anders als WP. Mir ist die Abbildung der Linzer Stadtteile auf unsere Listen nicht klar. Mit https://stadtgeschichte.linz.at/denkmal/Default.asp?action=search&krit=Stadtteile&inp_suche=id von id=1 Innere Stadt bis id=16 Pichling bekommst du jedenfalls Auflistungen der Denkmäler in den 16 Linzer Stadtteilen.lg --Herzi Pinki (Diskussion) 06:45, 9. Jul. 2019 (CEST)

Eventuell hat ja das Archiv in Linz eine kompaktere Listendarstellung? --Herzi Pinki (Diskussion) 06:50, 9. Jul. 2019 (CEST)

GPX-Datei

Auch heuer gibt es offenbar Startschwierigkeiten beim Download der GPX-Dateien: Anstatt einer gemeindespezifischen GPX-Datei landet immer eine 257 Bytes kleine PHP-Datei am Datenträger.--Duke of W4 (Diskussion) 16:23, 30. Jun. 2019 (CEST)

Das Back-end sollte hier eigentlich problemlos GPX-Dateien liefern. Die alte Abfrage funktioniert bei mir problemos. Download von Teillisten wie etwa der Bilderwünsche müssen aber noch vom Front-end entsprechend verlinkt werden. Sollte es irgendwo nicht klappen, bitte um ein Beispiel. --Ruben Demus (Diskussion) 01:40, 1. Jul. 2019 (CEST)

Der GPX-Download funktioniert wieder. Danke! --Duke of W4 (Diskussion) 06:47, 1. Jul. 2019 (CEST)

Dem kann ich nicht zustimmen. Ich hatte gestern das Problem in Lienz, da ich eine Stunde Umsteigezeit hatte, die ich nützen wollte. Die Datei ließ sich nicht runterladen und es funktioniert auch jetzt noch nicht. Es fragt mich zwar, ob ich die Datei öffnen will, aber wenn ich da draufklicke, schlägt es mir nur Anwendungen vor, mit denen ich sie nicht öffnen kann (Kalender, SIM-Kontakt hinzufügen, DB-Navigator ...) oder Google Maps - weder will ich sie mit letzterem öffnen, noch hat es funktioniert (da es nur eine Stunde war, dachte ich mir, okay, aber es waren keine Objekte auf GMaps zu sehen). Ich will die Dateien einfach nur in den Downloads-Ordner downloaden, um sie dann mit dem netzunabhängigen mobilen OpenStreetMap zu öffnen. Außerdem hüpft am Smartphone die Liste wild herum, wenn man hinunterscrollt und am unteren Ende ankommt. Liebe Grüße, --Häferl (Diskussion) 13:55, 1. Jul. 2019 (CEST)

Bei mir unter iOS funktioniert die Linz-GPX. Wenn es sich um ein Androidproblem handelt, so brächte ich mehr Infos/eine funktionierende GPX (da ich leider keine passende Hardware zum Testen habe) um eventuelle Unterschiede festzustellen. Am Listenproblem der mobilen Ansicht arbeitet Bene bereits - siehe oben in den Notizen zur Besprechung am 27. Juni 2019. --Ruben Demus (Diskussion) 14:59, 1. Jul. 2019 (CEST)

Mit dem letzten Update des Front-end werden auch Teillisten korrekt verlinkt. Bei Problemen bitte um möglichst konkrete Beispiele. --Ruben Demus (Diskussion) 17:28, 2. Jul. 2019 (CEST)

Der Upload funktioniert zwar inzwischen, aber die Datei legt sich nicht in den Download-Ordner ab, sondern ich hab sie da gefunden, wo verfügbare App-Updates aufgelistet werden. Das liegt nicht an meinen Einstellungen, denn von anderen Quellen legen sich alle gpx-Dateien im Download-Ordner ab. Was weiterhin nicht funktioniert, ist die Möglichkeit, in der gpx-Datei nur fehlende Objekte zu erhalten (oder überhaupt die Filter anzuwenden). Entschuldigung für die späte Rückmeldung, war zwischenzeitlich weg und dann war mein Smartphone weg (das ich aber dank Google-Ortung und einer kleinen Mithilfe der Polizei inzwischen wiederhabe). Liebe Grüße, --Häferl (Diskussion) 16:52, 10. Jul. 2019 (CEST)

Sorry, kann dein Problem trotz ausgiebigen Versuchen leider nicht nachvollziehen und somit nicht fixen. Wenn es möglich wäre (auch wenn ich keine Ahnung habe, wie ich das veranlassen würde) als externer Websitebetreiber zu bestimmen, wohin eine Datei auf deinem Gerät gespeichert wird, dann läuft seitens des Betriebssystems einiges falsch. Kann das beschriebene Verhalten auch jemand Anderer mit Android bestätigen?--Ruben Demus (Diskussion) 10:09, 16. Jul. 2019 (CEST)

Je nach Auswahl der anzuzeigenden Inhalte werden bei mir unterschiedliche Listen als gpx heruntergeladen. Der Filter für nur fehlende Bilder ist der graue Button Bilderwünsche. Andere fehlende Inhalte (Beschreibungen etc.) haben in der gpx nichts zu suchen. Daher existiert diese Auswahlmöglichkeit auch nicht.--Ruben Demus (Diskussion) 10:09, 16. Jul. 2019 (CEST)

Zum frühzeitigen Aussortieren von Bildern in der Vorjury

Wie am 17.1. besprochen, sollen Bilder mit wenigen Punkten frühzeitig aus dem Vorjuryprozess ausgeschlossen werden und weitere Vorlagen eines chancenlosen Bildes vermieden werden. Mathematischer Background dazu:

Ansatz

(1) Im folgenden bezeichnen p die durchschnittlichen Punkte, und P die aufaddierten Punkte eines Bildes. Nach k Bewertungen gilt:

pk = Pk / k

individuell pro Bild. Im Prinzip sind die aufsummierten Punkte und der Punkteschnitt gleichwertig, der Punkteschnitt erlaubt allerdings eine unterschiedliche Anzahl von Bewertungen pro Bild. Das ist der Grund, warum wir mit dem Punktschnitt arbeiten.

(2) Wir betrachten das Bild, das es als 500. (allgemein L) gerade noch durch die Vorjury geschafft hat. Dieses hatte im Schnitt p_limit Punkte. Alle Bilder die die Vorjury überstanden haben, hatten p ≥ p_limit Punkte (liegen im oberen Bereich und gehen weiter an die Jury), die anderen p < p_limit Punkte (liegen im unteren Bereich und scheiden aus). Nach insgesamt d Bewertungen kann ein Bild, das nach k Bewertungen p_k Punkte erhalten hat, d > k, am Ende nur insgesamt

pk + 5*(d-k)

Punkte erreichen.

Beispiel für d=6, k=2 und p_limit=4: In den verbleibenden 4 Durchgängen kann ein Bild maximal noch 4*5 = 20 Punkte erreichen, damit

(20+P2)/6 ≥ 4

ist, muss

P2 ≥ 4 (wolframalpha)

sein. Bilder, die nach zwei Runden weniger als 4 Punkte haben, können rein rechnerisch nicht mehr unter die letzten 500 (L) kommen.

(3) Die Anzahl der endgültigen Durchgänge kennen wir nicht im Voraus, hängt von vielen Faktoren ab. Wir wissen aber, dass bisher Bilder sich in der Anzahl der Durchläufe gerade mal um 1 unterscheiden können, weil Bilder, die mit den Bewertungen im Rückstand sind, bevorzugt zur nächsten Bewertung vorgelegt werden. In Ausnahmefällen (etwa wenn alle Bilder mit Rückstand schon vom aktuellen Vorjuror bewertet wurden) kann der maximale Unterschied der Bewertungen je Bild auch größer 1 werden. Wenn wir Bilder frühzeitig nach wenigen Bewertungen ausscheiden, da diese es ohnehin nicht mehr in die Auswahl der Vorjury schaffen, ändert das nichts am Ergebnis der Vorjury, auch wenn der Unterschied in der Anzahl der Bewertungen größer als 1 wird. Ein solcher Unterschied betrifft fast immer ein Bild aus der Auswahl der Vorjury und ein Bild, das es nicht in die Auswahl der Vorjury schaffen würde, auch wenn es die volle Anzahl an Bewertungen und dabei die jeweils vollen 5 Punkte bekommen würde. Fälle, in denen sich die Bilder in der Anzahl der Bewertungen um mehr als 1 unterscheiden, werden hier ignoriert.

Verallgemeinerung

(4) Wir machen die Anzahl der Durchgänge variabel. Sei d_max die größte Anzahl von Bewertungen bei einem der Bilder (nicht die Anzahl vollständiger Durchläufe). Für alle anderen Bilder b gilt:

db ≤ dmax.

Ein Bild kann in der Situation maximal noch

dmax − db + 1

Bewertungen bekommen. +1, weil es Bilder gibt, die eine Bewertung mehr haben können als die anderen. Wir nennen die aufaddierten Punkte, die ein Bild nach d_b = k Bewertungen hat, P_k. Die maximal erreichbaren Punkte für diese Bild bis zum Erreichen der aktuellen Maximalanzahl an Bewertungen ergeben sich dann nach

(5*(dmax-k)+Pk)/(dmax) ≥ plimit

bzw. bei Überschreiten der aktuellen Maximalanzahl an Bewertungen um 1 zu

(5*(dmax-k+1)+Pk)/(dmax+1) ≥ plimit

(5) Nach Auflösen der Ungleichung

(5*(dmax-k+1)+Pk)/(dmax+1) > (5*(dmax-k)+Pk)/(dmax)

ergibt sich mit

Pk < 5*k (wolframalpha)

eine wahre Aussage, nach k Runden à 5 Punkten kann ein Bild nicht mehr als maximal 5*k Punkte bekommen haben, insoferne muss, um die Chancen eines Bildes auf einen Erfolg in der Vorjury intakt zu lassen, mit der größeren Anzahl an Durchläufen gerechnet werden. Dies ist logisch, da mit fetten 5 Punkten in der max+1 ten Runde die Chancen auf einen Erfolg in der Vorjury steigen.

(6) Also kann o.B.d.A ein Bild in dieser Situation maximal

(5*(dmax-k+1)+Pk)/(dmax+1)

Punkte erreichen. Ein Bild was damit nicht über p_limit kommt, kann vorerst zurückgestellt werden und muss in dieser Situation keiner zusätzlichen Bewertung zugeführt werden.

(7) Ein Bild, das zurückgestellt wurde, kann allerdings bei einer Erhöhung von d_max um 1 wieder in die Vorjury zurückkehren. Dies deshalb, weil ein Bild, das bei d_max Bewertungen maximal noch

(5*(dmax-k+1)+Pk)/(dmax+1)

Punkte erreichen kann und damit unterhalb von p_limit bliebe und nicht bewertet wird, in der nächsten Runde bei dann insgesamt einer Bewertung mehr

(5*(dmax+1-k+1)+Pk)/(dmax+1+1)

Punkte erreichen kann. Die Ungleichung

(5*(dmax-k+1)+Pk)/(dmax+1) < (5*(dmax+1-k+1)+Pk)/(dmax+1+1)

ist äquivalent zu

Pk < 5*k (wolframalpha),

was immer der Fall sein muss (ein Bild kann nach k Bewertungen nie mehr als 5k Punkte haben). Damit muss Bildern die Chance auf eine d_max +1 te Bewertungmöglich gemacht werden.

Algorithmus

Damit ergibt sich folgender Algorithmus. Die größte Anzahl an Bewertungen für ein Bild sei aktuell d_max. Der Grenzwert während eines Durchgangs, um ins Finale zu kommen, ist p_limit, der Anfangswert dafür 1 (weniger Punkte gibt es auch im Schnitt nicht). Ein Bild mit aktuell P_k Punkten aus bisher k Bewertungen wird nur dann zur nächsten Bewertung vorgelegt, wenn

(5*(dmax+1-k)+Pk)/(dmax+1) ≥ plimit

wird. Muss d_max um 1 vergrößert werden, so wird p_limit neu berechnet und mit dem neuen Kriterium ein neues Bild ausgewählt.

p_limit kann ohne wesentlichen Einfluss jederzeit berechnet werden, es empfiehlt sich aber dies vor der endgültigen Teilung in den oberen Bereich und den Rest jedenfalls zu tun. Invariant ist

1 ≤ plimit ≤ 5

Für die Punkte je Bild P_k gilt

k ≤ Pk ≤ 5k

bzw. für neue Bilder (k = 0) als degenerierte obige Ungleichung

Pk = P0 = 0

Für neue Bilder gilt unabhängig von d_max

(5*(dmax+1-0)+P0)/(dmax+1) = (5*(dmax+1-0)+0)/(dmax+1) = 5 ≥ plimit

d.h. später eingestiegene neue Bilder bekommen immer eine erste Bewertung. Diese Bedingung gilt auch für den ersten Durchgang (alle Bilder neu).

Im zweiten Durchgang gilt d_max = 2, k = 1, 1 < P₁ < 5, es ergibt sich

(5*(2+1-1)+P1)/(2+1) = (10+P1)/3 = [3.67;5] ≥ plimit

Zu lesen ist das wie folgt: Ein Bild mit einer fehlenden Bewertung im zweiten Durchgang kann je nach den Punkten für die erste Bewertung zwischen 3.67 und 5 Punkten final erreichen. Je nach p_limit reicht das für die Vorlage zur nächsten Bewertung. Ist p_limit = 4, so werden Bilder mit P₁ = 1 nicht vorgelegt (max. 3.67 erreichbar), während Bilder mit P₁ ≥ 2 (ergibt mindestens 4) vorgelegt werden. Das Bild mit dem bisher einen Punkt kann aber im dritten Durchgang wieder vorgelegt werden, d_max = 3, k = 1, 1 < P₁ < 5, es ergibt sich

(5*(3+1-1)+P1)/(3+1) = (15+P1)/4 = [4;5] ≥ plimit

Eigenschaften

• Je weniger Punkte ein Bild hat, d.h. je schlechter es bisher bewertet wurde, desto eher wird es nicht mehr vorgelegt.
• Auch schlechte Bilder werden mit zunehmender Anzahl von Durchgängen ev. wieder vorgelegt, aber insgesamt weniger oft als gute Bilder. Dies kann dazu führen, dass in bestimmten Abschnitten der Vorjury ein Block schlechterer Bilder zur Bewertung vorgelegt wird.

Implementierung

Ich würde mir eine begleitende Statistik über die Bewertungen je Bild wünschen, braucht keinen Bildbezug. Ein Tupel pro Bild mit den Bewertungen in ihrer Reihenfolge reicht aus, etwa (1,2) für ein schlechtes und (4,5,4,3,5) für ein gutes Bild. Insbesondere brauchen wir ein Gefühl für die Einsparung an Bewertungen im realen Betrieb.

Kritik, Diskussion

Ich bitte Menschen mit mathematischem Verständnis meine Überlegungen nachzuprüfen, mein Vorschlag wäre hier zu kommentieren und ausnahmsweise nicht oben im Text. Ich habe jetzt keine Abschätzung, was das an Einsparungen bringt. @Ruben Demus: wäre das so umsetzbar? lg --Herzi Pinki (Diskussion)

Hab mal manuell die Tupel für die Gewinnerbilder rausgesucht.

(4,4,3,3,3,3,3)	3,29
(5,4,4,3,3,1)	3,33
(5,5,4,3,2,1)	3,33
(4,4,4,4,3,1)	3,33
(5,4,3,3,3,2)	3,33
(4,4,3,3,3,3)	3,33
(5,4,3,3,3,2)	3,33
(5,4,4,3,3,3,2)	3,43
(4,4,4,3,3,3)	3,50
(5,5,4,4,3,2,2)	3,57
(5,4,4,3,3,3)	3,67
(4,4,4,4,3,3)	3,67
(5,4,4,4,4,3,3)	3,86
(5,5,5,5,4,4,4)	4,57

Je nach Reihenfolge der Bewertungen und Schlüssel zur Teilung könnten (5,5,4,3,2,1) und (5,5,4,4,3,2,2) problematisch werden. --Ruben Demus (Diskussion) 13:24, 22. Jan. 2019 (CET)

Danke für die konkreten Zahlen, ich jag sie mal durch Excel Open Office Calc. Mich wundert der große Abstand in der durchschnittlichen Bewertung, hatte da eine andere Fantasie von eher dicht beinander liegenden Schnitten. Einigkeit bei der Bewertung (±1) ist eher die Ausnahme als die Regel. Sogar 5 & 1 kommen zweimal gemeinsam vor. lg --Herzi Pinki (Diskussion) 17:42, 22. Jan. 2019 (CET)

Mein angepasster Algorithmus oben, der ohne Ausscheiden nach einer fixen Anzahl Runden auskommt, sollte das aber schaffen. Ein Bild, das mit Bewertungen 1 und 2 beginnt, würde vermutlich nicht zur 3. Runde vorgelegt werden, auch nicht zur 4. Sondern bei 2 Bewertungen verharren. Wird nach 3 Bewertungen abgebrochen, ist das Bild zu recht draußen. Bei der 5. Runde (das Bild mit 3 Punkten aus 2 Bewertungen ist jetzt mögliche 3*5 Hoffnungspunkte im Rückstand, wird es wieder vorgelegt und ist mit 5 Punkten weiter im Rennen, mit 1 Punkt aber für weitere Runden draußen. Es werden nur Bilder ausgeschlossen, die es auch theoretisch nicht mehr schaffen können über p_limit zu kommen. Aber ich spiel noch mit den Zahlen, um das auch praktisch zu untermauern. lg --Herzi Pinki (Diskussion) 17:52, 22. Jan. 2019 (CET)

Wenn es darum geht, dass sich nicht jeder Vorjuror alle Bilder anschauen 'muss' (Öfter als 1x kann ein Bild ja pro Person ohnehin nicht bewertet werden.): Sollte die Logik für 'schlechte Bilder' nicht umgekehrt auch für 'gute Bilder' angewendet werden? --Ruben Demus (Diskussion) 19:43, 22. Jan. 2019 (CET)

Gute Idee, werde das nochmals für den oberen Bereich überlegen. Die 500 besten Bilder der Vorjury, nur zur Sicherheit, kommen ja ohne diese Wertungen, also unsortiert, zur Vorjury. lg --Herzi Pinki (Diskussion) 11:32, 23. Jan. 2019 (CET)

Ich denk 1-2 konkrete Beispiele sollten wir beim nächsten Termin am 14. Februar mal durchgehen. Die Bewertungen mit 5 und 1 zeigen deutlich, dass da etwas ganz und gar nicht passt... --Braveheart ^Diskussion 12:07, 23. Jan. 2019 (CET)

@Ruben Demus, Herzi Pinki: Bevor wir das diesjährige Vorjurytool aufmachen und Leute zum Bewerten anfangen: Wäre der obige Ansatz eurer Meinung nach umsetzbar? Speziell die Logik, Bilder mit drei schlechten Bewertungen beim 4. Bewerter nicht mehr vorzulegen und ev. in einer späteren Runde abzubilden. Das würde den guten Bildern mehr Differenzierung ermöglichen.

Eine Alternative wäre dazu, dass bis Ende September mal überhaupt festgelegt wird, welche Bilder eine Chance im Wettbewerb haben und welche nicht, d.h. eine Vorausscheidung basierend auf ja/nein. LG, --Braveheart ^Diskussion 13:15, 10. Jul. 2019 (CEST)

Also ich bin immer noch gegen das automatische Aussortieren, sondern stattdessen dafür, die Teilnehmer bereits in der Wettbewerbsbeschreibung auf die Not-for-prejury-Cat hinzuweisen und Vieluploader direkt aufzufordern, ihre Bilder vorzusortieren. Freiwilligkeit sollte Vorrang haben. Liebe Grüße, --Häferl (Diskussion) 16:46, 10. Jul. 2019 (CEST)

@Haeferl: Die Vieluploader sind in dieser Statisik einsehbar. Die "Not-for-Prejury-Kategorie" wird bereits in den meisten Upload-Kampagnen auf Commons abgefragt, das Verhalten der letzten Jahre war jedoch, dass man im Zweifelsfall ein Bild nominiert statt auszusortieren.

Ein Anschreiben der Vieluploader könnte ich übernehmen, dann stellt sich jedoch die Frage, ab wann die Vorjury in Erscheinung treten soll. Laufend Personen anzuschreiben wär für mich allein zuviel Aufwand, einmal gegen Ende würde bedeuten, dass die Vorjury trotzdem bis dorthin alles bewertet, was ev. doch nicht für den Wettbewerb gedacht ist. LG, --Braveheart ^Diskussion 12:33, 13. Jul. 2019 (CEST)

@Haeferl, Braveheart: ich fürchte, ihr habt meinen (modifizierten) Vorschlag nicht verstanden. Trotzdem gehe ich mit gutem freiwilligen Beispiel voran und werde heuer keine Bilder hochladen. lg --Herzi Pinki (Diskussion) 18:27, 14. Jul. 2019 (CEST)

@Herzi Pinki: Hmmm, inwiefern wurde dein (modifizierter) Vorschlag in meinem Beitrag vom 10. Juli missverstanden? Haeferl moechte ja einen komplett anderen Ansatz wählen. Dass du gar keine Bilder hochladen magst, find ich schade, fand die immer interessant und hilfreich! LG, --Braveheart ^Diskussion 13:21, 15. Jul. 2019 (CEST)

Bilder mit drei schlechten Bewertungen beim 4. Bewerter nicht mehr vorzulegen klingt danach. lg --Herzi Pinki (Diskussion) 15:03, 15. Jul. 2019 (CEST)

Hallo Herzi Pinki! Also ich finde eine Trotzreaktion wie "werde heuer keine Bilder hochladen" nicht wirklich ein gutes Beispiel, das solltest Du Dir ehrlich noch einmal überlegen. Ein gutes Beispiel wäre es, von Deinen Bildern alle, die Du nicht selbst für mögliche Gewinnerbilder hältst, in die Not-for-prejury-Kategorie einzusortieren. ;-) Zu Deinem Vorschlag: Du versuchst das mittels Durchschnitt zu bestimmen, weil es sich so eher rechnen/programmieren lässt, was aber ja auch aus der Idee entstanden ist, ein Bild nach drei schlechten Bewertungen nicht mehr vorzulegen. Gut finde ich, dass es nach weiteren Durchgängen neuerlich nachgerechnet wird und das Bild gegebenenfalls wieder in die Bewertung kommt. Jedenfalls sollte die Zahl, unter der es ausscheidet, wirklich tief genug sein, damit sicher kein Bild rausfliegt, das evtl. doch noch Chancen hätte (also entweder herumrechnen oder einfach auf Nummer Sicher gehen und sie tief genug ansetzen). Was ich allerdings befürchte (vielleicht zu unrecht), ist, dass das Vorjurytool durch die Rechnerei sehr langsam wird.

Rubens Idee, ob das System "nicht umgekehrt auch für 'gute Bilder' angewendet werden" könnte, kann ich gar nichts abgewinnen. Gerade Bilder, die in die Auswahl kommen, sollten möglichst oft, am besten von jedem Juror bewertet werden. Wenn die schlechten und die guten Bilder nicht mehr vorgelegt werden, bewerten wir dann hauptsächlich das Mittelfeld - abgesehen davon, dass die Vorjury ohne gute Bilder eine ziemlich langweilige Angelegenheit werden würde, finde ich es nicht sinnvoll, wenn Bilder im Mittelfeld 10 oder 12 Bewertungen erhalten, jene, die in die Auswahl kommen, aber nur 3 oder 4. Außerdem würde es den Juroren die Arbeit erschweren, wenn man die guten Bilder nicht alle sieht: Man hat dann den Eindruck, es würde zu wenig richtig gute Bilder geben, und bewertet dann welche, die nicht so gut sind, besser, damit man eine gewisse Anzahl an Bildern mit 4 oder 5 Punkten bewertet (ich weiß, dass ich nicht die einzige bin, die am Ende nochmals entsprechend umsortiert) - und dann fliegen am Ende womöglich gute Bilder raus, weil man sie nicht zu Gesicht bekommt und daher die zweitbesten überbewertet werden. Am Schluss sitzt man dann als Vorjuror staunend vor der Auswahl, weil da lauter Bilder sind, die man nie gesehen hat. Also die umgekehrte Variante halte ich ehrlichgesagt für Topfen (sorry, Ruben ;-)). Liebe Grüße, --Häferl (Diskussion) 02:36, 16. Jul. 2019 (CEST)

Hallo @Haeferl: Ich sortiere alle meine Bilder in die not-for-prejury Kategorie ein, so ich sie denn am Wettbewerb nicht teilnehmen lassen will. Sonst hat die Freiwilligkeit keinen Vorrang. Du jammerst immer über die Menge der Bilder in der Vorjury, ich habe einen radikalen Vorschlag gemacht, die Anzahl der Bilder pro Uploader zu reduzieren, aber mehr Klasse statt Masse ist offensichtlich nicht gewünscht. Jetzt trage ich halt bei, was ich zur Reduktion der Arbeit beitragen kann. Es war auch ein Versuch, zur Reduktion meiner Arbeit beizutragen, was ich jetzt halt anders löse. lg --Herzi Pinki (Diskussion) 08:22, 16. Jul. 2019 (CEST)

Ein Versuch der Erklärung und Zusammenfassung. Wenn ich das Ziel richtig verstehe sollen bevorzugt Bilder mit durchschnittlicher bis sehr guter Bewertung gezeigt werden und Bilder mit schlechter Bewertung nachrangig der Vorjury vorgelegt werden. Es geht aber ausschließlich um die Reihenfolge in der die Bilder vorgelegt werden. Kein Bild wird ausgeschlossen. Es kann jedes Bild pro Juror weiterhin genau 1x bewertet werden. Durch eine Verschiebung wird sich das subjektive Empfinden über die Qualität der Einreichungen immer ändern. Eher 'gute' -> gefühlt viele 'gute' Einsendungen -> strengere Bewertung(?). Eher 'Durchschnitt' -> gefühlt viele 'durchschnittliche' Einsendungen -> eher sanftere Bewertung(?)...

Folgendes sollte sich realistisch umsetzen lassen, wenn ich nicht die objektive Ersparnis sondern das subjektive Gefühl mit einbeziehe.

• Die Bilder erhalten nach Durchschnitt der bisherigen Bewertungen eine Reihung nach Priorität.
• Wenn der Durchschnitt unter 3 ist, so wird das Bild mit geringerer Priorität gewertet.
• Neue Bilder fangen mit der höchsten Priorität an.
• Je nach Bewertung ändert sich die Priorität
  • avg(0) -> 1 (sofort bewerten)
  • avg(~1) -> 3 (zwei Runden aussetzen)
  • avg(~2) -> 2 (ein Runde aussetzen)
  • avg(~3) -> 1 (in der nächsten Runde wieder vorlegen)
  • avg(~4) -> 1 (in der nächsten Runde wieder vorlegen)
  • avg(~5) -> 1 (in der nächsten Runde wieder vorlegen)

Das würde für einzelne Beispiele bedeuten:

• immer 1 Stern: Runden 1. 4. 7. 10. ...
• immer 2 Sterne: Runden 1. 3. 5. 7. ...
• immer 3 Sterne: Runden 1. 2. 3. 4. ...
• immer 4 Sterne: Runden 1. 2. 3. 4. ...
• immer 5 Sterne: Runden 1. 2. 3. 4. ...
• 5,1,5, Sterne: Runden 1. 2. 3. 4. ...
• 1,5,5, Sterne: Runden 1. 4. 3. 4. 5. 6. ...

In Runden ausgedrückt:

• 1. Runde: wie bisher alle Bilder

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

• 2. Runde: nur die Besseren

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

• 3. Runde: auch die nicht so guten noch mal

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

• 4. Runde: die ganz Schlechten bekommen eine 2. Möglichkeit

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

• 5. Runde: nur die nicht so guten kommen noch mal

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

• 6. Runde: wieder nur die Besseren

Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

7. Runde: Hier sind wir wieder, wo wir am Anfang waren. Die Darstellung von Grafiken ist aktuell auf Grund eines Sicherheitsproblems deaktiviert.

Die folgenden bisherigen Bedingungen können weiter bestehen bleiben:

• Ein Bild kann pro Juror nur 1 x bewertet werden
• Eigene Bilder können nicht bewertet werden

Die folgenden Funktionen werden (etwas) langsamer

• Abgeben einer Stimme
• Anzeigen des nächsten Bildes
• Ändern der Stimme

--Ruben Demus (Diskussion) 16:14, 16. Jul. 2019 (CEST)

Das wäre aus meiner Sicht eine deutlich abwechslungsreichere Gestaltung der Bewertung als im Vorjahr. Falls jemand alle Bilder bewerten möchte, kann das noch immer stattfinden, aber wenigstens bekommt man die (von der restlichen Vorjury) als interessanter bewerteten Bilder häufiger serviert. Hast du eine Hausnummer, wieviel langsamer die Abgabe der Stimmde und die nachfolgende Anzeige des nächsten Bildes wird? LG, --Braveheart ^Diskussion 09:44, 17. Jul. 2019 (CEST)

Punkto Geschwindigkeit sollte es sich bisher im Rahmen halten. Zumindest habe ich seitens der momentan aktiven Juroren seit der Umstellung keine Beschwerden gehört. Bei vielen Bewertungen von vielen Juroren in Kombination mit vielen Bildern sollten wir aber ein Auge darauf haben.--Ruben Demus (Diskussion) 10:40, 17. Jul. 2019 (CEST)

D.h. das ist bereits umgestellt? Falls ja, würd ich auch anfangen das aktiv zu bewerben. LG, --Braveheart ^Diskussion 10:29, 19. Jul. 2019 (CEST)

Ja ist es. Nachdem wir ja dieses Jahr bereits etwas früher fertig werden sollen (gibt es schon einen konkreten Termin bis wann die Vorjury fertig sein muss?), hab ich bereits umgestellt. --Ruben Demus (Diskussion) 12:11, 19. Jul. 2019 (CEST)

Bilder mit Bewertung 2 sollten nicht herausgenommen werden, nur Bilder mit 1. Da es keinen Sinn hat, schlechte Bilder in mehr und weniger schlecht aufzuteilen, sondern sinnvoller ist, die besseren und guten Bilder auf 2 bis 5 zu streuen, sollten schlechte Bilder immer nur mit 1 bewertet werden. Das ermöglicht eine bessere Differenzierung unter den guten Bildern. Alternativ könnte man natürlich auch mit mehr möglichen Punkten differenziern (die internationale Jury hat da mindestens 20), aber es hat einfach keinen Sinn, sich Gedanken zu machen, ob ein Bild nun mehr oder weniger schlecht ist. "seitens der momentan aktiven Juroren": Habe bisher noch keine Möglichkeit zum Anmelden gefunden, hier steht zwar Bitte tragt euch in dieser Liste ein, wenn ihr an der Auswahl der Fotos für WikiDaheim und Tag des Denkmals mitmachen wollt. Das Tool steht bereits zur Verfügung:, aber nach dem Doppelpunkt kommt nichts. Liebe Grüße, --Häferl (Diskussion) 14:15, 19. Jul. 2019 (CEST)

Es werden keine Fotos herausgenommen. Wer alle Fotos bewerten will bekommt sie auch weiterhin vorgelegt. Es geht aus Sicht des Vorjurors ausschließlich um die Reihenfolge also die statistische Wahrscheinlichkeit mit welcher ein Foto wann zur Bewertung vorgelegt wird. Bei Fotos mit rund einem Stern ist dies 1/3 und bei Fotos mit rund zwei Sternen 1/2 in Relation zu allen Anderen. Ob ein Bild nun 4,9 oder 4,8 Sterne hat ist eigentlich absolut irrelevant, da es in beiden Fällen ja der Jury vorgelegt wird. Da du aber weiter oben argumentiert hast, dass die besonders Guten zwecks Relation zur fairer Bewertung des Mittelfelds auch weiterhin angezeigt werden sollen, werden auch diese mit hoher Priorität angezeigt. Wir haben auch bisher niemanden eingeladen oder mitgeteilt, dass das Tool bereits mit den aktuellen Fotos bespielt wird. Da aber Link und Zugangsdaten mit jenen des Vorjahres identisch sind, haben sich einige einfach bereits an die Arbeit gemacht. Für alle jene, die ohnehin vor haben alle Fotos möglichst zeitnah zu bewerten, ist das hier ja ohnehin ein relativ irrelevante Diskussion. --Ruben Demus (Diskussion) 15:01, 19. Jul. 2019 (CEST)

Wikidata Bilderwünsche

Wikidata gibt Wünsche an, die bereits zur Genüge erfüllt sind. Bsp.: Puxerloch, Schloss Weyer, Wildemannloch, Repolusthöhle. LG --Christian Pirkl (Diskussion) 23:15, 15. Jul. 2019 (CEST)

• Puxerloch (Q2119410) (die Burg hat ein Bild in WD), Puxerloch (Q21874622) (die Höhle hat kein Bild in WD)
• Wildemannloch (Q21879203) hat kein Bild in WD
• Repolusthöhle (Q2145097) hat kein Bild in WD

lg --Herzi Pinki (Diskussion) 23:51, 15. Jul. 2019 (CEST)

Was ich meinte ist: wieso Photographen wohinschicken um etwas zu photographieren was schon photographiert ist? Wenn ich wüßte wie, würde ich die Bilder in wikidata ergänzen. LG--Christian Pirkl (Diskussion) 16:40, 16. Jul. 2019 (CEST)

Meines Wissens nach bedeutet auch in der WP ein Bilderwunsch nicht direkt 'Bitte machen ein Foto' sondern nur 'an dieser Stelle wäre eine Abb. super'. Ist somit eher eine allgemeine Frage zu Bilderwünschen. Prinzipiell steht und fällt die Datenqualität des gesamten Projekts mit der Qualität der Quellen. Bei den Listen gab es schon ein paar Jahre diese zu verbessern. Wikidata ist neu dazu gekommen, um hier durch mehr Aufmerksamkeit ähnliches zu bewirken. Zumindest hab ich das so verstanden. --Ruben Demus (Diskussion) 17:06, 16. Jul. 2019 (CEST)

Gut, ich hatte das anders aufgefasst. Bleibt die Herausforderung herauszufinden was dringend photographiert gehört und wovon es schon genug Bilder gibt. (und wikidata hat meine Aufmerksamkeit, bloß weiß ich nicht wie man dort Bilder hinzufügt) LG--Christian Pirkl (Diskussion) 21:06, 16. Jul. 2019 (CEST)

Ich hoffe, dir kann geholfen werden. Bild in WD einfügen ist einfach, Aussage hinzufügen: Bild (P18) (einfach Bild tippen) und den Dateinamen ohne Namespace-Präfix eintragen. --Herzi Pinki (Diskussion) 23:41, 16. Jul. 2019 (CEST)

Generell ist das natürlich ein Problem. Soweit ich das überblicke, kümmert sich hauptsächlich User:Braveheart um das Einfügen von Bildern auf WD. Bei den Denkmallisten gibt es diverse unterstützende Mechanismen, die es bei WD nicht gibt. D.h. viel manuelle Arbeit. Noch immer ist mein Unbehagen nicht ausgeräumt, dass das Verwenden von Bildern an diversen Stellen durch falsche Anreize zustandekommt. lg --Herzi Pinki (Diskussion) 23:41, 16. Jul. 2019 (CEST)

Welche falschen Anreize meinst du damit? @Christian Pirkl: Wir haben leider auf Wikidata keinen sauberen Datenbestand, d.h. es kann sehr gut vorkommen, dass zwar ein Objekt auf Wikidata kein Bild hat, aber der Artikel in der deutschsprachigen Wikipedia. Dies abzugleichen ist eines der Experimente in diesem Jahr. Das Hinzufügen von bereits vorhanden Bildern wäre auch hilfreich, sollt eigentlich auch recht einfach gehen, oder gibts damit Probleme? LG, --Braveheart ^Diskussion 09:40, 17. Jul. 2019 (CEST)

Ich habe mir 3 Fälle angesehen, ein Problem ist, dass die Items auf WD doppelt / überlappend waren, und ein Mischen notwendig. Das Mischen ist nicht trivial, widersprüchliche Properties müssen gegeneinander geprüft werden. Wie oft, gibt es ein ordentliches Item mit Bild und ein sv/ceb-Item parallel dazu. Warum scheinen die WD-items mit nur sv/ceb Sitelinks bei den Bilderwünschen überhaupt auf? Sie scheinen außerdem mit den unscharfen / falschen Koordinaten von Geonames auf. lg --Herzi Pinki (Diskussion) 10:19, 17. Jul. 2019 (CEST)

Ich bin mal bis jetzt A-G für Wikidata-Items in Österreich durchgegangen, die Menge an Duplikaten war bisher erträglich. Ärgerlicher sind da Fälle, wo Duplikate in der schwedischen Wikipedia existieren... :-/ Werd versuchen den Rest in den nächsten Wochen durchzugehen. --Braveheart ^Diskussion 10:16, 25. Jul. 2019 (CEST)

Ich habe in den vergangenen Tagen 76 Duplikate auf WD gemischt, und 177 Bilder eingefügt. lg --Herzi Pinki (Diskussion) 16:48, 25. Jul. 2019 (CEST)

Danke erstmal für die Erklärung. Habe jetzt einfach auf der jeweiligen WD Diskussionsseite auf die Verfügbarkeit + link hingewiesen. Zum zweiten: Worin besteht Dein Unbehagen? LG--Christian Pirkl (Diskussion) 00:09, 17. Jul. 2019 (CEST)

Warum fügst du ein von dir für gut befundenes Bild nicht gleich ein? Ich fürchte, auf den Talkpages liest niemand mit. Was Schloss Gutenberg angeht, so habe ich jetzt Schloss Gutenberg (Q2241348) und Schloss Gutenberg (Q21871490) gemischt (über: Mehr -> Zusammenlegen mit ...), damit ist der BW dann durch das andere Objekt erfüllt. lg --Herzi Pinki (Diskussion) 01:23, 17. Jul. 2019 (CEST)

Weil ich da noch nicht gewußt habe wie's geht, habe die Bilder nur gleich in sv/ceb eingefügt (aber jetzt kann ich es dank Dir). Dein Unbehagen? LG--Christian Pirkl (Diskussion) 10:56, 17. Jul. 2019 (CEST)

Wikidata Bilderwünsche

Ich habe jetzt einige der bilderlosen WD-Einträge angeguckt. Ein erklecklicher Teil davon sind Duplikate, die für ceb/sv doppelt angelegt worden sind und oftmals für das andere Item bereits mit Bildern versehen sind. Die wünschenswerte Vorgehensweise bei einem solchen Bilderwunsch ist es daher, nicht hinaus in die Natur zu gehen, sondern zuerst die beiden WD-items zu mischen. Fühlt sich jemand in der Lage eine Anleitung zu schreiben, wie man das kompletten Neulingen und Nur-Fotografen vermitteln kann? Und wie kann man diese Info prominent auf wikidaheim.at platzieren? lg --Herzi Pinki (Diskussion) 07:27, 19. Jul. 2019 (CEST)

• Fehler in der Quelle GeoNames ev. gleich mitausbessern. --Herzi Pinki (Diskussion) 07:42, 19. Jul. 2019 (CEST)

Die Zielgruppe für so eine Anleitung dürfte größer sein. Ich bin schon deutlich mehr als 10 Jahre auf Wikipedia aktiv, hab aber von wikidata keine Ahnung. Das ist für mich so wie wikinews oder wikivoyage einfach ein ganz anderes Projekt, mit dem ich nichts zu tun habe. Das sprengt jetzt den Rahmen von wikidaheim, aber: falls es aus Sicht von wikipedia sinnvoll ist, wikidata zu bearbeiten, dann müsste man vermutlich zunächst versuchen, den aktiven wikipedia-Autoren beizubringen, warum und wie das geschehen soll.--Niki.L (Diskussion) 07:51, 19. Jul. 2019 (CEST)

Ich kann mich mal an so einer Anleitung versuchen. Ich würds auf WikiDaheim ins Pin-Popup verlinken mit der Aufschrift "Duplikat?".

Der Grund, wieso heuer Wikidata dabei ist, ist eigentlich ganz einfach - in der deutschsprachigen Wikipedia haben wir Relevanzkriterien, die uns vorschreiben, was relevant/als Artikel oder Liste vorhanden ist oder nicht. Die Realität in Österreich sieht oftmals anders aus und Datensätze mit Koordinaten z.B. zu Friedhöfen zu pflegen ist ein deutlich geringerer Wartungsaufwand, als eine Wikitable-Liste auf Wikipedia pflegen zu müssen. Was nicht bedeutet, dass wir dann auch eine Liste auf Wikipedia machen, aber die Schwelle um interessante Objekte auf WikiDaheim anzuzeigen, sinkt erheblich. Wenn einige Wiener Kollegen nicht sehr viel Zeit hineingesteckt hätten, um alle Brücken und Gemeindebauten in Wien aufzulisten, sähe es in Wien heuer etwas langweilig aus ;-) --Braveheart ^Diskussion 10:49, 19. Jul. 2019 (CEST)

Könnte man nicht WD-items, die ausschließlich Sitelinks auf ceb/sv haben, für die Bilderwünsche generell ignorieren? Damit könnte man die false negative Bilderwünsche stark reduzieren. Dann bleiben noch die Fälle der WD-items, die aus anderen Quellen hoffentlich besser modelliert sind. Trotzdem ist auch bei diesen natürlich erst ein Bild zu suchen, und erst dann ins Feld hinauszustechen. lg --Herzi Pinki (Diskussion) 11:01, 19. Jul. 2019 (CEST)

@Ruben Demus: Wäre das aus deiner Sicht möglich? Die SPARQL-Abfrage läuft ja mit den sitelink-Einschränkungen in ein Timeout, d.h. diese Filterung müsste man danach noch zusätzlich machen. LG, --Braveheart ^Diskussion 11:13, 20. Jul. 2019 (CEST)

Bilde mir ein wir hatten das mal diskutiert und uns dann dagegen entschieden. (Zumindest hab ich mir das so notiert.) Aber kein Problem. Werden jetzt auch ausgeschlossen. --Ruben Demus (Diskussion) 14:42, 20. Jul. 2019 (CEST)

Danke! Ja, wir hatten das anders diskutiert, aber die Verwirrung ist dann doch größer als der erhoffte Nutzen... :-/ --Braveheart ^Diskussion 10:17, 25. Jul. 2019 (CEST)

Bilderwünsche von Wikidata importieren

Hier ist ja schon einiges über doppelte und bereits erfüllte Bilderwünsche geschrieben worden, aber wie sieht es aus wenn man einen Bilderwunsch von Wikidata für WikiDaheim importieren will. Passiert das automatisch wenn man ein Datenobjekt mit geographischen Koordinaten anlegt? Ich hätte da nämlich einige Bilderwünsche für die Steiermark. Lg --Liuthalas (Diskussion) 15:38, 19. Jul. 2019 (CEST)

Alles, was unserer Abfrage entspricht (derzeitige Version siehe unten - allerdings werden zusätzlich alle Elemente ohne wdt:P625 und mit wdt:P625 ausschließlich cebwiki - da extrem fehlerbehaftet - ausgefiltert), wird regelmäßig aktualisiert und taucht entsprechend unter Wikidaheim auf.

SELECT DISTINCT ?_s ?_sLabel WHERE {
 SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
 ?_s wdt:P17 wd:Q40.
 ?_s wdt:P131*/wdt:P279* wd:Q40.
 ?_s wdt:P31 [].
 ?_s wdt:P625 []
 MINUS
 {
   ?_s wdt:P18 []
 }
 MINUS
 {
   ?_s wdt:P373 []
 }
}

--Ruben Demus (Diskussion) 16:03, 19. Jul. 2019 (CEST)

Danke für die Antwort. Also wenn ich das richtig verstehe taucht der Bilderwunsch früher oder später automatisch bei WikiDaheim auf, solange die Koordinaten in Österreich liegen bzw. des Objekt einer österreichischen Gemeinde zugeordnet ist. --Liuthalas (Diskussion) 16:18, 19. Jul. 2019 (CEST)

Korrekt :-) Sollte normalerweise am nächsten Tag sichtbar sein. --Braveheart ^Diskussion 11:07, 20. Jul. 2019 (CEST)

@Liuthalas: Hat das dann funktioniert? --Braveheart ^Diskussion 09:38, 31. Jul. 2019 (CEST)

Anscheinend nicht. Ich habe versuchsweise Wikidataeinträge zu den Ortsteilen von Bärnbach und dem Hahnenschloss mit Koordinaten etc. erstellt, aber ich kann keinen Bilderwunsch bei Wikidaheim sehen. Habe ich da irgendwo etwas vergessen? Lg --Liuthalas (Diskussion) 10:48, 31. Jul. 2019 (CEST)

Wie ich oben schon schrieb: '[... Es] werden zusätzlich alle Elemente ohne wdt:P625 [...] - da extrem fehlerbehaftet - ausgefiltert '. Im Vergleich zu diesen Einträgen ist cebwiki noch eine erfreuliche Bereicherung des Datenschatzes... --Ruben Demus (Diskussion) 11:35, 31. Jul. 2019 (CEST)

Die Koordinaten müssen auf jeden Fall auch angegeben werden, sonst ist das leider auf der Karte net anzeigbar. Es wäre allerdings auch eine Idee, alle Einträge ohne Koordinate in dieser Gemeinde in der Liste darzustellen. --Braveheart ^Diskussion 18:01, 31. Jul. 2019 (CEST)

Einzelhöfe als Bilderwünsche relevant?

Anschlussfrage an oben: sind von der Statistik Austria erfasste Einzelhöfe, -häuser etc. interessant bzw. relevant um als Bilderwünsche für WikiDaheim aufzuscheinen? Lg --Liuthalas (Diskussion) 16:36, 19. Jul. 2019 (CEST)

Was meinst mit der Relevanz und der Statistik. Es sind auch andere Einzelhöfe als Foto relevant. --K@rl 20:43, 19. Jul. 2019 (CEST)

Ok, war erwas unverständlich formuliert. Ich meine die Einzellagen bzw. Einzelhöfe aber auch Gasthöfe welche die Statistik Austria unter anderem in ihren Ortsverzeichnissen angibt. Also sonstige Ortslagen wie zum Beispiel in Edelschrott der Einzelhof Adambauer oder der Aiblwirt. Man findet sie ja auch im GIS Stmk. Es stehlt sich mir halt die Frage ob wir die auch gerne bebildert hätten bzw. ob sie relavant genug für einen eigenen Wikidataeintrag und damit auch für einen Bilderwunsch sind. Lg --Liuthalas (Diskussion) 21:51, 19. Jul. 2019 (CEST)

erst wenn es ein Foto gibt - gabnz unabhängig von der GIS - ist es auch relevant für einen WD eintrag. --K@rl 22:58, 19. Jul. 2019 (CEST)

Danke für die Antwort, ich werde mich daran halten. Lg --Liuthalas (Diskussion) 07:13, 20. Jul. 2019 (CEST)

Das schöne an Wikidata ist ja, dass alle Daten prinzipiell relevant sind - d.h. jedes Gasthaus in Österreich wäre einen Eintrag wert. Allerdings wärs natürlich besser, wenn a) der Eintrag belegt ist und b) mehr Informationen als Name und Koordinaten vorhanden sind. --Braveheart ^Diskussion 09:30, 31. Jul. 2019 (CEST)

nicht am Wettbewerb teilnehmen - Naturdenkmallisten

Da hier so viel über frühzeitiges Aussortieren diskutiert wurde: wenn ich Bilder ganz normal über die Naturdenkmallisten hochlade, bekomme ich nirgendwo eine Hinweis, dass ich damit automatisch an einem Wettbewerb teilnehme, geschweige denn, dass ich die Bilder aus dem Wettberwerb rausnehmen könnte? --Niki.L (Diskussion) 12:47, 21. Aug. 2019 (CEST)

Was wir im Wettbewerb für Aufwand treiben, um Bilder nicht am Wettbewerb teilnehmen zu lassen. Ich habe mich mal der Sache angenommen. lg --Herzi Pinki (Diskussion) 10:20, 27. Aug. 2019 (CEST)

Wikidata-Einträge überprüfen und korrigieren

Für alle, die Lust und Laune haben, für die Datenkonsistenz in Wikidata zu sorgen, erlaube ich mir folgende Erfahrungen zu teilen:

• Alle Koordinaten aus GeoNames sind als falsch / ungenau zu betrachten. Die Originalkoordinaten sind nur auf Minuten genau, ihr erkennt sie also an den 0 Sekunden in der Breite und Länge. Bitte Koordinaten anhand der jeweiligen Gis-Dienste neu eruieren und entsprechend ändern. Als Fundstelle trage ich nachgewiesen in (P248) und den jeweiligen GIS-Dienst als Wert ein. Für Österreich sind die 9 Landesgisdienste und amap.at bereits als Objekte definiert, mit den üblichen Aliasen: Gis Burgenland, Kagis, NÖ Atlas, Doris, Sagis, Gis Steiermark, Tiris, Vogis, Gis Wien und amap.at.
• die Höhen stammen aus irgendeinem Oberflächenmodell der Erde und entsprechen den Höhenangabe an der Stelle der falschen Koordinaten. Also mit den Koordinaten auch die Höhen korrigieren.
• die Bezeichnungen sind oft falsch, falsche ss/ß-Schreibung, falsche Trennung, falsche Interpretation von Abkürzungen: K. = Klein / Kleines / Kleine / Kleiner, falscher Genus: Grosser xxxSpitze. Bitte die Bezeichnungen entsprechend den Schreibweisen in den Gis-Diensten anpassen, sinnvolle Alternativschreibweisen behalten.
• die Objekttypen sind nicht korrekt, etwa Lagune (Q187223) statt See (Q23397)
• die Beschreibung muss zusammen mit der Bezeichnung eindeutig sein. Klammerbezeichnungen entsprechend unseren Klammerlemmatas halte ich für falsch. In Wikidata ist die Q-Number (Item-Number) der Schlüssel zum Objekt, und die Bezeichnung nur Text. Ich arbeite nach folgendem Muster:
  • Bezeichnung = Hornbach
  • Beschreibung = Bach in Oberösterreich
    bzw.
  • Hornbach (Q685926)
• gelegentlich lohnt es sich, die fehlerhafte Datenquelle in GeoNames oder Openstreetmap zu korrigieren. Dazu dort Account anlegen. Was mir noch nicht gelungen ist, ist das Löschen von Einträgen auf GeoNames.
• Grenzüberschreitende Objekte sind oftmals falsch eingetragen, so sind mir Berge an der österreichisch-slowenischen Grenze untergekommen, mit zwei WD-Einträgen, einmal Berg in Slowenien mit dem slowenischen Namen und Berg in Österreich mit dem deutschen Namen. Diese Einträge gehören zusammengemischt und bei Staat (P17) und bei liegt in der Verwaltungseinheit (P131) zwei Werte eingetragen.
• Beim Mischen von Objekten (Zusammenlegen mit) sind Höhenangaben und Koordinaten auf den einen richtigen Wert zu reduzieren, Falschschreibungen aus den Beschreibungen zu entfernen. Um die Linkverbiegungen müsst ihr euch nicht kümmern, geht automatisch.
• Vor dem Mischen von identischen Objekten sind ev. Artikel in der WP:sv bzw. WP:ceb aus dem Wikidata-Sitelink zu entfernen (sonst schlägt das Mischen fehl). Sinnvoll ist oft der Ersatz der Duplikate durch Weiterleitungen. #redirect funktioniert auch in WP:sv bzw. WP:ceb, mit der Vorlage Delete kann in beiden Sprachversionen eine Schnelllöschung beantragt werden.
• Für Bilder muss die Property Bild (P18) versorgt werden, bei der Suche nach möglichen Bildern auf Commons bitte kreativ sein. Commonscat über den entsprechenden Site-Link. Beim Zusammenmischen in der Regel nur ein Bild belassen, ein ev. zweites entfernen.
• Beispielhafte Suche nach Bergen ohne Bild: https://query.wikidata.org/#SELECT%20DISTINCT%20%3F_s%20%3F_sLabel%20%3F_sDescription%20WHERE%20%7B%0A%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22%5BAUTO_LANGUAGE%5D%2Cen%22.%20%7D%0A%20%3F_s%20wdt%3AP17%20wd%3AQ40.%0A%20%3F_s%20wdt%3AP131%2a%2Fwdt%3AP279%2a%20wd%3AQ40.%0A%20%3F_s%20wdt%3AP31%20wd%3AQ8502.%0A%20%3F_s%20wdt%3AP625%20%5B%5D%0A%20%0A%20MINUS%0A%20%7B%0A%20%20%20%3F_s%20wdt%3AP18%20%5B%5D%0A%20%7D%0A%20MINUS%0A%20%7B%0A%20%20%20%3F_s%20wdt%3AP373%20%5B%5D%0A%20%7D%0A%7D%0AORDER%20BY%20ASC%28%3F_sLabel%29

SELECT DISTINCT ?_s ?_sLabel ?_sDescription WHERE {
SERVICE wikibase:label { bd:serviceParam wikibase:language "[AUTO_LANGUAGE],en". }
?_s wdt:P17 wd:Q40.
?_s wdt:P131*/wdt:P279* wd:Q40.
?_s wdt:P31 wd:Q8502.
?_s wdt:P625 []

MINUS
{
  ?_s wdt:P18 []
}
MINUS
{
  ?_s wdt:P373 []
}
}
ORDER BY ASC(?_sLabel)

@Braveheart:, vielleicht als Teil deiner geplanten Anleitung. lg --Herzi Pinki (Diskussion) 18:32, 1. Aug. 2019 (CEST)

Danke für die Erläuterung, Lagune statt See ist mir bisher einmal untergekommen, aber macht beim genaueren Hinsehen natürlich Sinn, die Instanz auf See zu ändern. Wir können die Klammern-Label auch ändern und dafür eine Bezeichnung einführen, das dazugehörige CSV-File hab ich noch herumliegen.

Die Höhenangaben von Geonames sind zu 90% falsch und beim Zusammenlegen sowieso zu löschen, weil zumindest beim deutschsprachigen Artikel mal jemand drübergeschaut hat.

Ansonsten sind das genau jene Arbeitsschritte, die ich bisher auch gemacht habe, bis auf das Konto auf Geonames.

Die generelle Frage, die sich mir stellt: Könnte man das Löschen dieser ganzen Artikel beantragen, weil sie nachweislich falsche Daten beinhalten? Hat das schon jemand probiert? @DerHexer:, falls das international schonmal angesprochen wurde. Dieses Vollpflastern mit Falschinformationen auf Wikidata erzeugt einen irren Arbeitsaufwand, um das wieder aussagefähig zu bekommen. --Braveheart ^Diskussion 20:08, 1. Aug. 2019 (CEST)

P.S.: Was mir noch aufgefallen ist: die sv/ceb-Wikidata-Einträge sind alle in einem bestimmten Nummernkreis angelegt, falls man nur diese Einträge herausfiltern möchte. --Braveheart ^Diskussion 20:12, 1. Aug. 2019 (CEST)

Jetzt konnte ich ein Feature auf Geonames löschen. Vielleicht habe ich mich durch einige Edits hochgearbeitet und habe jetzt Löschrechte? @Braveheart:, gibt es was Neues von der Anleitung? lg --Herzi Pinki (Diskussion) 23:28, 31. Aug. 2019 (CEST)

Noch nicht, bin leider noch nicht dazu gekommen, weitere Duplikate zu sichten und zu löschen. In welchen Fällen empfiehlst du eigentlich das Löschen auf Geonames? --Braveheart ^Diskussion 09:10, 1. Sep. 2019 (CEST)

wird halt schon spät für WLM / WD.

Ich lösche auf Geonames Namen, die Schreibfehler sind (wie Gorssspeikkofel) komplett und Duplikate, sobald ich den anderen Namen als Alternativname eingetragen habe. Ich habe allerdings erst einmal gelöscht. lg --Herzi Pinki (Diskussion) 19:49, 8. Sep. 2019 (CEST)

statistik neue user

@Funke: u.a.: https://quarry.wmflabs.org/query/39729 --Herzi Pinki (Diskussion) 12:52, 25. Okt. 2019 (CEST)

87 Bilder oder ein gutes Prozent stammen von 35 neuen UserInnen. lg --Herzi Pinki (Diskussion) 12:53, 25. Okt. 2019 (CEST)

Danke. --Funke (Diskussion) 12:53, 25. Okt. 2019 (CEST)

Leopoldstadt - Carl Michael Ziehrer-Denkmal

Das Denkmal ist richtig beschrieben, aber in der Landkarte falsch positioniert. Es soll in der Prater Hauptallee sein, nicht beim Odeonpark. LG Theodora (nicht signierter Beitrag von Promenade~dewiki (Diskussion | Beiträge) 17:30, 27. Okt. 2019 (CET))

@Promenade~dewiki: - habe die Koordinaten in Liste der Kunstwerke im öffentlichen Raum in Wien/Leopoldstadt angepasst. Hast du das gemeint? lg --Herzi Pinki (Diskussion) 21:19, 27. Okt. 2019 (CET)

Vorbereitung für nächste Runde (nächstes Jahr)

Ich habe ein paar SPARQL queries erstellen lassen, die die bebilderten und unbebilderten Objekte in Österreich in Wikidata auffindbar machen. Z.B. [4] (lässt sich auch als Bildersuch-API verwenden, @Thomas Ledl:). Weitere Beispiele unter: d:User:Herzi Pinki/Sparql. Die Erfahrung lehrt, dass in vielen Fällen bereits Bilder auf Commons vorhanden sind, ihr müsst sie nur suchen und finden. (d.h. die passende Beschreibung / Kategorisierung kann komplett fehlen). lg --Herzi Pinki (Diskussion) 00:07, 12. Nov. 2019 (CET)

@Braveheart: ein bisschen Statistik: Ich habe seit 1. Juni rund 645 Bilder zu Wikidata-Objekten hinzugefügt, alles Bilder, die bereits auf Commons vorhanden waren. Bevor wir Fotografen ansetzen, Bilderwünsche zu erfüllen, sollten wir mE den Schatz auf Commons heben. Die 645 Bilder bebildern ein geschätztes Drittel aller von mir untersuchten Objekte auf Wikidata, hauptsächlich Berge und Seen, hauptsächlich in der Steiermark. lg --Herzi Pinki (Diskussion) 00:15, 25. Nov. 2019 (CET)

Die Karte ist leer

Auf https://wikidaheim.at/ sind keine Pins mehr zu sehen? @Ruben Demus:, kannst du bitte mal schauen? lg --Herzi Pinki (Diskussion) 01:23, 16. Dez. 2019 (CET)

Da scheint es wohl Probleme mit der php-Installation am Server zu geben. Hab jetzt (ungetestet) auf eine andere Version gewechselt und meiner Meinung nach sollte alles wieder laufen. Wenn sich irgendwo Probleme zeigen, dann bitte melden. --Ruben Demus (Diskussion) 02:21, 16. Dez. 2019 (CET)

merci vielmals. --Herzi Pinki (Diskussion) 03:26, 16. Dez. 2019 (CET)