Od pewnego czasu pobieram dane z flickr.com dotyczące najbardziej interesujących zdjęć [sposób w jaki flickr.com tworzy listę `najbardziej interesujących' zdjęć nie jest znany]. Konkretnie wykonuję flickr.interestingness.getList pobierając 500 zdjęć dla każdego kolejnego dnia.

Dla takiego zbioru policzyłem: -- średnią liczbę tagów, tagów maszynowych (tj. takich, które zawierają dwukropek, np.: geo:lat=54.00) i tagów wielowyrazowych; -- średnią liczbę zbiorów i średnią liczbę puli, do których należy zdjęcie. Wreszcie -- odsetek zdjęć geokodowanych. Wszystkie ww. statystyki w rozbiciu na kolejne miesiące...

Teza była taka, że z czasem średnie/udziały będą miały większe wartości bo użytkownicy coraz chętniej będą swoje zdjęcia oznakowywać, doceniając płynące stąd korzyści. Rosnąca liczba tagów maszynowych i/lub wielowyrazowych oraz rosnący odsetek zdjęć geokodowanych w pewnym stopniu świadczyłaby o rosnącej semantycznej precyzji metadanych na flickr.com. Dane przedstawione poniżej nie potwierdzają tego założenia:

Statystyki flickra. Od : 2006-11-28 do 2008-08-28
-----------------------------------------------------
Mc/Yr     :    Loc   MTag    Poo   RTag    Set    Tag
--> 200611:   13.9  0.067  8.810  1.704  1.543  8.975 
--> 200612:   13.3  0.064  8.690  1.740  1.501  8.942 
--> 200701:   14.0  0.066  8.607  1.603  1.596  9.281 
--> 200702:   13.8  0.063  8.862  1.413  1.654  9.675 
--> 200703:   13.4  0.063  9.159  1.398  1.679  9.936 
--> 200704:   13.6  0.056  9.556  1.434  1.703 10.302 
--> 200705:   14.4  0.056 10.229  1.432  1.700 10.568 
--> 200706:   13.2  0.057  9.968  1.386  1.688 10.217 
--> 200707:   12.8  0.048  8.136  1.401  1.613  9.547 
--> 200708:   14.0  0.059  7.770  1.585  1.773 10.249 
--> 200709:   13.5  0.053  7.321  1.638  1.767 10.174 
--> 200710:   13.6  0.057  6.939  1.610  1.743  9.722 
--> 200711:   12.9  0.055  6.698  1.532  1.714  9.392 
--> 200712:   12.4  0.048  6.698  1.606  1.749  9.644 
--> 200801:   12.1  0.052  6.818  1.599  1.685  9.456 
--> 200802:   11.2  0.049  6.962  1.603  1.664  9.401 
--> 200803:   10.4  0.049  6.786  1.637  1.675  9.457 
--> 200804:   10.3  0.049  6.475  1.623  1.672  9.315 
--> 200805:   10.6  0.053  6.505  1.661  1.690  9.205 
--> 200806:   10.0  0.047  6.369  1.693  1.650  9.023 
--> 200807:   10.0  0.038  6.534  1.664  1.658  9.101 
--> 200808:   11.1  0.048  6.181  1.726  1.715  9.471
----------------------------------------------------- 

Gdzie: Loc -- odsetek zdjęć geokodowanych; MTag -- średnia liczba tagów maszynowych; Poo -- średnia liczba puli; RTag -- średnia liczba tagów wielowyrazowych ; Set -- średnia liczba zbiorów ; Tag -- średnia liczba tagów.

Jak widać w zasadzie wartości są stałe. Można nawet zauważyć, że odsetek zdjęć geokodowanych uległ niewielkiemu obniżeniu (z 13--14, do 10--11%). Także spadła nieznacznie przeciętna liczba puli, do których wysłano zdjęcie... Liczba tagów maszynowych jest śladowa. Hmmm...

Dopisane 16 września 2008: Policzę jeszcze ww. statystyki dla danych bardziej losowych. Ściągnę mianowicie opisy zdjęć za pomocą flickr.photos.getRecent:

do { $pageno++; ## następna strona

   my $resp = get ( "http://www.flickr.com/services/rest/?" .
     "method=$method&api_key=$api_key&per_page=$max_per_page&" .
     "page=$pageno&extras=geo,views,tags,machine_tags,license" );
   ## sprawdź czy jest OK:
   eval { $photos = $parser->parse_string($resp) } ;

   unless ($@) {## pomiń stronę z błędami
     ## ... obrób dokument XML zawarty w $resp ##
   }
} while ( ($current_page < $total_pages) && ($pageno < $max_pages) );

Konstrukcja eval{ ... } służy do tego żeby skrypt się nie wywalał po fatal error tylko wykonywał następną iterację. A potrafi się wywalić na parsowaniu XML bo rzadko-bo-rzadko ale czasami coś jest nie tak z kodowaniem (UTF).

Skrypt, którego fragment jest wyżej będzie uruchamiany losowo plus/minus co 15 minut:

#!/usr/bin/perl
## Do forever with 15 min random delay or ca 4 x hour (\approx 100 per 24 hrs)
while (1) { my $runTask = `perl flickr_photo_recent.pl`;
   sleep (int(rand(600 )) + 600); }

Plan jest taki żeby ściągać dane przez 10 dni. Zakładając 100 tys zdjeć na dzień da to próbę wielkości 1 mln zdjęć.

Dopisane 26 września 2008: Niebuforowany zapis do STDOUT oraz do pliku. Sprawa ciut niejasna: w Internecie większość tekstów wskazuje, że problem załatwia nadanie zmiennej $| wartości niezerowej. Mi to jednak nie działa... W końcu znalazłem działającą odpowiedź:

#!/usr/bin/perl
use FileHandle;

# to make STDOUT flush immediately, simply set the variable $|
$| = 1;

# to prevent buffering when writing to files, set autoflush on
# the file handle
open (OUT, ">>test.out") || die "could not create test.out - $!";
OUT->autoflush(1);

print OUT "writing to file\n";

close(OUT); exit(0);

Dopisane 2 października 2008: Pierwsze wyniki dla danych z 18.09--30.09 (łącznie 364,127 zdjęć): 1) odsetek zdjęć zawierających co najmniej jeden tag: 40,77%; 2) odsetek zdjęć geotagowanych: 4,06%; 3) odsetek zdjęć tagowanych i umieszczonych w co najmniej jednym pulu: 10,17%; 4) odsetek zdjęć geotagowanych, tagowanych i umieszczonych w co najmniej jednym pulu: 1,15%. Przeciętnie zdjęcie było oznaczone 2,5 tagami. Jak widać najbardziej interesujących zdjęcia są ca 3 razy częściej geotagowane i mają 3--4 razy tyle tagów... Zrozumiałe bo znaczna część zdjęć jest wrzucana ,,jak leci'' bez oznaczenia ich czymkolwiek. Z reguły też zdjęcia takie są mało interesujące dla szerszej publiczności...

Dopisane 4 października 2008: Dziś wylosowałem 2,5% z 233520 użytkowników flickr, których zdjęcia pobrałem w ostatnich dniach. Te 2,5% to było dokładnie 5838. Ściągnąłem za pomocą flickr.people.getInfo informacje dotyczące liczby zdjęć i daty zawartej w elemencie firstdate. (The firstdate element contains the unix timestamp of the first photo uploaded by the user.). Myślałem, że to data pierwszego uploadu, ale tak nie jest. Wygląda to raczej na (opis jest raczej lakoniczny) na datę wykonania pierwszego zdjęcia zamieszczonego na flickr.com. Data ta jest zapewne odczytana z odpowiedniego pola Exif, a co za tym idzie może jej nie być, albo może być lipna... Anyway wyniki są następujące:

Wyszczególnienie    N  mediana  średnia  dominan   od.st.      max  min    Ws    Ws'
 L.zdjęć         5837   191.00   846.11   200.00  3121.26   171182    0    0.21 (0.63)
 L. dni          5837   307.00   435.80    18.00   546.00    14157    2    0.77 (0.71)

L. dni, to liczba dni od firstdate (coś w rodzaju stażu). Próba się zmniejszyła do 5837, bo z jednym użytkownikiem był problem... Ws to współczynnik skośności Pearsona (x-D)/sd (a w nawiasie podobny współczynnik skośności (Ws') liczony na podstawie Mediany, jako 3(x-Me)/sd.) Rozkłady są zatem prawostronnie asymetryczne. A ten gość co ma 170tys zdjęć jest tutaj:-). Interpretacja: 50% użytkowników, którzy publikują swoje zdjęcia ma ich mniej niż 191... BTW element count zawiera liczbę wszystkich zdjęć umieszczonych na flickr.com, nie tylko zdjęć o statusie public. Nie jest to napisane w dokumentacji ale zweryfikowałem empirycznie...

W książce Flickr Hacks Paula Bauscha i Jima Bumgardnera do manipulowania danymi w formacie XML przesyłanymi z flickr.com używa się XML::Simple. Jakoś XML::Simple nie wydaje mi się specjalnie simple w tym wypadku. Zdecydowanie wolę XML::LibXML, który pozwala przede wszystkim na dotarcie do poszczególnych fragmentów dokumentów XML w prosty sposób bez używania karkołomnych referencji. Przykładowo poniższy skrypt (fragment) wykonuje zapytanie flickr.photos.search [najistotniejszą częścią skryptu -- zaznaczoną odmiennym kolorem tła -- jest pętla do { ... }]:

use XML::LibXML;
use LWP::Simple;
use Getopt::Long;

require 'login2flickr.rc';

our $api_key;
our $my_flickr_id;

my $tags_txt;
my $show_help;
my ($user_id, $all_users, $report_views);
my @Photos;

GetOptions( "all" => \$all_users,
     "user=s" => \$user_id, "views"  => \$report_views,
     "tags=s" => \$tags_txt);

unless ( $user_id ) {  $user_id = $my_flickr_id; }
if ( $all_users ) { $user_id = ''; } ## search all photos

my $parser = XML::LibXML->new;
my $pageno;
my $method = 'flickr.photos.search';
my $max_per_page = 500;
my ($total_pages, $current_page);

my $search_query =  "&extras=geo,views"; # http://www.flickr.com/services/api/flickr.photos.search.html
if ( $user_id ) { $search_query .=  "&user_id=$user_id";  }
if ( $tags_txt ) { $search_query .=  "&tags=$tags_txt" }


do {
   $pageno++;

   my $resp = get ( "http://www.flickr.com/services/rest/?" .
       "method=$method&api_key=$api_key&per_page=$max_per_page&page=$pageno" . 
       $search_query );

   ## sprawdź czy jest OK:
   my $photos = $parser->parse_string($resp); 
   unless ( $photos->getElementsByTagName('rsp' )->[0]->getAttribute( 'stat' ) eq 'ok') { 
        die "Problems with retriving photo list!\n" }

   push @Photos, $photos->getElementsByTagName('photo' );

   $total_pages = $photos->getElementsByTagName('photos' )->[0]->getAttribute('pages' );
   $current_page = $photos->getElementsByTagName('photos' )->[0]->getAttribute('page' );

   # Dla dużych zbiorów zdjęć może długo trwać, więc wypisz że coś robisz:
   printf STDERR " *** Page %d  of %d retreived...\n", $current_page, $total_pages;

} while ( $current_page lt; $total_pages  );

## Lista @Photos zawiera wszystkie zdjęcia...
## ... dalsza część skryptu ...

Pętla jest niezbędna ponieważ flickr API organicza wielkość zwracanego dokumentu do maksymalnie 500 zdjęć. Jeżeli zdjęć jest więcej, to zapytanie należy zadać wielokrotnie, zmieniając wartość parametru page. Przy czym liczbę wszystkich stron określa wartość atrybutu pages.

Po ściągnięciu dokumentu skrypt sprawdza czy wszystko jest OK. Jeżeli tak, to za pomocą getElementsByTagName pobiera wszystkie elementy photo i dodaje je do listy @Photos. Teraz pobierane są wartości atrybutów pages/page w celu ustalenia czy wszystko już ściągnięto. Jeżeli pages < page to pętla działa dalej...

Zwracam uwagę, że od jakiegoś czasu zapytanie może zawierać parametr extras, dzięki któremu zwracany dokument XML zawiera dodatkowe informacje, takie jak: tagi, współrzędne geograficzne, liczbę odsłon, itd... Jest to opisane w API na flickr.com a także tutaj. W wyżej przedstawionym skrypcie deklaracja:

my $search_query =  "&extras=geo,views";

Oznacza, że do standardowych opisów zdjęć będą dodane także współrzędne geograficzne (oczywiście tylko wtedy gdy zdjęcia będą nimi oznaczone) oraz liczba odsłon. BTW dodanie extras=views powoduje, że kiedyś niemożliwy do wykonania poprzez API problem ustalenia ile razy zdjęcie było oglądane teraz jest jak najbardziej wykonalny. Zatem skrypty -- opisane w Nowa usługa na flickr.com oraz Czy flickr umie liczyć -- lepsze rozwiązanie -- są już niepotrzebne.

Kompletny skrypt pobierający zdjęcia z flickr.com i wypisujący plik GPX dla tych, które zawierają współrzędne geograficzne jest tutaj. Ale uwaga: próba wykonania zestawienia wszystkich wież ciśnień z flickr.com:

flickr_photo_gsearch.pl -a -t 'wieżaciśnień,wasserturm,watertower' > wasserturme-alles.xml

Skończyła się pobraniem ponad 23 tysięcy zdjęć (z tego około 6 tys. było geokodowane). Plik GPX pn. wasserturme-alles.xml miał 1,8 Mb i za nic nie szło tego wyświetlić w przeglądarce. Za duże... Mniejsze pliki są ok: kaplice [mapa ] albo moje wieże ciśnień [mapa ].

Wziąłem aparat na dzisiejsze jeżdżenie rowerowe i popstrykałem trochę zdjęć w czasie jazdy. Rowerzyści są na nich od strony rewersu widoczni w większości (por. rysunek obok), ale to tylko podnosi autentyczność--tak to wygląda w środku peletonu:-)

No i GPS złośliwie się wyłączył w okolicach Kielna czyli tak w 2/3 trasy. Akurat zdjęcia, na których kol. Rysiu mnie sfotografował nie mogą być geokodowane (aka geotagowane), bo ślad się urwał. Pech... Ale, ale... Już kiedyś tą trasą jechałem i ślad mam tyle, że nie do końca tą, pewnie z trochę inną prędokością dziś dziś ale lepsze to niż nic. Tyle, że stempel czasu dla każdego punktu na śladzie jest zły. Pomyślałem, że można by oszukać gpsphoto ,,uzupełniając'' dzisiejszy ślad kawałkiem starego. Okazało się to całkiem proste dzięki gpsbabel:

gpsbabel -t -i gpx -f plik-we.gpx -x track,move=spec-czasu -o gpx -F plik-wy.gpx

Gdzie spec-czasu ma postać znak99d99h99m99s (99 oznacza stosowną liczbę, a poszczególne składniki są opcjonalne.) Przykładowo +2h przesunie czas o dwie godziny do przodu. Podobnie +32d0h1m42s przesunie o 13 dni, minutę i 42 sekundy ,,do przodu''.

Teraz w Google maps ustaliłem gdzie się kończy dzisiejszy ślad a następnie znalazłem punkt na śladzie z 23 sierpnia z grubsza odpowiadający tej pozycji. Zrobiłem to zupełnie na piechotę metodą ,,kilku przybliżeń'' (tj. wstawiałem do pliku GPX element wpt odpowiadający punktowi ze śladu, który był ,,w okolicy'' szukanego miejsca. Oczywiście pierwszy strzał był niezbyt celny, ale po kilku podstawieniach znalazłem szukany punkt). Od tego punktu wyciąłem do końca (bo akurat do końca trasy się pokrywały) i zapisałem jako plik tmp.gpx. Teraz ustaliłem różnicę czasu między obu punktami. Do tego ostatniego zadania użyłem Perla:

#!/usr/bin/perl
# Uruchom np.: delta_days.pl -w 2008:8:24:10:2:9 -p 2008:9:6:10:3:51
use Date::Calc qw/Delta_DHMS/;
use Getopt::Long;

GetOptions("w=s" => \$wszesniej, "p=s" => \$pozniej);
@wczesniej = ex ($wszesniej); @pozniej = ex ($pozniej);

my ($d, $h, $m, $s) = Delta_DHMS(@wczesniej, @pozniej);
print "Różnica: d: $d, h: $h, m: $m, s: $s\n";

sub ex { my $w = shift ;  return ( split /[:;-]/, $w ) }

Różnica wyniosła 13 dni, minutę i 42 sekundy. Teraz uruchomiłem gpsbabela:

gpsbabel -t -i gpx -f tmp.gpx -x track,move=+13d0h1m42s -o gpx -F tmp-out.gpx

Śladem z plik tmp-out.gpx uzupełniłem dzisiejszy, niekompletny ślad. Skrypt gpsphoto (uruchomiony via My-photo-sync.sh) zsynchronizował wszystkie fotki. Oczywiście jest błąd (np. wynikający z tego, że wtedy i dziś poruszałem się z różną prędkością), ale imho jest to błąd akceptowalny...

Całość jest tutaj. No i niech ktoś się teraz nie upiera, że Windowsem i Excelem to on wszystko obliczy....:-)

Jak już jestem przy tematyce rowerowej, to szukając butów SPD dla młodego usiłowałem obejrzeć stronę WWW jednego z większych trójmiejskich sklepów. Nie udało się... nur für Windows. I to tak dramatycznie: nic nie widać, w nic nie można kliknąć...