Links zu Wikimedia

Zecke · 2013-04-21 10:23:52

Häufig möchte man Links zu Bildern auf Wikimedia-commons setzen. Z.B. für die historische Karte. Wenn die Bilder dort eine hohe Auflösung haben, dauert der Preview manchmal sehr lange. Wikimedia bietet aber auch auf jeder Bildseite verschieden skalierte Versionen an:

"Size of this preview: 800 × 600 pixels. Other resolutions: 320 × 240 pixels | 640 × 480 pixels | 1,024 × 768 pixels | 1,280 × 960 pixels."

Sind diese Links permanent, d.h. könnte man direkt auf die 320x240 pixel Version verlinken statt auf die "File:<image.pg>" Seite?
Die Wikimedia Dokumentation gibt da leider nicht viel her.

Gruß,
Zecke

aighes · 2013-04-21 10:36:32

Ich denke, das sollte der Auswerter selber machen und nicht in den Daten hinterlegt werden.

reneman · 2013-04-21 10:50:14

aighes wrote:

Ich denke, das sollte der Auswerter selber machen und nicht in den Daten hinterlegt werden.

Korrekt. Interessant ist vlt. zu wissen, dass die vorgegebenen "Vorschaugrößen" zwar im Cache von Wikimedia Commons vorgehalten werden, jedoch können sich diese Größen auch "zentral" ändern. Daher, wenn du dich auf eine bestimmte Größe fixierst, die es in ein, zwei Jahren vlt. nicht mehr gibt...

Edit: Dafür setzt man am besten Links auf die Dateibeschreibungsseite, um
A: Eine Vorschau aus dem Cache zu sehen
B: Die optionale Auswahlmöglichkeit für beliebige Größen zu erhalten
C: Die Lizenzen zu betrachten

Edit2: Für die Geschichtskarte ist dies hier ausführlich erläutert: http://wiki.osm.org/wiki/Historische_Ob … le_angeben

Last edited by reneman (2013-04-21 11:59:45)

Zecke · 2013-04-21 12:22:55

aighes wrote:

Ich denke, das sollte der Auswerter selber machen und nicht in den Daten hinterlegt werden.

Du hast natürlich recht.

Wenn aber eine Bilderseite von vorneherein Vorschaubilder verschiedener Größen anbietet (wie hier bei commons) und diese sehr schnell verfügbar sind (1-2s), dann wäre es doch schön, der historischen Karte (die sehr viel länger für die Skalierung großer Bilder braucht) die Arbeit zu erleichtern, indem man sie von vorneherein mit der kleinsten verfügbaren Version füttert.

Ich will eben nicht hingehen und die Originalbilder stark verkleinern, nur damit sie schneller angezeigt werden (und damit die Philosophie von commons vergewaltigen). Der interessierte Betrachter soll weiterhin die Möglichkeit haben, via commons das Bild in einer großen Auflösung anzusehen.

Mir ist nicht klar, ob die verschiedenen Größen bei commons prinzipiell vorliegen oder nur on the fly skaliert werden (darüber findet man nichts). In jedem Fall würde ich sie gerne auch ansprechen können.

Gruß,
Zecke

Zecke · 2013-04-21 12:29:12

Am angenehmsten wäre es natürlich, wenn ich mir darüber überhaupt keine Gedanken machen müßte und der Skalier-Algorithmus bei Bildern von commons automatisch die kleinst sinnvolle Version als Basis für seine Skalierung runterladen würde!

Oranger Wink!
Zecke

rurseekatze · 2013-04-21 12:31:59

In der OpenLinkMap wird etwa bei dem kleinen Vorschaubild in den Popups bereits eine verkleinerte Version vom Wikimedia-Server angefordert, damit das Laden nicht so lange dauert.

Wenn man auf das Thumbnail klickt, wird das Bild in Originalgröße angezeigt. Bislang habe ich hier keine Begrenzung eingebaut, es wird also immer die volle Auflösung angefordert. Es würde natürlich Sinn machen, hier eine gewisse Begrenzung einzubauen, denn kaum jemand wird wohl ein 10 Megapixel Foto in voller Auflösung anfordern wollen...

Grüße
Alex

Zecke · 2013-04-21 12:50:17

Das ist ja genau was ich will. Wenn ich auf den Link klicke, darf ruhig die Standardversion von commons angezeigt werden.

Ich wüßte ganz generell natürlich schon gerne, wie man gleich eine kleine Version laden kann - wie muss die URL dann aufgebaut werden?

Gruß,
Zecke

Last edited by Zecke (2013-04-21 12:51:59)

Tordanik · 2013-04-21 12:58:17

Kleine Versionen ansprechen kann man sie auf jeden Fall, und zwar in beliebigen Größen - auch 277 Pixel oder so etwas. Auch wenn ich es nicht genau weiß, gehe ich daher davon aus, dass alle Bildgrößen zuerst einmal on the fly skaliert werden und dann in einem Cache liegen. (Das ist auch deshalb nötig, weil man z.B. bei Wikipedia die gewünschten Bildgrößen in den Artikeln und Bildbeschreibungsseiten umstellen kann.)

