Impreza odbyła się w Sopocie (jest nawet info na www.irb.com). Wczoraj był finał: Rumunia vs Gruzja 31 : 28. Emocjonujący mecz, po cztery przyłożenia a do tego 2 drop gole (również po jednym dla każdej ze stron). Oglądałem też półfinał w minioną środę, w którym Gruzja rozniosła Rosję 37 : 0. Zdjęcia z obu ww. meczy umieściłem na flickr.com.
W Sobotę pojechaliśmy razem z Jasiem na wycieczkę rowerową. Jakoś tak niedawno Jaś zapalił się całkiem na serio do rowerowania i zaczął jeździć -- sam -- po 20--30 kilometrów. Widząc co się dzieje dokupiłem mu pedały SPD (Shimano PD-M520) + buty (Shimano SH-M075G). W sklepie Żuchlińskiego 299 zł (na Allego trochę taniej, ale przecież nie będę robił wiochy mierząc buty w sklepie i kupując na Allegro) Do tego kask dla bezpieczeństwa i rajtuzy żeby wyglądał godnie (to z kolei kupiliśmy w sklepie Marka Szerszyńskiego w Sopocie).
Ponieważ po drogach się bałem z Jasiem jeździć pożyczyłem rower klasy Mountain Bike od Bogusia L. Pojechaliśmy do Oliwy a dalej ul. Kościerską do Owczarni, tam trochę pogubiliśmy drogę i zamiast pojechać dalej ul. Nowy Świat w stronę jeziora Wysockiego pojechaliśmy Meteorytową. [Tutaj uwaga: ww. ulice to wiejskie drogi a nie żadne ulice; a Meteorytowa nie dość że jest drogą polną to jeszcze do tego po ostatnich deszczach pełna kałuż i błota.] Dalej jadąc ul. Dębową dojechaliśmy do Barniewic a stąd kawałek brzegiem lasu po czym skręt w prawo. Jadąc teraz prosto przejechaliśmy w poprzek cały las pomiędzy Chwaszczynem, Tuchomkiem a Barniewicami, mijając po drodze kopalnię żwiru i parę malowniczych [zapewne pożwirowych] stawów. Po dojechaniu do Chwaszczyna -- ulicą Mickiewicza -- skręciliśmy do Osowy i dalej do Sopotu przez las. Powrót przez Wielką i Małą Gwiazdę. Ślad można obejrzeć tutaj [dystans: 35 km].
Następnym razem -- jak się nie pogubimy -- chcemy pojechać prosto Nowym Światem aż do Tuchomka, przeciąć drogę Gdynia-Kościerzyna i objechać jezioro Tuchomskie.
Dopisane 11 października 2008: Wczoraj byliśmy w Osowej ale wybraliśmy krótszą trasę: Owczarnia -- ul. Gnieźnieńska -- Źródło Marii. Powrót do Sopotu przez Gołębiewo. Bardzo fajna trasa, długość około 30 km (na liczniku wyszło 29,20). Ślad na mapie jest tutaj. A tutaj wersja eksperymentalna, na której można (klikając) wyświetlać średnią prędkość. Mianowicie należy kliknąć dwa razy na ślad, definiując w ten sposób początek i koniec odcinka śladu a zostanie pokazana średnia prędkość na tym odcinku. Uwaga: odcinek będzie zdefiniowany od--do najbliższych (miejsca kliknięcia) punktów ze śladu GPX. Uwaga2: nie należy celować myszą ,,w ślad'', tj. czerwoną linię tylko trochę obok....
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...
Dokumenty z http://pinkaccordions.homelinux.org/wblog nie wyświetlają się poprawnie w IE 6. Czy się wyświetlają w nowszych Eksplorerach to nie wiem -- nie sprawdzałem. Nawet chciałem dziś coś w tej sprawie dłubnąć ale nic z tego nie wyszło. Ostatecznie poprzestałem na dodaniu uwagi w nagłówku, że w MSIE nie działa. W sumie używanie dziś MSIE to dziwactwo, bo czemu nie korzystać z czegoś co jest lepsze skoro to nic nie kosztuje?
Dopisane 17 września 2008: Ponieważ arkusz CSS działał z przeglądarkami FF/Opera a z MSIE nie, więc uważałem że problem jest -- jak prawie zawsze -- z systemem specjalnej troski. Tak to już jest, że jak ktoś notorycznie coś psuje, no to podświadomie się zakłada, że ów ktoś ma zawsze popsute. [Pamiętam zwłaszcza w tym kontekście hasełko reklamowe MS Polska sprzed paru lat: kto pomyśli -- my pomyślimy. Na wydruku brak było tzw. polskich liter: kto pomyli -- my pomylimy. Brawo dla tych panów za szczerość:-]
Jednak w wolnej chwili sprawdziłem, i się okazało, że strona nie wyświetla się prawidłowo w IE7 też, co by mogło znaczyć że być może mój arkusz na 100% nie jest poprawny. Przyznam się przy okazji bez bicia, że nie znam/nie używam ,,zaawansowanych'' właściwości CSS -- arkusz skopiowałem kiedyś z pewnej strony i wydawało się że działa. Teraz po krótkich konsultacjach dodałem left do właściwości lewej/prawej kolumny. Teraz działa lepiej, a przynajmniej działa w IE7. BTW arkusz, o którym mowa jest tutaj: 2cols.css.
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ąć...
Czasy kiedy tzw. media informowały wydają się czasami minionymi... Przez kilka ostatnich dni nachalnie wtłaczana była do pustych głów teza, pn. ``absencja L. Wałęsy w katalogu IPN to skandal i oczywisty dowód politycznej zależności Instytutu od jego politycznych mocodawców''. Jak już puste głowy uwierzyły w tę kolejną niegodziwość PiS, to w GW ukazał się -- przyznam zaskakujący -- tekst opisujący tę sprawę tak jak ona wygląda: Osób, które otrzymały z IPN status pokrzywdzonego, jest ponad 50 tysięcy. To właśnie nazwiska ludzi z tej grupy są [...] najczęściej wpisywane do katalogu. Tymczasem na zamieszczonej przez IPN liście znajduje się zaledwie 2129 nazwisk [...] Na liście brakuje wielu znanych działaczy opozycyjnych w tym Antoniego Macierewicza, Jana Olszewskiego i Ludwika Dorna. Dodatkowo: [...] Wskutek zapisu ustawy nakazującego zgodę osoby, której dane są publikowane, w katalogu niestety nie mogą zostać zamieszczone nazwiska osób rozpracowywanych, które nie żyją [...] To oznacza, że na liście nie będzie nazwisk wielu znanych opozycjonistów, jak choćby Jacka Kuronia czy Bronisława Geremka. (cf. ). Naiwne pytanie: po co było zatem wcześniej wiatr robić, pisząc bzury i mącąc w głowach?
Teza, że ,,Kłamstwo powtarzane wielokrotnie staje się prawdą'' przez wielu jest przypisywana J. Goebbelsowi. Mniej znane jest, że Reichsminister osobiście zweryfikował powyższe twierdzenie empirycznie. W swoich artykułach z Der Angriff uporczywie określał on szefa berlińskiej policji, Dr. Bernharda Weissa, jako ,,Izydor Weiss'' [Imię Izydor ma/miało w Niemczech podobną konotację jak w Polsce, np. imię ,,Mosiek'']. Po 2--3 latach większość berlińczyków była przekonana, że Dr. Weiss ma na imię Izydor. Prowokował Weissa do wytaczania sądowych procesów [Weiss wytoczył mu ich aż -- podobno -- 28], co nagłaśniało ,,spór''. Spór o co? No właśnie... czy coś nie wydaje się w tej historii znajome...
W zasadzie tematów ,,politycznych'' nie poruszam bo się nie znam i wolę się nie ośmieszać. Ale ten nie jest do końca polityczny... Raczej historyczno-socjologiczny:-) A ministerstwo o którym wyżej wspominam oficjalnie i ekshibicjonistycznie się nazywało: Reichsministerium für Volksaufklärung und Propaganda (oświecenia publicznego i propagandy).
