Wprawdzie jestem/byłem sceptyczny co do rezultatów, ale postanowiłem sprawdzić empirycznie ile warte jest dodanie współrzędnych geograficznych przy wykorzystaniu techniki zsynchronizowania czasów GPSa i aparatu. Ustawiłem czas Geko na Paryż. To co odbiornik wyświetlał z grubsza się zgadzało z czasem na zegarku. No akurat wiem, że GPS z definicji może ,,robić'' za ultra dokładny zegarek. Z aparatem było gorzej--wyświetla tylko godziny i minuty. Ustawiłem czas na tyle dokładnie na ile się dało.

Po zapisaniu śladu do pliku GPX okazało się, że czas zapisany przez Geko jest circa godzinę do tyłu w porównaniu do tego co jest wyświetlane. Wyświetla czas lokalny a zapisuje UTC? Chyba tak, bo w dokumentacji skryptu GPSphoto jest o czymś takim wspomniane. Zdjęcie z kolei jest oznaczone czasem lokalnym i taki czas jest zapisywany. No i dodatkowo jest pewna różnica wynikająca z niezbyt precyzyjnego zgrania obu urządzeń. Prosty pomysł jak je zgrać dokładnie podano w dokumentacji GPSphoto: po prostu trzeba zrobić zdjęcie Geko z wyświetlonym na ekranie czasem. Faktycznie, prościej chyba się nie da:-) Ale nie do zastosowania w urządzeniach GPS bez ekranu (por. komentarz z tego bloga.)

Żeby sobie ułatwić skrypt zrobiłem wykorzystujący Image::ExifTool. Na wejściu pobiera nazwę pliku ze zdjęciem, a wypisuje zawartość pola DateTimeOriginal. Jeżeli podam -- jako drugi parametr -- czas w notacji gg:mm:ss, to skrypt wypisze też różnicę w sekundach:

exif_datetime.pl  -f dscf2451.jpg -b 15:49:20

Wyszło 44 sekundy. Dodałem 3600 sekund jako różnicę między czasem aparatu a czasem garmina, wpisując z wiersza poleceń:

perl gpsPhoto.pl --dir=jpgs --gpsfile=20071228.gpx --timeoffset=-3644 \
  --kml 20071228.kml

Szczerze mówiąc za pierwszym razem nie dodałem znaku minus przed wartością 3644. W rezultacie większość zdjęć została pominięta. Ale kilka zostało oznaczonych. Uruchomiłem gpsPhoto drugi raz, tym razem poszło lepiej. Powstały plik wyświetliłem w googleearth i konsternacja: część zdjęć jest oznaczona prawidłowo, ale kilka ma współrzędne kompletnie do kitu. Do tego ślad jak zwykle jest przerwany i ma jeden gigatyczny ,,odlot'' od prawdziwego przebiegu trasy. Najbardziej zdumiewało mnie jednak to, że zdjęcia na śladzie nie były wstawione chronologicznie, tylko przemieszane. Niechybnie oznaczało to, że coś namieszałem.

Straciłem sporo czasu kombinując czemu tak się stało. Wreszcie wróciłem do źródeł, czyli zacząłem studiować dokumentację gpsPhoto.pl. Dodałem opcję --overwrite-geotagged, słusznie mniemając, że skoro jest taka opcja, to geo-oznakowane pliki nie są domyślnie brane pod uwagę. Ostatecznie zatem uruchomiłem gpsPhoto w następujący sposób:

perl gpsPhoto.pl --dir=jpgs --gpsfile=20071228.gpx --timeoffset=-3644 \
  --overwrite-geotagged --kml 20071228.kml

Wynikowy plik 20071228.kml pokazuje, że współrzędne geograficze poszczególnych zdjęć są całkiem precyzyje. Tak się jednak stało, że w wszystkich miejscach gdzie robiłem zdjęcia garmin nie miał problemów z rejestrowaniem śladu. Zobaczymy jak będzie np. w lesie, albo w mieście, przy wysokich budowlach.

Reasumując, muszę odszczekać to co napisałem wcześniej no i być mniej sarkastyczny. Ślad z mojego pierwszego eksperymentu jest tutaj. Na razie nie ma na nim zaznaczonych zdjęć; są dostępne na flickr.com. Muszę też doczytać na temat formatu KML.

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...

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...