Taginfo nutzt diese Funktionalität beispielsweise für die eingebundenen Bilder. Man könnte die URL wohl selbst zusammenbauen, wenn man weiß, in welchem Wiki das Bild tatsächlich liegt. Taginfo fragt stattdessen bei der Wiki-API an, da hier Bilder aus dem OSM-Wiki und Commons bunt gemischt sind. Jochens Gedankengänge, inklusive einer Andeutung wie er die URLs aufgebaut hätte, sind aus diesem Thread ganz gut ersichtlich: http://gis.19327.n5.nabble.com/CORS-on- … 43508.html

Wenn man die URL nicht selber zusammenbaut, sondern die Wiki-API nutzt, kann man direkt eine Breite für die zurückgelieferte URL (als iiurlwidth) mit angeben: http://wiki.openstreetmap.org/w/api.php … ormat=json

Oranger Assistent · 2013-04-21 12:59:52

Tach,

Zecke wrote:

Am angenehmsten wäre es natürlich, wenn ich mir darüber überhaupt keine Gedanken machen müßte und der Skalier-Algorithmus bei Bildern von commons automatisch die kleinst sinnvolle Version als Basis für seine Skalierung runterladen würde!

Goldene Regel #3 bei OSM (nach nicht kopieren und nach Spaß haben): niemals das Tagging an defekte Software anpassen. (Bitte ins Wiki aufnehmen.)

Wenn das Bauen der Thumbs von Wikimedia-Bildern als zu deutlich zu langsam empfunden wird, muss ich da was tun. Ich werde zuerst nachschauen, ob der WM-Server die Zeit braucht, weil wir ein Format abfragen, das nicht im Cache liegt, oder ob das Skalieren selbst zu lange braucht.

Wir können natürlich auch wie bei Flickr ein Redirekt zum Vorschaubild auf dem WM-Server geben. Jedenfalls solange, bis wir da gesperrt werden.

Oranger Wink!

Jaja. Immer auf die kleinen Plüschigen!

Orange Grüße
Der Assistent

Oranger Assistent · 2013-04-21 14:21:49

Tach,

so, nachgeschaut: Bild decodierem und skalieren braucht nur Millisekunden; der Thumbnailer ist praktisch ausschließlich damit beschäftigt, Seiten und Bilder vom jeweiligen Server abzuholen.

Statt des Originalbildes wird jetzt das Hauptbild der Commons-File:–Seite abgeholt, das meist eine gute Größenordnung kleiner ist: dies sollte die Bereitstellung der Thumbs beschleunigen.

Der nächste Schritt wird wohl sein, nicht die Commons-File:–Seite abzuholen, sondern die zur Bildbeschaffung erforderlichen Infos über die API zu ziehen.

Orange Grüße
Der Assistent

Zecke · 2013-04-21 19:50:47

Schneller als die Feuerwehr...

Zecke · 2013-04-26 16:04:37

Ist das eigentlich auf dem Produktionsserver schon aktiviert? Für mein Gefühl dauert das Laden von nicht gecacheten commons-Images immer noch sehr lang.

Gruß,
Zecke

Oranger Assistent · 2013-04-26 18:44:56

Tach,

Zecke wrote:

Ist das eigentlich auf dem Produktionsserver schon aktiviert?

Du kannst prüfen, wo die Zeit bleibt:

1. Popup öffnen
2. Auf Voransicht rechte Maustaste→“Grafik anzeigen”

Die gruselig lange URL enthält ein “…?image=…”

3. Die URL ändern zu “…?DEBUG=2&image=…”
4. Abschicken.

Es erscheint ein “Thumbnail 'xxx' created at ttt available.”

5. Shift-Reload

Es erscheint ein Log der Schritte bei der Erzeugung des Thumbnails mit Zeitangaben für die einzelnen Schritte.

Alternative zu 2-4: auf der Detailseite der Verknüpfung unten rechts folgen.

Für mein Gefühl dauert das Laden von nicht gecacheten commons-Images immer noch sehr lang.

Sag das dem Wikimedia-Server.

Plüschige Grüße
Der Assistent (orange)

Edit: Alternative eingerichtet.

Last edited by Oranger Assistent (2013-04-26 19:07:58)

Zecke · 2013-04-26 21:27:19

Ohne Worte...

URL: http://commons.wikimedia.org/wiki/File: … kessel.jpg
0.000s used for access check.
0.084s used for retrieval of 36460 bytes.
0.000s used for decoding image.
Rule: Image from '//upload.wikimedia.org/*.jp[e]g' on commons page.
URL: http://upload.wikimedia.org/wikipedia/c … kessel.jpg
0.000s used for access check.
29.040s used for retrieval of 211375 bytes.
0.043s used for decoding image.
0.019s used for scaling image.
Ok: Thumbnail '031ace6d872c75223791dd0ad7062dd9' created.
0.001s used for storing thumb.
Thumbnail '031ace6d872c75223791dd0ad7062dd9' created at 2013-04-26T22:22:49+02:00 available.

