Zrezygnowałem wreszcie z używania do komunikacji z GPSem programu GPSman na rzecz GPSBabela. Ten pierwszy jest programem interaktywnym a przez to niezbyt wygodnym bo trzeba się trochę naklikać żeby przegrać zawartość pamięci Geko na PC. GPSBabel działa w trybie wsadowym, dzięki czemu można oszczędzić dużo (cennego) czasu:
#!/bin/bash TODAY=`date +"%Y%m%d"` # zapisz do pliku yyyymmdd.gpx gpsbabel -t -r -w -i garmin -f /dev/ttyS0 -o gpx -F "$TODAY.gpx"
Przyznać muszę, że podchodziłem do tego GPSBabela jak do jeża bo przy poprzednich próbach coś mi tam nie działało. A niesłusznie -- wystarczyło przeczytać dokumentację.
Najwięcej czasu straciłem zresztą na podłączeniu Garmina do komputera.
Mój Geko 301
jest podpięty do PC standardowym ,,fabrycznym'' kablem
pn. RS232 serial port connector
(part number: 010-10310-00). Port szeregowy, tj. /dev/ttyS0
w nomenklaturze Linuksa, w FC5 jest dostępny tylko dla superużytkownika.
BTW mam poczucie, że wcześniej był dostępny dla wszystkich.
Kłopot ten rozwiązałem w sposób przedstawiony
tutaj:
ls -l /dev/ttyS0 crw-rw---- 1 root uucp 4, 64 gru 18 2007 /dev/ttyS0 /usr/sbin/usermod -G uucp tomek # dodanie tomka do grupy uucp
Uwaga: program usermod
działa tak, że jeżeli
użytkownik jest obecnie członkiem grupy, której nie podano na
liście--wartości opcji -G
, to zostanie z niej usunięty.
Lepiej więc zwyczajnie uruchomić vi
i dopisać co trzeba
do /etc/groups
.
Mając już zgrany ślad (track) i punkty (waypoints)
zacząłem kombinować co dalej z tym robić. Sposób w jaki publikuję
moje ślady korzysta
z biblioteki
gpx-viewer
Kaza Okudy. Każdy punkt z pliku GPX jest przedstawiony w postaci
standardowej ,,pinezki'' znanej z google maps. Pinezka po
kliknięciu zamienia się w okienko zawierające zawartość
elementów-dzieci elementu wpt
(tj. ele
,
name
, cmt
, desc
oraz sym
)
oraz atrybuty tego elementu (lat
i lon
), np.:
<wpt lat="54.443087485" lon="18.540491704"> <ele>69.340332</ele> <name>168</name> <cmt>168</cmt> <desc>168</desc> <sym>Flag</sym> </wpt>
Gdyby ww. element zawierał element extension
, to
pokazana by była tylko zawartość extension
.
W przykładach ze strony Okudy extension
zawiera
element img
zawierający z kolei zdjęcie
zrobione w tym właśnie miejscu:
<wpt lat="49.237919" lon="-122.760106"> <ele>4.0</ele> <name>Photo 2</name> <extensions><html><![CDATA[ <a href="http://okuda.blogspot.com/2005/07/traboulay-poco-trail.html" target="_blank"> <img src="blog/2005-07/IMG_2370-01.jpg" /> </a> ]]></html></extensions>
Teraz mała dygresja: odsyłacze do zdjęć na flickr.com są tworzone według pewnego schematu.
Strona główna zdjęcia ma adres http://www.flickr.com/tprzechlewski/<photo_id>/
, gdzie
<photo_id>
oznacza identyfikator zdjęcia.
Plik ze zdjęciem ma zaś następujący URL:
http://static.flickr.com/<server>/<photo_id>_<secret>_<size>.jpg
Wartości <server>
oraz <secret>
można ustalić
np. poprzez wykonanie metody flickr.people.getPublicPhotos
.
Wartościami size
są s
(square), t
(thumbnail), m
(small), b
(large), o
(original). Oznaczają one odpowiednio pliki o wielkościach
75, 100, 200, 1024 pikseli i wielkość oryginalną. Rysunek typu
square to kwadrat, pozostałe to prostokąty o dłuższym boku
równym podanej licznie pikseli. Prostokąt o dłuższym boku równym 500 pikseli
to wielkość zdjęcia, która jest wyświetlana na stronie głównej zdjęcia.
Ta wielkość
jest wybierana jeżeli URL nie zawiera części _<size>
.
Ja chciałem żeby element img
wewnątrz extension
w pliku GPX
wskazywał na zdjęcie w rozmiarze thumbnail
na flickr.com a element a
odsyłał na stronę główną tego zdjęcia. Żeby nie wpisywać
kodu ręcznie wymyśliłem to następująco.
Za pomocą skryptu
flickr_getphotolist.pl
pobieram informacje nt. wszystkich zdjęć (publicznych, ale to ograniczenie
akurat jest OK). Skrypt zapisuje informacje w postaci następującej listy haszy:
@photos = ( {'owner' => '20425995@N00','isfriend' => '0','ispublic' => '1','secret' => '95826dcd42',\ 'farm' => '3','title' => 'dscf1209','server' => '2343','id' => '1747402167','isfamily' => '0'}, ...
do pliku ~/.flickr/hr.icio.ph
. Prosty skrypt zwraca kompletne
adresy URL po podaniu tytułu zdjęcia (działa przy założeniu, że tytuły są unikatowe):
#!/usr/bin/perl require "$ENV{HOME}/.flickr/hr.icio.ph" ; $photo_title = shift; for (@photos) { if ($photo_title eq $_->{title} ) { print "<extensions><html><![CDATA[ <a href=\"http://www.flickr.com/tprzechlewski/$_->{id}/\" target=\"_blank\"> <img src=\"http://static.flickr.com/$_->{server}/$_->{id}_$_->{secret}_t.jpg\" /> </a> ]]></html></extensions> \n"; } }
Teraz wystarczy dopisać w .emacs
funkcję, która w miejscu wywołania albo zapyta
o tytuł zdjęcia, albo pobierze go sama z wiersza gdzie jest kursor po czym wstawi to co
wypluje ww. skrypt do Emacsowego bufora. Genialne:-)
Na próbę dodałem zdjęcia do śladu
wygenerowanego 16. 12. 2007 r.
BTW patrząc na ten dziwny ślad nie mogę się powstrzymać od sarkazmu, mając w pamięci opinię niejakiej squishy z forum flickr.com: ... it's smaller than many cell phones and I think it's fabulous. I just turn it on and toss it in a backpack, then download the track log later to sync with photos... Gdzie ona mieszka? Na pustyni Gobi? Albo pracuje w Garminie... Albo to sync with photos jest plus/minus 10 kilometers. Bo mój geko 301 prawie zawsze zgubi ślad w trudnym terenie typu las, duże budynki, głębokie doliny itp...
Niedawno (13 grudnia 2007) Flickr uruchomił nowy serwis pn. stats! Użytkownicy serwisu z wykupioną usługą pro (ca 25 USD, czyli niedużo -- jak to się czasy zmieniły BTW) mają dostęp do różnych statystyk dotyczących swoich zdjęć. Informacje o usłudze zobaczyłem dzisiaj. Żeby z niej skorzystać trzeba się zasubskrybować -- czytaj nacisnąć duży guzik ze stosownym napisem. Wówczas ukazuje się napis, że OK, ale statystyki będą jutro. Grozę potęguje animacja gościa z pneumatycznym młotem. Widocznie jestem jednym z pierwszych bo były od razu -- wystarczyło odświeżyć stronę.
A więc pro-user dostaje takie informacje jak: liczba odsłon dla każdego zdjęcia oraz statystyki adresów referer w podziale na ,,wczoraj'' oraz ,,ogółem''. Ponadto wykres liniowy liczby odsłon zawierający dzienne dane z ostatniego miesiąca oraz zestawienie tabelaryczne zawierające podsumowania liczby odsłon (wczoraj, ostatni tydzień, ostatni miesiąc oraz ogółem) dla stron głównych (photostream), zbiorów (sets), kolekcji (collections) i stron pojedynczych zdjęć.
Statystki ,,oglądnięć'' dostępne ze strony
http://www.flickr.com/photos/tprzechlewski/stats/allphotos/
(Nie ma co klikać, więc i linka nie ma -- strona dostępna po
zalogowaniu:-) są kompletne, tj. dla każdego zdjęcia dostępna jest
liczba odsłon (z wczoraj, z ostatniego tygodnia oraz ogółem).
W pierwszej chwili pomyślałem, że nowa usługa renders obsolete
jak mawiają Anglicy moje
skrypty,
które z takim zapałem ostatnio udoskonalałem.
Ale niekoniecznie! Dane
ze strony stats! primo nie są trwałe (niektóre tak -- ale nie wszystkie,
np. dzienne statystyki oglądalności dostępne są tylko dla ,,wczoraj''),
secundo żeby były trwałe trzeba je ściągać na swój komputer
na przykład codziennie. No i tu się przyda programik
flickr_store_views.pl
,
który potrafi się zalogować na flickr.com, pobrać
stronę i zapisać co trzeba na dysk.
Zamiast ściągać 170 stron i z nich
wyciągać potrzebne informacje wystarczy teraz ściągnąć kilka stron
spod adresu tprzechlewski/stats/allphotos/yesterday/pageliczba
robiąc to metodycznie, czyli codziennie.
Jeszcze link z forum z informacjami nt. omawianej wyżej usługi. Your stats will eventually be a rolling 28 day window, czyli dostępne będą tylko dane z ostatniego miesiąca. Zwracam też uwagę na komentarz dot. tłumaczenia słowa interestingness na język hiszpański jako interesidad. Że niby takie słowo nie istnieje. Faktycznie nie ma w słowniku a google znajduje raptem 4 strony z interesidad (w tym powyższa). Ale jak przetłumaczyć interestingness (za WordNet: the power of attracting or holding one's interest), np. na j. polski? Moc przyciągania?
Dopisane 13 maja 2008:
Skrypt
flick-store-views.pl
przestał działać. Coś zostało zmienione w procedurze logowania.
Nie chce mi się tego poprawiać...
Znacząco poprawiłem swój tryb do dodawania zdjęć na flikr.com. Teraz wszystko się dzieje
wewnątrz Emacsa łącznie z uruchomieniem wysyłania plików na serwer. W starej wersji
pliki konfiguracyjne czytał Emacsowy moduł xml.el
co było może
i eleganckie ale odbywało się przeraźliwie wolno. W nowej wersji plik konfiguracyjny
jest plikiem lispowym wygenerowanym skryptem Perla z plików XML.
Jak to działa opisałem
na oddzielnej stronie.
Jedna sprawa jest tajemnicza:
#!/usr/bin/perl -w require 'login2flickr.rc'; require 'flickr_utils.rc'; my @tmpx = get_sets_ids(); my @tmpy = get_pools_ids();
W plikach login2flickr.rc
oraz flickr_utils.rc
są zdefiniowane
procedury, który czytają plik z dysku i zwracają zmienne. W szczególności
flickr_utils.rc
zawiera dwie prawie identyczne
procedury (get_sets_ids
oraz get_pools_ids
), czytające
różne pliki konfiguracyjne. Kurcze... na jednym komputerze perl zwraca błąd:
Undefined subroutine &main::get_pools_ids called at... a na drugim działa.
Ten sam perl, ta sama wersja FC5, jedna procedura z pliku dołączanego
poleceniem require
jest zdefiniowana druga nie...
Wystarczy zmienić kolejność poleceń require
żeby powyższe działało w obu systemach. Nic mi do głowy nie przychodzi...