Copy settings from #1 unit
Connect unit via USB. Copy the files from the Settings
,
Elevations
, and Sports
folders. Copy the
Device.fit
file from the Garmin
folder.
Copy settings to #2 unit
Connect unit via GPS and copy the backup files into the same folders
on it. Put Device.fit
into Garmin
,
Settings.fit
into the Settings
folder,
Elevations.fit
into the Elevations
folder,
and Cycling.fit
into the Sports
folder.
All settings and menu configurations will now be available in #2 unit, saving you lots of time recreating them from scratch. Probably works with all Garmin Edge units (tested on 500 series).
Google fusion tables another excercise.
Two data sets describe football players who plays in Polish t-Mobile ekstraklasa (1st division) and Pierwsza Liga (2nd division) in 2011/2012 (autumn).
To show from where the player came a straight line is drawn from a player's birthplace to club's stadium, the player plays for.
Figure 1. 1st division.
Figure 2. 2nd division.
Players from 2nd division seems to be born closer to the clubs they play for:-)
Warning: in considerable number of cases the geocoding as performed by Google maybe wrong due to poor data quality--have no time to check/correct.
Yet another excercise, which tests Google Fusion Tables.
The data set contains--among other things--birth place for 600+ rugby players who last year take part in Rugby World Cup in New Zealand. The raw data is available here and here.
On the following diagram (cf. Figure 1) the players are mapped by column containing birthplace coordinates
Figure 1. World's concentration of top Rugby Union players.
The map do not show which player plays for which country. To show that a straight line is drawn from each player's birthplace to the country's capital, the player plays for (cf. Figure 2).
Figure 2. The origin of top Rugby Union players by federation.
Some lines look strange and the problem is particularly evident around New-Zealand-Samoa-Tonga-Fiji. For example it seems that many Samoan players were born at high ocean (cf. Figure 3).
Figure 3. The origin of top Rugby Union Samoan players.
BTW mapping Samoans one-by-one is OK (try it). The problem is when all rows are mapped together by Visualize→Map function.
Accidentaly around 600 miles to the East of New Zealand lies antipodal meridian ie. a meridian which is diametrically opposite the Greenwich meridian (a pime one). The longitude of points lying on antipodal meridian can be referenced (at least in GoogleMaps) both as -180° or 180° (ie. -36,-180° and -36,+180° refers to the same place). Perhaps it is the cause of observed errors...
Wprawdzie Sejm RP szybkimi krokami zmierza w stronę wybranego w 1936 r. Reichstagu określanego jako ,,najlepiej opłacany męski chór ma świecie'' (The best paid male chorus in the world -- określenie użyte podobno w amerykańskim czasopiśmie The Literary Digest) i być może już w kadencji ósmej ten stan ideału zostanie osiągnięty. Ale zanim to nastąpi zbierzmy dane dotyczące posłów wybranych do Sejmu 7 kadencji.
Zaczynam od ściągnięcia listy stron bibliograficznych posłów:
## Najpierw zestawienie posłów: wget -U XX http://www.sejm.gov.pl/sejm7.nsf/poslowie.xsp?type=A -O lista-poslow.html ## Potem dla każdego posła z zestawiena: cat lista-poslow.html | perl -e ' undef $/; $_ = <>; s/\n/ /g; while ($_ =~ m@href="/sejm7.nsf/posel.xsp\?id=([0-9]+)\&type=A@g ) { $id = $1; ## id posła $pos = "http://www.sejm.gov.pl//sejm7.nsf/posel.xsp?id=$id&type=A"; print STDERR $pos, "\n"; system ('wget', '-U', 'XXX', "-O", "7_$id.html", $pos); sleep 3; ## --let's be a little polite-- }
Powyższe pobiera 460 stron, każda zawierająca biografię jakiegoś posła.
Z kolei poniższy skrypt wydłubuje co trzeba (data scraping) ze strony zawierających biografię pojedynczego posła (np. tego).
#!/usr/bin/perl # use Storable; use Google::GeoCoder::Smart; $geo = Google::GeoCoder::Smart->new(); # Domyślny kraj my $GeoCodeCacheName = 'geocode.cache'; my $NewCoordinatesFetched=0; # global flag my $kraj = 'Polska'; my $SLEEP_TIME = 3 ; # Rok wyborów my $baseyr = 2011; my ($data_day, $data_mc, $data_yr); undef $/; $_ = <>; s/\n/ /g; # Retrieve geocode cash (if exists) # http://curiousprogrammer.wordpress.com/2011/05/11/faking-image-based-programming-in-perl/ my %hash = %{ retrieve("$GeoCodeCacheName") } if ( -f "$GeoCodeCacheName" ) ; if (m@<h2>([^<>]+)</h2>@) { $posel = recode($1); } # zgadnij płeć patrząc na imię (jeżeli kończy się na a->kobieta): my @tmp_posel = split " ", $posel; if ( $tmp_posel[0] =~ m/a$/ ) { $sex='K' } else { $sex='M' } # id posła: if (m@http://www.sejm.gov.pl/sejm7.nsf/posel.xsp\?id=([0-9]+)@) {$id = $1; } # liczba oddanych na posła głosów: if (m@<p class="left">Liczba g\łos\ów:</p>[ \n\t]*<p class="right">([^<>]+)</p>@) { $glosy = $1 ; } # Data i miejsce urodzenia:</p><p class="right">29-06-1960<span>, </span>Gdańsk</p> if (m@Data i miejsce urodzenia:[ \n\t]*</p>[ \n\t]*<p class="right">([0-9\-]+)<span>,[ \n\t]*\ [ \n\t]*</span>([^<>]+)</p>@ ) { $data = recode ($1); ($data_day, $data_mc, $data_yr) = split "-", $data; ##print STDERR "R/M/D: $data_day, $data_mc, $data_yr\n"; $mce = recode ($2); } # Zawód: if (m@<p class="left">Zaw\ód:</p>[ \nt]*<p class="right">([^<>]+)</p>@ ) { $zawod = recode($1) ; } if (m@klub.xsp\?klub=([^"<>]+)@ ) { $klub = recode($1); } # Klub poselski: if (m@Okr\ęg wyborczy:</p>[ \t\n]*<p class="right">([^<>]+)</p>@) { $okr = recode($1); ## Pierwszy wyraz to numer okręgu, reszta nazwa (może być wielowyrazowa) ($okrnr, $okrnz) = $okr =~ m/([^ \n\t]+)[ \n\t]+(.+)/; ## -- sprawdzić czy działa -- } # Poprawienie błędów if ($mce =~ /Ostrowiec Świetokrzyski/) {$mce = 'Ostrowiec Świętokrzyski' } elsif ($mce =~ /Stargard Szaczeciński/) {$mce = 'Stargard Szczeciński' ; } elsif ($mce =~ /Białograd/ ) {$mce = 'Białogard'; } elsif ($mce=~ /Szwajcaria/) {$mce = 'Szwajcaria,Suwałki' } elsif ($mce=~ /Kocierz Rydzwałdzki/) { $mce= "Kocierz Rychwałdzki" } elsif ($mce=~ /Stąporów/) { $mce= "Stąporków" } elsif ($mce=~ /Szmotuły/) { $mce= "Szamotuły" } # Wyjątki: if ($posel=~ /Arkady Fiedler/ ) {$kraj = 'Wielka Brytania' } elsif ($posel=~ /Vincent-Rostowski/) {$kraj = 'Wielka Brytania' } elsif ($mce=~ /Umuahia/) {$kraj = 'Nigeria' } elsif ($posel=~ /Munyama/) {$kraj ='Zambia'; } ## Imię kończy się na `A' ale to facet: elsif ($posel=~ /Kosma Złotowski/ ) {$sex = "M"} # Sprawdź czy data jest zawsze w formacie dd-mm-yyyy: if ($data_yr < 1900) { print STDERR "*** $data_yr: $data for $posel ($id)\n"; } # geokodowanie (uwaga na limit) my $coords = addr2coords($mce); my $wiek = $baseyr - $data_yr; my $coords_okr = addr2coords($okrnz, 'r'); ($tmp_lat, $tmp_lng) = split " ", $coords; my $kml_line = "<LineString><coordinates>$tmp_lng,$tmp_lat $coords_okr</coordinates></LineString>"; print STDERR "$id : $sex : $posel : $wiek\n"; print "$id;$sex;$posel;$data;$wiek;$mce,$kraj;$coords;$klub;$glosy;$zawod;$okrnr;$okrnz;$kml_line\n"; ## Retrieve geocode cash if ($NewCoordinatesFetched) { store(\%hash, "$GeoCodeCacheName"); } ## ## ## ## ## ## sub recode { my $s = shift; $s =~ s/\ / /g; $s =~ s/\ł/ł/g; $s =~ s/\ó/ó/g; $s =~ s/\ń/ń/g; $s =~ s/\Ł/Ł/g; $s =~ s/\ź/ź/g; $s =~ s/\ż/ż/g; $s =~ s/\Ś/Ś/g; $s =~ s/\Ż/Ż/g; $s =~ s/\ę/ę/g; $s =~ s/\ą/ą/g; $s =~ s/\ś/ś/g; $s =~ s/\ć/ć/g; $s =~ s/[ \t\n]+/ /g; return $s; } ## ## ## ## ## ## sub addr2coords { my $a = shift ; my $r = shift || 'n'; my ($lat, $lng) ; ##consult cache first if (exists $GeoCodeCache{"$a"} ) { ($lat,$lng) = split (" ", $GeoCodeCache{"$a"} ); } else { my ($resultnum, $error, @results, $returncontent) = $geo->geocode("address" => "$a"); $resultnum--; $resultNo=$resultnum ; if (resultNo > 0) { print STDERR "** Location $a occured more than once! **" } if ($error eq 'OK') { $NewCoordinatesFetched=1; for $num(0 .. $resultnum) { $lat = $results[$num]{geometry}{location}{lat}; $lng = $results[$num]{geometry}{location}{lng}; ##print "*** LAT/LNG:$lat $lng ERROR: $error RES: $resultNo ***\n"; } } else { print STDERR "** Location $a not found! due to $error **" } } $GeoCodeCache{"$a"} = "$lat $lng"; ## store in cache sleep $SLEEP_TIME; if ($r eq 'r' ) { return "$lng,$lat"; } # w formacie KML else { return "$lat $lng"; } }
Skrypt wydłubuje id posła (id), imię i nazwisko (imnz), datę urodzenia (data_ur),
miejsce urodzenia (mce_ur), skrót nazwy partii do której należy (partia),
liczbę oddanych na niego głosów (log), zawód (zawod),
numer okręgu wyborczego (nrokregu) i nazwę okręgu (nzokregu). Do tego
zgadywana jest płeć posłanki/posła oraz obliczany jest wiek w chwili wyboru jako $baseyr - $data_yr
, gdzie
$data_yr
to rok urodzenia.
Miejsce urodzenia oraz nazwa okręgu są geokodowane. Współrzędne miejsca urodzenia są zapisywane jako zmienna wsp. Jako zmienna odleglosc zapisywana jest linia definiowana (w formacie KML) jako: współrzędne miejsce urodzenia--współrzędne okręgu wyborczego.
<LineString><coordinates>lng1,lat1 lng2,lat2</coordinates></LineString>
Zamiana kupy śmiecia (tj. wszystkich 460 plików HTML) na plik CSV zawierający wyżej opisane dane sprowadza się teraz do wykonania:
for i in 7_*html ; do perl extract.pl $i >> lista_poslow_7_kadencji.csv ; done
Jako ciekawostkę można zauważyć, że strony sejmowe zawierają 6 oczywistych błędów: Ostrowiec Świetokrzyski, Stargard Szaczeciński, Białograd, Kocierz Rydzwałdzki, Stąporów oraz Szmotuły. Ponadto wieś Szwajcaria k. Suwałk wymagała doprecyzowania. Czterech posłów urodziło się za granicą a pan Kosma jest mężczyzną i prosta reguła: jeżeli pierwsze imię kończy się na ,,a'' to poseł jest kobietą zawiodła.
Ostatecznie wynik konwersji wygląda jakoś tak (cały plik jest tutaj):
id;plec;imnz;dat_ur;wiek;mce_ur;wsp;partia;log;zawod;nrokregu;nzokregu;odleglosc 001;M;Adam Abramowicz;10-03-1961;50;Biała Podlaska,Polska;52.0324265 23.1164689;PiS;\ 12708;przedsiębiorca;7;Chełm;<LineString><coordinates>23.1164689,52.0324265 23.4711986,51.1431232</coordinates></LineString> ...
Teraz importuję plik jako arkusz kalkulacyjny do GoogleDocs, a następnie, na podstawie tego arkusza tworzę dokument typu FusionTable. Po wizualizacji na mapie widać parę problemów -- ktoś się urodził niespodziewanie w USA a ktoś inny za Moskwą. Na szczęście takich omyłek jest tylko kilka...
Geocoder nie poradził sobie z miejscowościami: Model/prem. Pawlak, Jarosław/posłowie: Kulesza/Golba/Kasprzak, Orla/Eugeniusz Czykwin, Koło/Roman Kotliński, Lipnica/J. Borkowski, Tarnów/A. Grad. We wszystkich przypadkach odnajdywane były miejsca poza Polską -- przykładowo Orly/k Paryża zamiast Orli. Ponadto pani poseł Józefa Hrynkiewicz została prawidłowo odnaleziona w Daniuszewie ale się okazało, że ta miejscowość leży na Białorusi a nie w Polsce. Też ręcznie poprawiłem...
Ewidentnie moduł Google::GeoCoder::Smart
ustawia
geocoder w trybie partial match, w którym to
trybie Google
intelligently handles incomplete input aka stara się być mądrzejszym od pytającego.
Może w trybie full match byłoby lepiej, ale to by wymagało doczytania.
Na dziś, po prostu poprawiłem ręcznie te kilka ewidentnie błędnych przypadków.
Po poprawkach wszystko -- przynajmniej na pierwszy rzut -- oka wygląda OK
Link do tabeli jest zaś tutaj.
Nawiasem mówiąc kodowanie
dokumentów na stronach www.sejm.gov.pl
jest co najmniej dziwaczne.
Klasyczny zbiór danych pn. niemieckie łodzie podwodne z 2WWŚ wg. typu, liczby patroli, zatopionych statków i okrętów oraz -- dodane dziś -- miejsca zatopienia (źródło: www.uboat.net). W zbiorze są 1152 okręty (pomięto 14, które były eksploatowane przez Kriegsmarine ale nie były konstrukcjami niemieckimi), z tego 778 ma określoną pozycję, na której zostały zatopione (z czego kilkadziesiąt w ramach operacji DeadLight). Można zatem powiedzieć, że dane dotyczące miejsca zatopienia/zniszczenia są w miarę kompletne, bo np. Kemp (1997) podaje liczbę 784 U-bootów zniszczonych w czasie 2WWŚ (dane są różne w zależności od źródła.)
Jeżeli U-boot zaginął/przepadł bez wieści/został zniszczony, ale nie wiadomo dokładnie gdzie, to nie występuje na mapie. Operacja DeadLight to ta wielka kupa kropek ,,nad'' Irlandią....
Link do danych/mapy na serwerze Google jest tutaj.
Dane były tylko zgrubie weryfikowane, więc mogą zawierać błędy (ale ,,na oko'' jest ich niewiele)...
Kemp Paul, U-Boats Destroyed: German Submarine Losses in World Wars, US Naval Institute Press, 1997 (isbn: 1557508593)
Pod tym adresem umieściłem moje ślady GPS (głównie rowerowe) z lat 2010--2012. W formacie KML bo to jedyny -- z tego co mi się wydaje -- obsługiwany przez Google Fusion Tables (GFT).
Moja procedura skopiowania danych z urządzenia GPS (zwykle jest to Garmin Legend) do GFT jest następująca:
Skryptem obsługującym program
gpsbabel
pobieram dane z urządzenia GPS do pliku w formacie GPX.
Skryptem kml2kml.sh
zamieniam plik GPX otrzymany w pierwszym kroku
na plik w formacie KML. Ponieważ plik ten jest ogromy (przykładowo z 60 kilowego pliku GPX
gpsbabel wygenerował plik o wielkości ponad 500 kb) zostaje on za pomocą
trywialnego arkusza XSLT zamieniony na znacznie mniejszą wersję uproszczoną:
#!/bin/bash # KMLSTYLE=~/share/xml/kml2kml.xsl # # Domyslna liczba punktow na sladzie COUNT=99 ## Domyslna nazwa Placemarka NAME=`date +%Y%m%d_%H`; while test $# -gt 0; do case "$1" in -name) shift; NAME="$1";; -name*) NAME="`echo :$1 | sed 's/^:-name//'`";; -max) shift; COUNT="$1";; -max*) COUNT="`echo :$1 | sed 's/^:-max//'`";; *) FILE="$1";; esac shift done ## Usun rozszerzenie z nazwy pliku wejsciowego OUT_FILE="${FILE%.*}" TMP_FILE=/tmp/${OUT_FILE}.kml.tmp echo "Converting $FILE to ${TMP_FILE}..." if [ -f $FILE ] ; then ## Konwersja GPX->KML gpsbabel -i gpx -f $FILE -x simplify,count=$COUNT -o kml -F $TMP_FILE else echo "*** ERROR *** File $FILE not found.... ***" ; exit fi ## Konwersja do uproszczonego KMLa (KML->KML) echo "Converting $TMP_FILE to ${OUT_FILE}.kml with maximum $COUNT points..." echo "KML' Placemark name is: $NAME..." xsltproc --stringparam FileName "$NAME" -o ${OUT_FILE}.kml $KMLSTYLE $TMP_FILE echo "Done..."
Zawartość arkusza XSLT zamieszczono na końcu tej notki.
Do interakcji z Fusion Tables wykorzystam zmodyfikowany skrypt (nazwany ftquery.sh
)
znaleziony na stronach
code.google.com:
#!/bin/bash # # Copyright 2011 Google Inc. All Rights Reserved. # Author: arl@google.com (Anno Langen) # http://code.google.com/intl/pl/apis/fusiontables/docs/samples/curl.html # -- Modified by TP -- MY_QUERY=$* function ClientLogin() { password='?1234567890?' email='looseheadprop1@gmail.com' local service=$1 curl -s -d Email=$email -d Passwd=$password -d \ service=$service https://www.google.com/accounts/ClientLogin | tr ' ' \n | grep Auth= | sed -e 's/Auth=//' } function FusionTableQuery() { local sql=$1 curl -L -s -H "Authorization: GoogleLogin auth=$(ClientLogin fusiontables)" \ --data-urlencode sql="$sql" https://www.google.com/fusiontables/api/query } FusionTableQuery "$MY_QUERY"
Teraz tworzę nową tabelę (wyklikowując co trzeba w przeglądarce) MyTracks
o następującej strukturze:
## Korzystamy z skryptu ftquery.sh ./ftquery.sh SHOW TABLES table id,name 2590817,MyTracks ## Tabela MyTracks ma zatem id=2590817 ./ftquery.sh DESCRIBE 2590817 column id,name,type col4,Date,string col0,Start,string col1,Stop,string col2,Location,location col3,Description,string
Kolumny zawierają odpowiednio: datę (Date
), czas
pierwszego
wpisu na śladzie GPX (Start
), czas ostatniego wpisu na
śladzie GPX (Stop
), ślad (Location
) oraz opis (Description
).
Kolumny Tabeli w Google Fusin Tables mogą być albo napisami (STRING
),
liczbami (NUMBER
), zawierać dane przestrzenne (LOCATION
) albo czas (DATETIME
).
Wstępne eksperymenty
z typem DATETIME
wskazują,
że jest z nim jakiś problem.
Primo
format czasu jest dość dziwaczny (np. gpsbabelowy zapis: 2012-01-07T09:19:47Z
nie jest rozpoznawany).
Także późniejsze filtrowanie w oparciu
o kolumnę DATETIME
też jakoś nie wychodzi, nawet jak zapisałem
datę w formacie YYY.MM.DD
,
który wg. dokumentacji
powinien być rozpoznawany.
Nie badając sprawy dogłębnie, zmieniłem po prostu
typ kolumn Date
, Start
, Stop
na STRING
.
Cytując za dokumentacją GFT: In a column of type LOCATION, the value can be a string containing an address, city name, country name, or latitude/longitude pair. The string can also use KML code to specify a point, line, or polygon... (cf. SQL API: Reference ). Zatem żeby wstawić linię śladu wystarczy przesłać napis zawierający współrzędne opakowane w następujący sposób:
<lineString><coordinates>lng,lat[,alt] lng,lat[,alt]...<coordinates></lineString>
Do tego służy następujący skrypt:
#!/bin/bash # STYLE=~/share/xml/gpxtimestamp.xsl MYTRACKS_TABLE_ID="2590817" GPX_FILE=$1 KML_FILE="${GPX_FILE%.*}".kml ## Ustal czas od--do sladu STARTTIME=`xsltproc --param Position '"First"' $STYLE $GPX_FILE` STOPTIME=`xsltproc --param Position '"Last"' $STYLE $GPX_FILE` DATE=`xsltproc --param Position '"First"' --param Mode '"Date"' $STYLE $GPX_FILE` if [ ! -f $GPX_FILE ] ; then echo "*** Error *** No GPX file: $GPX_FILE" ; exit ; fi if [ ! -f $KML_FILE ] ; then echo "*** Error *** No KML file: $KML_FILE" ; exit ; fi ## ## Wycinamy nastepujacym skryptem z uproszczonego pliku KML: TRACK=`perl -e 'undef $/; $t = <>; $t =~ m/(<coordinates>.*<\/coordinates>)/s; \ $t = $1; $t =~ s/[ \t\n]+/ /gm; print $t;' $KML_FILE` TRACK="<LineString>$TRACK</LineString>" ftquery.sh "INSERT INTO $MYTRACKS_TABLE_ID (Date, Start, Stop, Location, Description) VALUES ('$DATE', '$STARTTIME', '$STOPTIME', '$TRACK', '') "
I działa, tj. przesyła co trzeba na moje konto Google.
Google się chwali, że GFT radzi sobie z ogromnymi zbiorami danych. Mój ma -- na tem chwilem -- ponad 150 wierszy, a w każdym 99 punktów na śladzie, co daje łącznie approx 15,000 punktów do wykreślenia. Firefox/Opera coś tam wyświetla ale niewiele widać. Chrome radzi sobie najlepiej -- faktycznie da się to obejrzeć, przesuwać, powiększać... Wprawdzie nic z tych danych nie wynika, ale to już nie jest pytanie do Google.
Także filtr w połączeniu z mapą działa w Firefoksie i Operze tak sobie.
Wybieram zbiór tras,
np. za pomocą warunku Date < 20100901
(na tem chwilem jest to 7 wierszy)
następnie klikam Visualise Map i guzik -- nic nie widać.
Ale znowu w Chrome jest znacznie lepiej.
Dowód w postaci zrzutu ekranu obok.
Także wklejony poniżej link do mapy (pobrany
przez kliknięcie w guzik Get embeddable link) daje pozytywny wynik:
Przynajmniej w mojej wersji FF (8.0).
Zamiana pliku KML na uproszczony plik KML:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:kml="http://www.opengis.net/kml/2.2" > <xsl:output method="xml"/> <xsl:param name='FileName' select="'??????'"/> <xsl:template match="/"> <kml xmlns="http://www.opengis.net/kml/2.2" xmlns:gx="http://www.google.com/kml/ext/2.2"> <Document> <Placemark> <name><xsl:value-of select="$FileName"/></name> <MultiGeometry><LineString> <tessellate>1</tessellate> <coordinates> <xsl:for-each select="//kml:Placemark//kml:LineString"> <xsl:value-of select="kml:coordinates"/> </xsl:for-each> </coordinates></LineString></MultiGeometry></Placemark> </Document></kml> </xsl:template> </xsl:stylesheet>
Wydrukowanie daty/czasu z pliku w formacie GPX:
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:gpx="http://www.topografix.com/GPX/1/0"> <xsl:output method="text"/> <xsl:param name='Position' select="'First'"/> <xsl:param name='Mode' select="'Time'"/> <xsl:template match="/" > <xsl:for-each select='//*[local-name()="trkpt"]'> <xsl:choose> <xsl:when test="position()=1 and $Position='First' and $Mode='Time'"> <xsl:value-of select='substring(*[local-name()="time"], 12, 8)'/> <xsl:text> </xsl:text> </xsl:when> <xsl:when test="position()=1 and $Position='First' and $Mode='Date'"> <xsl:value-of select='translate(substring(*[local-name()="time"], 1, 10), "-", "")'/> <xsl:text> </xsl:text> </xsl:when> <xsl:when test="position()=last() and $Position='Last'"> <xsl:value-of select='substring(*[local-name()="time"], 12, 8)'/> <xsl:text> </xsl:text> </xsl:when> </xsl:choose> </xsl:for-each> </xsl:template> </xsl:stylesheet>
W nawiązaniu do poprzedniego wpisu.
Zachęcony relacjami Szlakiem kamieni i dworów..., Słupki graniczne WMG, i Węgry-kamienie graniczne WMG też się wybrałem obejrzeć ww. słupy graniczne d. Wolnego Miasta Gdańska.
Plany miałem ambitne: chciałem odnaleźć kamienie 7--21 k. Węgier plus 1--5 niedaleko Białej Góry. Najpierw ustaliłem ich położenie posługując się mapą i metodą opisaną w poprzednim wpisie. Rezultat jest tutaj (niebieska trasa/zielone pinezki). Wyznaczyłem też trasę (używając Gmaps pedometer) rozpoczynającą i kończącą się Tczewie.
Jak zwykle nie poszło zgodnie z planem. Planowo to było do Gościszewa. Później zjechałem z trasy i nie w tym miejscu dojechałem do Nogatu. W ,,normalnym'' terenie nie miałoby to większego znaczenia ale marsz (z rowerem -- do momentu, w którym stwierdziłem, że to nie ma sensu) po brzegu Nogatu naprzeciwko Pogorzałej Wsi okazał się niezwykle uciążliwy: bardzo stroma skarpa i mnóstwo powalonych gałęzi i przeszkadzających krzaków. Straciłem dużo czasu zanim dotarłem do słupka nr 7. GPS wskazywał jego pozycję z dokładnością do 30 m. Podobnie było ze słupem nr. 8, który też odnalazłem bez problemów. Pozostałem słupki odpuściłem wobec znaczącego obsuwu czasowego w stosunku do planowanego harmonogramu no i miałem już serdecznie dość łażenia po krzakach.
Kierując się na Białą Górę znowu fatalnie pomyliłem drogę. Do tego, to co na mapie jest drogą publiczną w tzw. realu okazało się drogą nawet nie szutrową a piaszczystą. W wielu miejscach nie szło jechać i trzeba było iść... Teren trzeba przyznać odludny i dziki. Ale żeby nie było idealnie to: tutaj i tutaj smrodzą (to drugie wygląda na mieszalnie pasz lub cóś w tym stylu)...
W związku z obsuwem czasowym słupki 1--5 także odłożyłem na później i z Białej Góry pojechałem bez zatrzymywania się (pod zimy i przeciwny wiatr) do Tczewa.
Trasa jest tutaj.
Zielone pinezki to słupki graniczne wg mapy 2079_Wernersdorf_1939.jpg
ustalone
za pomocą procedury opisanej w poprzednim wpisie.
Czerwone to miejsce zrobienia zdjęcia...
PS: jeżeli planuje się podróż PKP z rowerem
nie należy klikać na rozkładzie w pole `Przewóz rowerów', bo wtedy wyświetlona
zostanie tylko część pociągów, którymi można jechać z rowerem.
Np. pociągi osobowe (zwykle/zawsze? składy typu EN57)
Przewozów Regionalnych z definicji zabierają rower a wg. rozkładu nie.
Rozkład rozklad-pkp.pl
nie uwzględnia też połączeń SKM (a SKM kursuje m-dzy Tczewem a Słupskiem).
PS2: moja trasa jest w okolicach Parpar delikatnie mówiąc do kitu... Teraz już nawet nie wiem dlaczego tak to sobie ,,zaplanowałem''...
No maps or advanced features are supported but thanks to 1 inch display screen it can shows direction (electronic compass) and distance to up to 5 different targets. Targets (POIs) can be marked, manually entered or uploaded with appropriate software. (IMHO manual entry of POI requires at least Kristian Zimerman's fingers---for mere human it is simply impossible to remember and perform all key clicks in appropriate sequence...)
The producer recommends
ntrip
Travel Management Shareware.
Two main features of ntrip
are:
-- importing logged GPS data,
-- setting up to 5 locations by clicking them on the Google map.
Ntrip
is Windows only (perhaps it works with wine---I didn't try)
shareware and the license fee is 20 USD.
Brand new minihomer has logging capability disabled. On first
connection to ntrip
it is enabled.
One can stop/start logging manually with mark key.
As I do not use MSW (MS Windows) and don't like shareware applications
I have been searching for some free replacement for ntrip
starting
with an obvious one, namely gpsbabel.
Latest version of Gpsbabel (1.4.2) supports skytraq venus based loggers (Venus 5 and 6; for 130 PLN at allegro.pl) but the support for minihomer is limited to dowloading the GPS tracks only:
gpsbabel -i skytraq -f /dev/ttyUSB0 -o gpx -F out.gpx ## if the above do not works thy add baud=0 ; erase clears all device's memory gpsbabel -i skytraq,erase,baud=0 -f /dev/ttyUSB0 -o gpx -F out.gpx
Alternatively one can use skytraq-datalogger:
## get information about software version and configuration skytraq-datalogger --info --device /dev/ttyS0 ## change configuration of the data logger (do not works with miniHomer): skytraq-datalogger --enable-log --set-config ## dumping memory in GPX (works): skytraq-datalogger --dump > out.gpx
Finally a guy called Josef Reisinger adds Minihomer support to gpsbabel but it has not been integrated (yet?) to official distribution. However the `hacked' gpsbabel can be dowloaded from www.ohloh.net:
cvs -d :pserver:anonymous:@gpsbabel.cvs.sourceforge.net:/cvsroot/gpsbabel co gpsbabel cd gpsbabel ./configure make ## change gpsbabel to something else: mv gpsbabel gpsbabel_minihomer
To set location for ``Home'' icon one can issue a command similar to the following example:
## =55.44:18.55:45 is latitute:longitude:altitude ; altitude is optional ## -o gpx -F out.haha is suprefluous, perhaps -F - will suffice: gpsbabel_minihomer -i minihomer,Home=55.44:18.55:45 -f /dev/ttyUSB0 -o gpx -F out.haha
Other icons include ``Car'', ``Boat'', ``Heart'' and ``Bar''. The track can be dowloaded
as with ordinary version of gpsbabel of course.
It seems to be impossible to configure the
device however (disabling/enabling logging, setting logging period etc...) so enabling logging
can be done---as far as I know---with ntrip
only.
Dopisane 24 marca 2011: Się okazało, że połączenie gpsbabel/minihomer jest straszliwie zależne od użytego kabla USB. Kto by pomyślał. Mi działa z kablem oznaczonym jako Belkin Pro Series USB 2.0 [...] E237114 CSA 219561 Z innymi nie działa... Trudno powiedzieć czy to jest oryginalny dołączony do urządzenia, bo różnych kabelków USB mam już z kilkanaście...
Dopisane 28 marca 2011: Ponieważ ciągle nie działa poprawnie wykonałem następujące testy:
## działa: gpsbabel -i skytraq,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110326.gpx ## nie działa: gpsbabel -i skytraq,erase,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110326-e.gpx skytraq: Can't find skytraq device on '/dev/ttyUSB0' ## jeszcze raz polecenie nr1 teraz też nie działa: gpsbabel -i skytraq,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110326p.gpx skytraq: Can't find skytraq device on '/dev/ttyUSB0' ## wyjęcie USB/wsadzenie, powtórka, działa: gpsbabel -i skytraq,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110326p.gpx ## i jeszcze raz, działa: gpsbabel -i skytraq,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110326pp.gpx ## teraz próba zmodyfikowanym babelem: miniHomer_gpsbabel -i minihomer,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110324m.gpx skytraq: Can't find skytraq device on '/dev/ttyUSB0' ## wyjęcie USB/wsadzenie: miniHomer_gpsbabel -i minihomer,baud=0 -f /dev/ttyUSB0 -o gpx -F 20110324m.gpx Naruszenie ochrony pamięci ## ## działa natomiast: miniHomer_gpsbabel -i minihomer,Bar=55.44:18.55:45 -f /dev/ttyUSB0 -o gpx -F -
Reasumując ślad można zgrywać ,,klasycznym'' babelem. Zmodyfikowany ma coś
spieprzone, ale działa w trybie ustawiania POI, czego nie potrafi ,,klasyczny'' z kolei.
Żaden nie obsługuje polecenia erase
.
To nie jest wszakże aż tak wielki problem bo pamięć po zapełnieniu jest nadpisywana (chyba:-).
Poza tym w komputerze kol. B. nie działało w ogóle.
Pomogło wpisanie w google frazy:
gpsbabel+hangs
.
Należy wykonać przed uruchomieniem
gpsbabela [ale po podłączeniu urządzenia] następujące tajemnicze polecenie:
stty -F /dev/ttyUSB0 clocal
co jest opisane tutaj albo tutaj. Z opisu zaś wynika, że błąd dotyczy nowych wersji Ubuntu lub nawet kernela per se (nie chciało mi się czytać, bo ja mam ciągle Fedorę acht i jest OK!).
Intensywne używanie http://www.gmap-pedometer.com/ spowodowało, iż dotarłem do granic możliwości Legenda, o których NB. do niedawna nie miałem pojęcia. Otóż Legend może przechować do 1000 punktów (waypoints), 20 śladów (tracks) oraz do 50 tras (routes), każda o długości do 250 punktów... Ponieważ punkty trasy liczą się do puli punktów, 5 tras 200 punktowych zawala pamięć ,,na amen''. Co zresztą niedawno miało miejsce...
Usunięcie wszystkich punktów i wszystkich tras z Garmina jest bardzo łatwe. Tyle, że chciałbym niektóre zachować... Można wprawdzie usuwać punkty według związanych z nimi symboli, ale to by wymagało porządku przy ich definiowaniu. A ja, póki co, mam w tym względzie bałagan. Zatem:
Zgrałem zawartość pamięci Garmina do pliku. Wywaliłem wszystkie trasy i ślady oraz związane z nimi punkty (są one łatwo rozpoznawalne po nic nie mówiącej nazwie typu Turn 233 albo GRTP-202). Pozostawiłem pozostałe punkty. (Wywalając trasy trzeba usunąć wszystkie, bo nie wiadomo jaki punkt należy do jakiej trasy -- tak jest szybciej i prościej.)
Wyczyściłem pamięć urządzenia. W tym celu w menu głównym należy wybrać ikonę Waypoints→przycisk menu/find→Delete. Teraz wybrać All Symbols i potwierdzić. Uwaga: przycisk menu/find jest po lewej na dole pod przyciskami góra/dół.
Załadowałem z powrotem plik GPX (nazwałem go LEGEND_MEM.gpx
):
gpsbabel -r -w -t -i gpx -f LEGEND_MEM.gpx -o garmin -F /dev/ttyUSB0
Plik LEGEND_MEM.gpx
zawiera moją bazę podstawowych punktów i tras (jeżeli takowe są)...
Resztę będę ładował w miarę potrzeby, a jak się znowu zapełni pamięć
Legenda, to powtórzę opisaną wyżej procedurę... Przy okazji 225 jako górny limit
punktów na trasie wygląda na zbyt dużo.
Spróbuję 100 punktów, wtedy zmieści się więcej tras....
Trasy z google maps zaimportowane do odbiornika GPS są do kitu...
Są zbyt proste
i bez Gmapy sprowadzają się do linii prostej, łamanej w kilku miejscach.
Dużo lepsze efekty daje
http://www.gmap-pedometer.com/.
Należy także zainstalować
bookmarklet
GMapToGPX, który
-- przynajmniej w Firefoksie -- pojawi się jako guzik na pasku
zakładek. Trasę należy wyklikać, a jak już jest gotowa
trzeba nacisnąć GMapToGPX
. W oddzielnym oknie zostanie
wyświetlony dokument GPX,
który metodą copy-paste wkleja się do pliku.
Teraz należy załadować
trasę -- w przypadku mojego Legenda HCx, gpsbabela i FC8, wygląda to następująco:
gpsbabel -r -i gpx -f plik.gpx -o garmin -x simplify,count=225 -F /dev/ttyUSB0
Ważny jest filtr -x simplify,count=225
, bo trasy muszą być krótsze od 250
punktów albo zostaną ucięte (co urządzenie zasygnalizuje
komunikatem Route Truncated). Dałem limit 225
mogłem 250... być może należy dać jeszcze mniej żeby Garmin nie piszczał non-stop.
Powyższe w praktyce sprawdziło się całkiem całkiem... Przykładowo moja trasa do Gdyni-Oksywia, naokoło przez las. (Na czerwono planowana na niebiesko zrealizowana.) W miejscu gdzie chciałem pojechać wzdłuż Estakady Kwiatkowskiego się okazało, że nie da rady (rura ciepłownicza); na GoogleMaps była tam zaznaczona ścieżka stąd takie nierealistyczne plany.
MapSource firmy Garmin to aplikacja dodawana do każdego odbiornika
zdolnego do korzystania z map. Nie ma wersji dla Linuksa, ale działa
z emulatorem wine
,
tyle że przeraźliwie wolno (każda zmiana skali,
czy obszaru mapy oznacza czekanie).
Zresztą, być może w MSW jest podobnie -- nie sprawdzałem...
Ponieważ ja wykorzystuję MapSource praktycznie wyłącznie do załadowania mapy do urządzenia, powolność działania aż tak bardzo nie przeszkadza. Zatem...
Należy zainstalować MapSource z płyty dostarczonej z urządzeniem. Podłączyć urządzenie kablem USB i sprawdzić czy Linuks go widzi:
$ /sbin/lsusb Bus 005 Device 003: ID 091e:0003 Garmin International GPSmap (various models)
Można też sprawdzić czy Linuks załadował stosowny moduł:
$ /sbin/lsmod | grep garmin garmin_gps 18885 0 usbserial 30249 1 garmin_gps garmin_gps
Jeżeli w powyższych dwóch krokach coś jest nie tak, no to jest problem... Ale u mnie jest OK. Teraz uruchamiamy MapSource:
wine "/home/tomek/.wine/drive_c/Garmin/MapSource.exe"
Jak MapSource nie widzi urządzenia, to trzeba wykonać jeszcze polecenie:
ln -s /dev/ttyUSB0 ~/.wine/dosdevices/com1
Teraz MapSource w mojej Fedorze działa. W Windows XP jak zwykle nie... Pewnie tzw. problem brakujących sterowników.
W opisie tzw. waypointa (punkt nawigacyjny),
w formacie GPX jest m.in. znacznik <sym>
, którego
zawartością jest napis określający symbol punktu. Do tej pory zawsze wstawiałem tam Flag,
a Legend oznaczał taki punkt ikoną niebieskiej flagi.
Wprawdzie teoretycznie to (chyba) może być dowolny napis, ale lepiej ograniczyć się do
tych kilkanastu--kilkudziesięciu, które Garmin zna i ,,reaguje'' na nie
podstawiając odpowiednią ikonę.
Zestaw tychże znalazłem
tutaj. Na stronach
Garmina zaś trudno się doszukać stosownej informacji.
Przykładowo pierwszy z punktów (poniżej) to cmentarz a drugi Miejsce Polowania wybrany na oznaczanie ,,grzybowych miejscówek'' -- ponieważ w zestawie symboli nie ma takiego, który by się lepiej nadawał na oznaczenie miejsca ,,gdzie rosną grzyby''
<wpt lat="54.0704694444" lon="18.9803833333"> <name>Stogi k/M Cment</name> <cmt>Stogi k/M Cment</cmt> <desc>Stogi k/Malborka Cmentarz Mennonitów</desc> <sym>Cemetery</sym> </wpt> <wpt lat='54.84425261' lon='18.000581109'> <name>Boczniak1</name> <cmt>Boczniak Ostrygowaty</cmt> <desc>Boczniak Ostrygowaty na pniu buka</desc> <sym>Hunting Area</sym> </wpt>
Jak już opisałem kiedyś
bazę moich punktów trzymam w pliku (konkretnie w ~/.gps/local.wpts
) co ułatwia jej modyfikowanie.
Jeżeli baza się zmieni, to przesyłam plik (synchronizuję) do urządzenia wykorzystując
program gpsbabel
.
Jedna z atrakcji doliny Radości w Gdańsku. Dojście/dojazd jest bardzo prosty -- asfaltem w górę aż do stawów rybnych, tutaj jest parking i szlaban. Za szlabanem to już blisko -- jedziemy dalej, a w momencie kiedy alfalt skręca w lewo (na zakręcie, po lewej znajdują się zabudowania leśniczówki), zjeżdżamy/schodzimy z asfaltu i dalej kawałek prosto. Po jakiś 50--100 metrach w prawo (a nie dalej prosto). Tą drogą lekko pod górę jakieś 500 metrów i dojeżdżamy/dochodzimy do kamienia, który znajduje się na wzgórzu, przy drodze. Dodatkowo jest tabliczka, więc trudno to miejsce przeoczyć... Trzeba podejść jakieś 100 metrów po zboczu. Współrzędne kamienia to 54.392956/18.510197. Wygląda zaś jak na rysunku obok.
Po obejrzeniu kamienia wróciliśmy na drogę asfaltową i pojechaliśmy dalej w górę... Ta droga prowadzi do ul. Słowackiego; można też nią dojechać do Matemblewa. My dojechaliśmy tylko do skrzyżowania (ca miejsca o współrzędnych 54.385589/18.532811) z drogą, którą można wrócić z powrotem do Oliwy. Droga jest praktycznie równoległa do alfaltowej którą przyjechaliśmy, tyle że w lesie. No i ciągle w dół, bo do tego miejsca było głównie pod górę... Wyjeżdżamy jakieś 500 metrów, przed Kuźnią Wodną, który to budynek znajduje się jak wiadomo na początku Doliny Radości.
Trasa w postaci śladu GPS jest tutaj.
Albo w wersji
kml (Googleearth).
GPSowi ,,puściły zawory'' w okolicach zdjęcia dscf7124
(ca miejsca o współrzędnych 54.397747/18.545939). Odtąd trasa
zupełnie odbiega od tej, którą jechaliśmy,
aż do Spacerowej, na której urządzanie złapało z nowu
poprawne namiary. Dodatkowo GPS pogubił na samym
końcu, jak pojechałem -- już sam -- w okolice
jez. Nowowiejskiego w Sopocie zrobić zdjęcia sromotnikom,
których cała kolonia idąca w co najmniej kilkadziesiąt
owocników właśnie tam się znajduje.
Mniej znana atrakcja Gdańska położona w dolinie Radości. Dojście wygląda następująco: Kierujemy się na hotel Oliwski Dwór. Jak już do tego hotelu dojdziemy to należy iść w górę, wzdłuż doliny ścieżką na skraju lasu (mając ogródki działkowe po lewej ręce). Mijamy małe jeziorko i wychodzimy na łąkę. Teraz trzeba zachować czujność i skręcić w prawo do lasu (miejsce skrętu ma współrzędne (54.399598/18.529976, cf. górne zdjęcie zamieszczone obok). Idziemy według znaków czarnego szlaku. Po przejściu 20--30 metrów droga się rozwidla. Idziemy w lewo (wzdłuż szlaku, tyle że niekoniecznie jest to oczywiste, bo znaczek może być słabo widoczny). Po 100--200 metrach będzie widać skocznię na lewym zboczu doliny (a raczej to co ze skoczni zostało). Dokładnie naprzeciwko skoczni znajduje się kamień--płyta pamiątkowa.
Płyty z dołu nie widać. Trzeba wejść na prawe zbocze--dokładnie naprzeciw zeskoku skoczni (współrzędne 54.40047/18.52563). Informacje nt. płyty są także tutaj oraz tutaj.
Przy okazji jak załadować plik GPX do Garmina (za wiki.gpsbabel.org):
gpsbabel -w -i gpx -f ~/.gps/local.wpts -o garmin -F /dev/ttyUSB0
Nota bene stojąc na rozbiegu skoczni płytę widać doskonale.... Dziwny pomysł na zmotywowanie zawodników:-)
Dopisane 6 maja 2009: Informacja z Panoramy Gdańskiej zamieszczona na youtube.com
Jak nie zapiszę, to zapomnę. Już kiedyś znalazłem serwis pozwalający on-line na tworzenie tras (routes) w formacie GPX za pomocą klikania w GoogleMaps. Nie zapisałem i oczywiście nie mogłem go znaleźć przez dłuższą chwilę. W końcu jest: http://www.gmap-pedometer.com/. Moja przykładowa trasa: Brodnica-BachotekUMK. IMHO czasami może się okazać przydatne...
Dokupiłem najtańszy odbiornik Garmina pn. Etrex h. Urządzenie to ma monochromatyczny wyświetlacz i nie obsługuje map. Nie ma wysokościomierza jak geko, nie ma też kompasu elektronicznego. Wysokościomierz barometryczny geko wskazywał pi-razy-drzwi a kompas jest niepotrzebny. Etrex pokazuje kierunek bez kompasu, wystarczy się poruszać.
Etrex h (z literą H) ma chipset firmy MTK, tej samej co zrobiła Iblue747. Wyświetlacz tego urządzenia jest duży, litery wyraźne. Łatwiej też wyświetlić bieżący czas na ekranie; w geko wymagało to extra ekwilibrystyki. Z drugiej strony, podgumowane guziki są bardziej toporne niż w geko i trochę trudniej nimi operować.
Wygląda, że urządzenie ma wadę polegającą na błędnym wyliczaniu średniej i przebytej drogi (widać to na zdjęciu obok). Jeżeli podczas wędrówki wyłączę Etrexa a następnie włączę -- przy ograniczonej widoczności nieba -- na ekranie pojawiają się wyniki typu 2000 km/h. Na szczęście zapisany ślad jest OK, nie ma na nim punktów z Afryki czy Hondurasu. Niby nie jest to wada z gatunku mocno uciążliwych, ale denerwuje. No co tu dużo mówić: bubel.
Porównanie śladów iblue, etrexa oraz geko jest tutaj (czerwony ślad to etrex, niebieski iblue, turkusowy geko 301). Etrex wyłączył się nie wiedzieć czemu w pewnym momencie.
Ślady w różnych kolorach wymagały drobnych zmian
w bibliotece
gpx-viewer Kaza Okudy.
Oryginalna biblioteka rysuje tylko na czerwono a moja modyfikacja zmienia kolor
dla każdego
elementu <trk>
zawierającego <cmt>
(por. GPX 1.1).
Zmiana koloru dla każego elementu trk
nie byłaby
dobrym pomysłem, bo ślad pobrany z GPSa często jest dzielony na wiele
elementów trk
.
Dodanie cmt
ma wymusić
zmianę koloru na żądanie.
GPSbabel nie wstawia cmt
do śladu pobieranego z urządzenia.
GPS logger to odbiornik GPS wyposażony w pamięć pozwalającą na rejestrację przebytej drogi (śladu). Ślad z GPSa jest mi potrzebny do dodania współrzędnych geograficznych do zdjęć. Do tej pory do tego celu wykorzystywałem odbiornik Geko 301 firmy Garmin. Geko jednakże jest urządzeniem starszego typu i generalnie nie działa jeżeli nie widzi ,,czystego nieba''. Nie działa w lesie, często są duże problemy w terenie mocno zabudowanym, itp.
Postanowiłem kupić lepszy odbiornik. Czytając fora i blogi poświęcone GPS najpierw dowiedziałem się, że jest coś takiego jak SIRF. Już chciałem takiego SIRFa kupić ale doczytałem o chipsecie MTK. Według niektórych doniesień jest on lepszy niż SIRF 3 (są też tacy co twierdzą, że tak nie jest; głosów w stylu X to syf a ja jestem wielkim znafcom nie biorę pod uwagę).
Ceny loggerów na allegro zaczynają się od 300 zł (styczeń 2008) a ja znalazłem coś chwalonego, podobno działającego z Linuksem co jest dla mnie bardzo ważne i (okazało się) tańszego pn. i-Blue 747 Dziwne, ale w Polsce nikt tego nie sprzedaje, przynajmniej w Internecie. Znalazłem i-Blue na ebay za mniej niż 200 zł przy czym 30% tej kwoty stanowiły koszty wysyłki.
BTW opis na e-bay był w języku włoskim, sklep w Niemczech, sklepowy (sądząc po imieniu i nazwisku, Turek) po angielsku słabo pisał, ale się dogadaliśmy i paczka doszła.
Do obsługi loggera jest dołączony CDrom z programem. Program jest
of course na system MSW,
ale podobno działa z wine. Dokładnie postępując według instrukcji
stąd dało się go uruchomić:
należy zainstalować wine
, uruchomić winecfg
,
a następnie:
cd ~/.wine/dosdevices ln -s /dev/ttyUSB0 com1
Teraz należy skopiować
plik instalacyjny
i uruchomić wine DataLog.exe
.
Program zostanie zaistalowany tyle, że u mnie nie działa.
Ściąga ślad całkiem dziarsko
ale nie do końca bo zwisa.
Próbowałem dwa razy raz zawisł gdy wskaźnik był na 49%
drugi raz na 89%.
W google znalazłem opinie użytkowników
Ubuntu utrzymujących, że w ich systemie wszystko
działa (like a charm).
BTW w MS Windows też były problemy, zarówno z instalacją,
jak i z uruchomieniem, ale jak w końcu poszło, ale
co z tego przecież nie będę go używał w systemie W.
Uwaga: Aby ściągnąć ślad albo zmienić konfigurację urządzenia przełącznik musi być w pozycji LOG. Po uruchomieniu programu pierwsze co trzeba zrobić to zatrzymać zapis śladu (można to zrobić tylko programowo), bo inaczej logger cały czas zapisuje dane.
Zainstalowałem też w bólach bt747 (aplikacja Javy).
Zresztą autor ostrzega, że dokumentacja jest niedoskonała. Po
rozpakowaniu zipa, zainstalowałem zawartość katalogu
rxtx-2.1-7-bins-r2
,
zgodnie z tym co jest napisane
w pliku INSTALL
, umieszczonym w tym katalogu. Następnie
uruchomiłem skrypt run_rxtx.sh
, zmieniając wartość
zmiennej MYROOTPATH=/usr/local/bt747
.
Żby użytkownik
miał dostęp do /dev/ttyUSB0
musi być w grupie
uucp
, to już ustaliłem wcześniej. Dalej jednak nie
działało (check_group_uucp(): error testing lock file creation
Error details: Permission denied check_lock_status:
No permission to create lock file.).
Kluczowa okazała się zmiana praw dostępu do
/var/log
:
chmod 777 /var/lock
Aplikacja, jak widać obok, wygląda okropnie, ale funkcjonalnie jest OK: ściąga
dane i kasuje LOG. Więcej nie potrzebuję. Żeby skrypt run_rxtx.sh
działał uruchamiany z dowolnego katalogu musiałem jeszcze zmienić wartości
zmiennej CLASSPATH
(albo wstawić zawartość CLASSPATH
jako wartość opcji -cp
przy uruchamianiu javy):
CLASSPATH=${RXTXJAR}:$MYROOTPATH/webstart/Waba_only.jar:\ $MYROOTPATH/dist/BT747_rxtx.jar:.:$CLASSPATH
Wreszcie jest też aplikacja pn. MTKbabel (skrypt Perla), działająca podobnie do programu GPSbabel, czyli z wiersza poleceń. Do działania wymaga zainstalowania modułu Device::SerialPort. Ten sposób działania podoba mi się najbardziej. Pobranie danych sprowadza się do wydania następującego polecenia:
mtkbabel -f nazwa-pliku-bez-rozszerzenia -t
Powstaną dwa pliki (dlatego nie podaje się rozszerzenia): jeden w formacie binarnym, drugi w fomacie GPX. Jedno wielkie ale -- transmisja jest bardzo wolna: plik binarny o wielkości ca 650 kB (czyli ca 30% pamięci) był ściągany z loggera 9 minut 47 sekund. Czyli cała pamięć byłaby ściągana 30 min. Hmm... Dla porównania obie wcześniej wymienione aplikacje ściągały te 650 kB w circa 2 minuty. Różnica jest.
Wykonałem już dwa eksperymenty porównujące iblue z moim Garminem 301. Pierwsza trasa to las, w wielu miejscach gęsty i wysoki. Do tego też w wielu miejscach jary o stromych zboczach. Trasa zapisana przez geko oraz trasa zapisana przez iblue. Nie ma porównania, bo geko w zasadzie w lesie nie działał.
Druga trasa to teren zabudowany, a konkretnie Sopot. Zabudowa w większości 3--4 kondygnacyjna. Dwa razy wszedłem do sklepu (Geko zgubił w pierwszym ślad, ale poczekałem po wyjściu aż znajdzie, a za drugim razem sam szybko się odnalazł). Oba ślady wyglądają nieźle (cf. geko iblue). Iblue pogubił się w okolicach skrzyżowania 1-go Maja z Aleją Niepodległości, gdzie wszedłem do sklepu (na dłużej). Nie zgubił satelity, tak jak geko, ale trasa w tym miejscu jest nieprawidłowa (wielki `tik' od 1-go Maja wzdłuż Al. Niepodległości w stronę Gdańska. Na mapie od szpilki oznaczonej jako `sklep' do szpilki `tik'. W rzeczywistości od sklepu poszedłem do szpilki oznaczonej `tunel' i dalej wzdłuż ul. Bohaterów Monte Cassino, co zresztą też jest zaznaczone). Nie ma różnicy pomiędzy śladami zredukowanymi do 500 punktów i dużo większym -- 2500 punktów.
Reasumując: wszystkie zdjęcia zrobione na obu trasach zostały (z zadowalającą precyzją) oznakowane współrzędnymi geograficznymi na podstawie śladu z Iblue, a po to go kupiłem.
Ślad iblue zredukowałem za pomocą gpsbabela, bo oryginalny ślad
składa się z tysięcy punktów. Iblue zapisuje ślad co sekundę, Garmin
w trybie auto (Iblue nie ma czegoś takiego jak auto).
Kiedyś eksperymentowałem z Garminem i też go przestawiłem
na zapis sekundowy, ale nie zaobserwowałem różnicy pomiędzy takim trybem
a trybem auto. Polecenie uproszczenia śladu wygląda
następująco (Log.nma
zawiera dane zapisane jako
NMEA):
gpsbabel -i nmea -f Log.nma -x simplify,count=450 \ -o gpx -F 2008-01-23BT_x.gpx
Poniżej bardziej zaawansowane polecenie: zapisz jako GPX, ślad od 2008-01-24T13:40
od 2008-01-24T14:50, następnie upraszczając go do 500 punktów.
Uwaga: opcje
-x
nie są przemienne, tj. ich zamiana skutkowałaby najpierw
uproszczeniem do 500 punktów, a potem wycięciem od-do, dając w rezultacie
ślad dużo bardziej uproszczony:
gpsbabel -i nmea -f GPSDATA-20080123.nmea \ -x track,start=200801241340,stop=200801241450 -x simplify,count=2500 \ -o gpx -F 20080124BT_x.gpx
Kończąc, trochę mnie zastanawia/niepokoi trwałość tego urządzenia, bo jakość wykonania jest taka sobie (100% chińszczyzna). Jakby mi, np. wypadł z ręki, to chyba byłby to jego ostatni lot. Nawet nie próbuję tego sprawdzać. Poza tym logger wydaje się całkiem, całkiem...
Dopisane 16 marca 2008: Dioda GPS: pomarańczowa -- szuka satelitów; pomarańczowa/miga -- nawiguje; niebieska/miga -- mało pamięci (mniej niż 20%); niebieska -- pamięć jest zapełniona, stop (cokolwiek to znaczy); trzykrotny błysk -- zarejestrowanie POI. Dioda baterii: czerwona -- bateria prawie wyczerpana; zielona -- ładowanie; zielona/miga -- naładowana. Dioda BT: niebieska -- BT włączone, ale nie połączony; wolno miga -- połączony w sleeping mode; szybko miga -- połączony i gotowy.
Dopisane 16 marca 2008: projekt formularzy
w aplikacji bt747
jest daleki od ergonomicznego, stąd
poniżej krótka rekapitulacja.
Aby usunąć plik: Fmt/Erase (albo Fmr/Set&erase).
Pobranie pliku i zapis na dysk: Log/Get Log i inne przyciski z tej karty.
Karta File: konfiguracja. Karta Con: połączenie z urządzeniem.
Innych kart w zasadzie nie używam.
Dopisane 19 marca 2008:
Poniżej skrypt do zamiany pliku NMEA pobranego z bt747
na
plik GPX. Skrypt upraszcza uruchomienie gpsbabela. Ponadto
uruchomiony z opcją -U
wycina niepotrzebne znaczniki (np. <ele>
, czyli
wysokość, która w moim przypadku zawsze wynosi zero. Dodatkowo
liczy długość wyciętego śladu. Pełny skrypt jest
tutaj.
# !/bin/bash # # Skrypt ułatwiający uruchomienie programu gpsbabel # Wycina fragment ścieżki + upraszcza ślad do zadanej liczby punktów # Na koniec plik podaje długość wyciętego śladu. # OUT='' FORMAT=nmea ROK=`date +"%Y"` XREDUCE="NO" while test $# -gt 0; do case "$1" in -help|--help) echo "$USAGE"; exit 0;; -od) shift; START="$1";; -od*) START="`echo :$1 | sed 's/^:-od//'`";; -do) shift; STOP="$1";; -do*) STOP="`echo :$1 | sed 's/^:-do//'`";; -max) shift; COUNT="$1";; -max*) COUNT="`echo :$1 | sed 's/^:-max//'`";; -rok) shift; ROK="$1";; -rok*) ROK="`echo :$1 | sed 's/^:-rok//'`";; -format) shift; FORMAT="$1";; -format*) FORMAT="`echo :$1 | sed 's/^:-format//'`";; -U) XREDUCE="YES";; -out) shift; OUT="$1";; -out*) OUT="`echo :$1 | sed 's/^:-out//'`";; -h) echo usage; exit;; -h*) echo usage; exit;; *) FILE="$1";; esac shift done if [ "$XREDUCE" = "YES" ] ; then echo "** Tracks will be simplified! (Option -U)" ; fi EXTENSION=${FILE##*.} BASE=`basename $FILE .$EXTENSION` if [ "$OUT" = "" ] ; then OUTFILE="$BASE.gpx" ; else OUTFILE="$OUT" ; fi if [ "$START" != "" -a "$STOP" != "" ] ; then PERIOD="-x track,start=$ROK$START,stop=$ROK$STOP" ; elif [ "$START" != "" ] ; then PERIOD="-x track,start=$ROK$START" ; elif [ "$STOP" != "" ] ; then PERIOD="-x track,stop=$ROK$STOP" ; fi if [ "$COUNT" != "" ] ; then SIMPLIFY="-x simplify,count=$COUNT" ; fi if [ -f "$BASE.$EXTENSION" ] ; then gpsbabel -i $FORMAT -f $BASE.$EXTENSION $PERIOD $SIMPLIFY -o gpx -F $OUTFILE if [ -f "$OUTFILE" -a "$XREDUCE" = "YES" ] ; then extension=${OUTFILE##*.} simname="`basename $OUTFILE .$extension`_s.$extension" echo "** File $OUTFILE simplified to $simname" ; # perl -e 'while ( <> ) { unless(/<ele|fix|course|speed>/) ... to błąd !! perl -e 'while ( <> ) { unless(/<(ele|fix|course|speed)>/) { print $_ }} ' $OUTFILE > $simname OUTFILE=$simname fi else echo "File $BASE.$EXTENSION found!" ; echo "$USAGE" fi if [ -f "$OUTFILE" ] ; then ## Oblicz dystans: echo "** Counting distance covered in: $OUTFILE " perl -e 'use Geo::Distance; my $geo = new Geo::Distance; my $qchars = "\042\047"; # znaki cytowania pojedynczy i podwojny while (<>) { if (/<trkpt\s+lat\s*=\s*([$qchars])([^$qchars]+)\1\s+lon\s*=\s*([$qchars])([^$qchars]+)\3/) { $lat=$2; $lon=$4; unless ($trkpt < 1) { $dist += $geo->distance( "meter", $plon, $plat => $lon, $lat ); } $trkpt++; $plat=$lat; $plon=$lon; } } print "** Distance covered (meters): $dist\n"; ' $OUTFILE fi
W okresie świątecznym i na przełomie roku wykonałem kilka eksperymentów weryfikujących jakość dodawania współrzędnych za pomocą synchronizacji czasu odbiornika GPS i aparatu. Dokładnie siedem prób (odpowiednio data: zdjęcia ogółem/zdjęcia oznaczone): 20071226: 61/61, 20071228: 11/11, 20071229: 29/29, 20071230: 71/71, 20071230: 48/48, 20080101: 30/30, 20080102: 8/22. Łącznie zdjęć było zatem 260 z czego 16 (6,1%) nie zostało zsynchronizowanych. Większość zdjęć została oznakowana z zadowalającą albo nawet dobrą dokładnością. Niektóre trasy były łatwe: płaski teren. Ale trasa z 31.12 prowadziła w sporej części przez gęsty las a GPS się nie pogubił. Dziś poszedłem jeszcze dalej do lasu, no i GPS tym razem odmówił kooperacji. A GPSa -- zgodnie z zaleceniem, żeby był jak najwyżej -- noszę pod czapką!
Przerobiłem swoje skrypty, oraz bibliotekę dla Emacsa. Aby odróżnić zdjęcia zawierające zdefiniowane tagi EXIF ze współrzędnymi geograficznymi od tych, które tej informacji nie zawierają, generowana miniatura zdjęcia zawiera czerwony prostokąt w lewym górnym rogu (jeżeli zdjęcie jest już geotagowane). No tak to sobie wymyśliłem.
Niektóre ślady GPS na mojej stronie zawierają teraz miniatury zdjęć. Publikuję też dane w formacie KML. Uaktualniony opis jest tutaj. Detaliczna instrukcja jak używać GPSphoto. jest zaś tutaj.
Dopisane 8 maja 2008/Zmodyfikowane 27 sierpnia 2008: Podsumowanie procedury pobrania śladu z urządzenia GPS i ich zamiany na ślad w formacie GPX/KML:
Ślad z urządzenia jest pobierany albo za pomocą gpsbabela albo programu bt747.
Skrypt nmea2gpx
zamienia dane w formacie NMEA na GPS w razie potrzeby
wycinając fragment śladu i upraszczając go (opcja -max liczba-punktów
).
Skrypt akceptuje także inne formaty danych wejściowych (opcja -format
):
nmea2gpx -od czas -do czas -max liczba [-format format ] [-U ] [-out plik.gpx] plik
Skrypt My-photo-sync.sh
(wykorzystujący gpsPhoto.pl
)
,,synchronizuje'' ślad ze zdjęciami i generuje plik w formacie KML:
My-photo-sync.sh -d katalog-zdjęć -f plik.gpx -t różnica-czasów
różnica czasów jest obliczana za pomocą skryptu exif_datetime.pl
exif_datetime -b czas_z_GPSa -f zdjęcie -o GMT_offset_in_seconds
gdzie: zdjęcie, to nazwa pliku ze zdjęciem ekranu GPSa;
czas_z_GPS, to czas wyświetlany przez GPSa na ww. zdjęciu;
GMT_offset_in_seconds, różnica między czasem lokalnym a GMT (niektóry GPSy to wyświetlają,
a jak nie to łatwo jest to obliczyć).
Ponieważ uruchamianie exif_datetime
w ww. sposób dla każdej sesji zdjęciowej
jest pracochłonne można też napisać:
exif_datetime
Powyższe wyświetli przesunięcia czasowe zapisywane w pliku ~/.time_offset
. Ponieważ
czas w aparatach rozsynchronizowuje się w miarę
wolno, wystarczy co kilka tygodni aktualizować ~/.time_offset
.
Można też napisać:
My-photo-sync.sh -d katalog-zdjęć -f plik.gpx -a
Przesunięcie zostanie pobrane automatycznie z pliku ~/.time_offset
. [Nie trzeba
uruchamiać exif_datetime
.]
W wyniku wykonania My-photo-sync.sh
powstaje także plik .kml
.
Skrypt perlowy kml-adjust-urls
zamienia linki do zdjęć
w pliku KML, tak aby wskazywały na zdjęcia umieszczone w serwisie
flickr.com (skrypt My-photo-sync.sh
oryginalnie wstawia linki lokalne). Przed wykonaniem kml-adjust-urls
należy wykonać flickr_update_kb
bo kml-adjust-urls
pobiera
informacje nt. zdjęć lokalnie z bazy utworzonej przez flickr_update_kb
.
kml-adjust-urls plik.kml
Ubocznym efektem działania kml-adjust-urls
jest plik plik.wpts
zawierający elementy <wpt>
określające linki do zdjęć umieszczonych na flickr.com.
Zawartość tego pliku można dodać do pliku plik.gpx
uzskanego w kroku #2.
Ślad -- wyświetlony w googlemaps
-- będzie wtedy zawierał ,,pinezki'' z minaturami zdjęć.
Niektóre zdjęcia z lokalnego katalogu nie są umieszczone na
flickr.com. Skrypt kml-skip-deadlinks
usuwa takie
zdjęcia z pliku KML. Mało eleganckie rozwiązanie -- jeden skrypt by wystarczył, ale
nie mam czasu w tej chwili poprawiać skryptu kml-adjust-urls
:
Skrypt kml-adjust-urls
usuwa takie zdjęcia z pliku .kml
.
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.
Jak większość jeżdżących na rowerze pilnie notuję przejechane kilometry i inne przydatne dane. Robię to w sposób dość elementarny:
<day date="2007/08/25"> <ride dist="60" exdist="60.00" bike="b"> <by name='Banino' /> <by name='Miszewo' /> <by name='Przodkowo'/> <by name='Czeczewo'/> <by name='Warzno'/> <by name='Kielno' /> </ride> </day>
Jak widać jest to plik w formacie XML; co oznaczają poszczególne elementy i atrybuty można IMHO się zorientować po ich nazwach. Odpowiednie skrypty XSLT formatują dane, liczą średnie miesięczne i roczną. Całość jest dostępna tutaj. Ponieważ system jest w miarę toporny, dziś zrobiłem rozpoznanie co w tym zakresie oferują inni i znalazłem dwa potencjalnie interesujące serwisy: bikestats oraz bikebrother.
Pierwszy z wymienionych jest prostszy: pozwala na oznakowanie wyjazdów za pomocą daty, czasu, przejechanych kilometrów oraz krótkiego opisu. Bikebrother ma dużo bardziej rozbudowany opis. Więcej można przesłać ślad GPSa trasy. Pliki GPS mogą pobrać inni użytkownicy.
Oba serwisy prezentują dane w efektowny sposób i to jest ich jedyny plus. Minusów jest więcej: dodawanie danych za pomocą formularzy to przeżytek:-) Jakiś REST-based API byłoby dużo bardziej wygodniejsze. Wpisywanie wszystkich danych do formularza Bikebrothera musi być męczące. Nie ma (albo jest bardzo starannie ukryte) eksportu danych, więc i tak trzeba robić kopie.
Reasumując na razie minusy zdecydowanie przewyższają nad plusami. No i na koniec: licencje. Oczywiście na ten temat nic nie ma, pliki zawierające ślady GPS są udostępnione ,,na kocią łapę'' (albo nie na kocią: są własnością autorów). Może jestem przewrażliwiony ale nie lubię w ten sposób dzielić się danymi. Tzn. lubię dzielić się ale na określonych zasadach, np Creative Commons. Za granicą też zresztą kombinują zamiast korzystać ze sprawdzonych rozwiązań.
Poniżej przykładowe ekrany wpisywania danych (pierwszy z Bikestat, drugi z BB; jak się kliknie to będą większe):