Spricht dafür, daß Wikimedia wohl die kleineren Bilder (teilweise ?) erst on the fly generiert?
Schade, aber wohl nicht zu ändern.

Aber danke für dein Debugging-Tool!

Gruß,
Zecke

Oranger Assistent · 2013-04-26 22:39:14

Tach,

Zecke wrote:

Ohne Worte...

Als kleiner Trost was Neues: der Parameter “select” selektiert beim Laden der Karte ein Objekt.
Beispiel: http://geschichtskarten.openstreetmap.d … n330343878

Bei geöffnetem Popup enthält der Permalink diesen Parameter.

Ist vielleicht nützlich für Permalinks bei dicht beieinanderliegenden Objekten.

Orange Grüße
Der Assistent

reneman · 2013-04-26 23:23:06

vielleicht
Echt toll!

wambacher · 2013-04-27 00:27:55

Zecke wrote:

Spricht dafür, daß Wikimedia wohl die kleineren Bilder (teilweise ?) erst on the fly generiert?
Schade, aber wohl nicht zu ändern.

Wird der Thumbnail jedesmal neu erzeugt oder nur beim ersten Aufruf? Wenn er gecached wird und es "meine" Bilder wären, wüsste ich schon, was ich machen würde.

Gruss
walter

lutz · 2013-04-28 06:25:09

hallo,

die thumbnails werden 1 woche lang gecached, es sind ca. 2000 bilder im cache.
die cashe-zeit können wir nach belieben einstellen.
zu zeit arbeitet ein oranger mitarbeiter daran, falls neuere bilder zur verfügung stehen, das diese im hintergrund geladen werden,
und solange das alte bild angezeigt wird.....
die cache-zeit wird dann auf jeden fall verlängert.

grüße von lutz

Zecke · 2013-04-28 09:31:29

Ich habe etwas gefunden, daß Commons die parallele Zahl der downloads pro IP auf zwei beschränkt (nicht sicher ob das nur für database dumps gilt). Könnte evtl. auch etwas ausmachen, wenn die Geschichtskarte eifrig benutzt wird...?

Warum eigentlich nicht für den download einen Squid vorschalten statt den Cache selbst zu entwickeln?

Gruß,
Zecke

Oranger Assistent · 2013-04-28 09:52:46

Tach,

Zecke wrote:

Warum eigentlich nicht für den download einen Squid vorschalten statt den Cache selbst zu entwickeln?

1. Weil es Unfug ist, bei jedem Aufruf das Thumbnail aus einem Originalbild neu zu berechnen, statt ein bereitliegendes Thumbnail auszuliefern.

2. Weil wir lieber das Thumbnail-Script um 5 Zeilen vergrößern, als dem Lutz die Betreuung eines Squids ans Bein zu binden.

Es gibt zur Zeit kein Problem. Wir liefern mit der maximal uns möglichen Geschwindigkeit aus. Zur Zeit muss der Abrufer beim ersten Aufruf eines Vorschaubildes nach einer Woche warten, während das Vorschaubild neuberechnet wird. Das ändern wir noch dahingehend, dass der Abrufer das alte Bild geliefert bekommt, während das neue parallel berechnet wird, um die Wartezeit zu vermeiden.

Orange Grüße
Der Assistent

Zecke · 2013-04-28 10:58:32

Hast sicher recht. Mir kam die Idee halt so, da ich einige Squids betreue...

Announcement

#1 2013-04-21 10:23:52

Links zu Wikimedia

#2 2013-04-21 10:36:32

Re: Links zu Wikimedia

#3 2013-04-21 10:50:14

Re: Links zu Wikimedia

#4 2013-04-21 12:22:55

Re: Links zu Wikimedia

#5 2013-04-21 12:29:12

Re: Links zu Wikimedia

#6 2013-04-21 12:31:59

Re: Links zu Wikimedia

#7 2013-04-21 12:50:17

Re: Links zu Wikimedia

#8 2013-04-21 12:58:17

Re: Links zu Wikimedia

#9 2013-04-21 12:59:52

Re: Links zu Wikimedia

#10 2013-04-21 14:21:49

Re: Links zu Wikimedia

#11 2013-04-21 19:50:47

Re: Links zu Wikimedia

#12 2013-04-26 16:04:37

Re: Links zu Wikimedia

#13 2013-04-26 18:44:56

Re: Links zu Wikimedia

#14 2013-04-26 21:27:19

Re: Links zu Wikimedia

#15 2013-04-26 22:39:14

Re: Links zu Wikimedia

#16 2013-04-26 23:23:06

Re: Links zu Wikimedia

#17 2013-04-27 00:27:55

Re: Links zu Wikimedia

#18 2013-04-28 06:25:09

Re: Links zu Wikimedia

#19 2013-04-28 09:31:29

Re: Links zu Wikimedia

#20 2013-04-28 09:52:46

Re: Links zu Wikimedia

#21 2013-04-28 10:58:32

Re: Links zu Wikimedia

Board footer