Erinevus lehekülje "GPSBabel" redaktsioonide vahel

Allikas: Tipikate Rattamatkaklubi teabebaas
Jump to navigation Jump to search
(ei näidata sama kasutaja 7 vahepealset redaktsiooni)
58. rida: 58. rida:
 
   cd ..
 
   cd ..
 
   rm -rf gpsbabel
 
   rm -rf gpsbabel
 +
 +
== Näited ==
 +
=== Filtreerimine sõltuvalt kaugusest ===
 +
Kui on vaja filtreerida välja huvipunktid sõltuvana kaugusest mingist kesksest punktist, saab seda teha nii:
 +
 +
gpsbabel -i gpx -f lokkekohad.gpx -x radius,distance=38K,lat=58.47,lon=26.71 -o gpx -F lokkekohad_tartu.gpx
 +
 +
See näide filtreerib enam-vähem välja need lõkkekohad, mis jäävad Tartumaale või selle ümbrusesse. "38K" tähendab siin kaugust kesksest punktist (58,47N, 26,71E).
 +
 +
=== Marsruudi või rajalogi lihtsustamine ===
 +
=== Sissejuhatus ===
 +
Mõnikord on vajalik töödelda või talletada marsruuti või rajalogi, milles on ilmselgelt liiga palju punkte. Sel juhul võib abiks olla rajapunktide vähendamine. Üks põhjus selleks võib olla lihtsalt talletatava andmemahu vähendamine, aga olulisemaks muutub see juhtudel, kui on soov antud marsruuti või rajalogi edasi töödelda. Eriti võib liigne rajapunktide arv häirida juhul, kui rada töödeldakse käsitsi. Samuti võib mõnel juhul liiga palju punkte arvuti aeglasemaks muuta.
 +
 +
GPSBabel toetab rajapunktide vähendamist läbi kahe erineva filtri: ''position'' ja ''simplify''. Neist esimene eemaldab rajapunktid, mis on üksteisele liiga lähedal, teine võimaldab rajapunkte eemaldada lähtuvalt sellest, et rajajoon hiljem võimalikult algupärane välja näeks. Ilmselt võiks abi olla ka filtrist, mis võimaldaks eemaldada punkte lähtuvalt ajalisest lähedusest, aga tundub, et see on hetkel puudu. ''position'' filtri korral on küll võimalik määrata, et punktid eemaldatakse ainult juhul, kui need ajaliselt lähestikku on, aga ''simplify'' filtri puhul ajalist parameetrit üldse ei ole.
 +
 +
=== Position filter ===
 +
[https://www.gpsbabel.org/htmldoc-1.6.0/filter_position.html Position filter] eemaldab punkte, mis on üksteisele liiga lähedal. Testimisel ilmnes, et antud filtril on (vähemalt GPSBabel 1.5.4+ development versioonis) olemas üks veidrus, kus kustutati ära oluliselt rohkem punkte kui loogiline tunduks. Internetist otsides sai leitud [https://wiki.openstreetmap.org/wiki/GPSBabel/Using_filters#Remove_duplicates_and_nearby_points_filter leht], mis väidab, et tegemist on bugiga. Lisaks aga [https://wiki.openstreetmap.org/wiki/Talk:GPSBabel/Using_filters leht], mille järgi võib tegemist olla ka lihtsalt bugiga dokumentatsioonis. Nii üldiselt tundub siis, et ''position'' filter ei võrdle eemdaldamisel punkti mitte ainult sellele vahetult eelnevaga, vaid kõigi eelnevate punktidega. Ning juhul kui samal rajal liiguti näiteks edasi-tagasi, siis eemaldatakse tagasi osalt enamik või kõik punktid. Tundub, et antud veidrusest aitab üle saada, kui kasutada lisaks ''distance'' parameetrile ka ''time'' parameetrit, näiteks:
 +
 +
gpsbabel -t -i gpx -f in.gpx -x nuketypes,waypoints,routes -x track,pack,start=2000 -x position,distance=5m,time=10 -o gpx -F out.gpx
 +
 +
NB! Tasub märkida, et sellist meetodit saab siiski kasutada ainult juhtudel, mil tegemist on rajalogiga ning see sisaldab ka ajatempleid! Marsruutide puhul ilmselt ''position'' filtrit kasutada ei ole mõtet (kui just ei ole kindel, et marsruut ei sisalda lõikuvaid ega kattuvaid osi).
 +
 +
=== Rajalogi lihtsustamine ===
 +
Nii üldiselt tasub mainida, et marsruudi ja rajalogi lihtsustamised on veidi erinevad. Kui näiteks jalgrattaretke ette joonistatud marsruudi puhul võib üldiselt 7-11 rajapunkti kilomeetri kohta olla juba vägagi kvaliteetne rada, siis rajalogi puhul tundub, et see number võiks olla näiteks 30-70 punkti kilomeetri kohta. Marsruudi puhul on pigem oluliseks see, et punkte ei oleks liiga palju - marsruudi punktide töötlemine (kaardile kandmine, lihvimine) käib pigem käsitsi ning liiga palju punkte tähendab liiga palju tööd. Teisalt on käsitsi tegemisel jälle see eelis, et inimene suudab "kauni" raja kuju kaardile kanda kahtlemata väiksemate punktide arvuga kui automaatne süsteem seda suudaks. Rajalogi puhul võib suurem arv punkte olla õigustatud ühelt poolt seetõttu, et rajalogi ei ole tavaks enam (vähemalt sellisel määral või viisil kui marsruute) käsitsi töödelda. Teisalt tekitavad GPS seadmed ja nutitelefonid kohati kurvides päris ilusaid kaari, mida käsitsi joonistada polekski mõtet, otstarbekas või võimalik. Kolmandaks aga ei suuda automaatne joonistamise loogika saada kunagi hakkama sama väheste punktidega kui inimene käsitsi marsruudi joonistamisel.
 +
 +
Nii üldiselt tundub, et Garmin Edge Touring Plus GPS kasutab rajalogi talletamisel üsna head loogikat, et ühelt poolt optimeerida punktide arvu, kuid teisalt mitte rajajoont liigselt lõigata. Ühelt poolt ei talleta antud GPS seistes liiga palju punkte, samas tekitab neid rohkem kiiremal liikumisel. Samuti on ilmselt olemas mingi loogika, et kui liiga kaua liiga sirgelt liikuda, siis ikkagi pannakse vahele lisa punkt, et näiteks ajatempel hiljem näha jääks. See info vajab nüüd rohkemate rajalogide baasilt üle kontrollimist, aga nii üldiselt tundub, et keskmise õhtuse rattasõidu rajalogil talletatakse 40-50 rajapunkti kilomeetri kohta. Ja selle raja kvaliteedile midagi ette heita küll ei saa (välja arvatud muidugi juhtumid, kus lihtsalt GPS signaaliga probleeme on).
 +
 +
GPSBabeli abil rajalogi lihtsustades päris nii head varianti ei ole, seega sama kvaliteediga rajalogi saamiseks on ka peale lihtustamist üldiselt punktide arv suurem (a'la 55-65 rajapunkti kilomeetri kohta). Nii üldiselt tundub, et ''simplify/crosstrack'' filter on siinjuures peamine, mis ühelt poolt võimaldab punktide arvu väga palju vähendada, samas algset rajajoone kuju pea täielikult säilitades. ''position'' filter on selles osas märksa kehvem - ta hakkab kurve lõikama, eriti kui tegemist on järsu tagasipööramisega vms. Samas punktide arv nii palju ei vähene kui ''simplify/crosstrack'' puhul. Hetkel on "parima pakkumisena" välja pakkuda järgnev käsurida:
 +
 +
gpsbabel -t -i gpx -f in.gpx -x nuketypes,waypoints,routes -x track,pack,start=2000 -x simplify,crosstrack,error=0.0003k -x position,distance=3m,time=10 -o gpx -F out.gpx
 +
 +
Ehk siis kõigepealt eemaldatakse kõik punktid, mille eemaldamisena ei nihku rajajoon paremale-vasakule rohkem kui 30 cm jagu. Ühel näiterajajoonel sai seeläbi 13641 punktist 3253 punkti, samas kui 30 cm laiuste kõrvalekallete eemaldamine ei tähenda rajajoone kujule tegelikult "mitte midagi". Siinkohal võiks kasutada ka 10 korda suuremat väärtust (ehk 3 meetrit), ilma et rajajoone kujuga väga palju juhtuks. Punktide arv läheks veel oluliselt alla, samas miinuseks on see, et sirgetel lõikudel võib mõnes kohas kahe järjestikuse punkti vahe väga suureks minna. Kui ''simplify'' filtril oleks olemas ka võimalus ajaliselt määratleda, et "vähemalt 15 sekundi tagant tahan punkti väljundisse", võiks tegemist olla veelgi võimsama ja pandlikuma filtriga. Hetkel tuleb aga leppida sellega, et GPS seadmega sama kvaliteediga rajajoone saamiseks jääb ka tulemusse rohkem punkte.
 +
 +
Ülal toodud näites on aga peale ''simplify/crosstrack'' filtri kasutatud veel ka ''position'' filtrit. Tasub mainida, et seda kasutatakse üsna leebe seadistusega, ehk siis eemaldatakse punktid, mis on üksteisele lähemal kui 3 meetrit. Lisaparameeter 10 sekundit on vajalik siis selleks, et ei eemaldataks punkte, mis tagasiteel eelneva marsruudi lähedusse satuvad (vt probleemi püstitust eespool). Leebe seadistuse tõttu ei vähene punktide arv küll märkimisväärselt - näites toodud raja 3253 punktist sai seeläbi 3131 punkti. Pigem aga eemaldab see filter punktid, mis visuaalselt vaadates veidi silma häirivad - näiteks üksteisele väga lähedal olevad punktid, mille järgi võiks arvata, et rattur metsas siksakiliselt mättalt mättale hüppas. Suuremaks kui 3 meetrit pole aga soovitav seda filtrit keerata seetõttu, et siis hakatakse üsna pea juba reaalseid tagasipöördeid maha lõikama.
 +
 +
Märkus 14.02.2020: Tasub ilmselt tulevikus dokumenteerida ka seda, millisest seadmest ja millise iseloomuga rajalogisid tasub töödelda ja milliseid mitte. Peale Talvematka 2020 selgus, et (vähemalt jalgsimatkal) ja CAT S41 telefoniga oli rajalogi piisavalt hea (~50 rajapunkti kilomeetrile), et automaattöötlust polnud mõtet teha. Tehtud sai ainult käsitsi töötlus, et "isiklikud puu taga käimise pausid" jms välja korrigeerida ning algus ja lõpp paika lõigata.
 +
 +
== Juhuslikud märksõnad ==
 +
* On olnud mõte, et äkki on võimalik GPSBabel'it kasutada selleks, et retkele minnes genereerida KML ja TCX failid automaatselt, st et ei peaks iga kord käsitsi Javawa RTWTool graafilist liidest kasutama. KML faili tekitamine pole kindlasti probleem (kuigi pole veel järgi proovitud), TCX puhul teeb asja keerukamaks soov pöördekohtade info lisada. GPSBabel küll toetab mingit sarnast ''bend'' funktsionaalsust, kuid selle täpsem mõte on läbi testimata. Kirjelduse järgi päris meile vajalikku asja see ei paku.
 +
* GPSBabel toetab radade ühendamist ''pack'' ja ''merge'' meetodil. Neist esimesel juhul ei tohi olla ajaliselt kattuvaid rajasegmente, teisel juhul võib. Siiski on puudu selline ''merge'', mis kahest rajalogist ühtlustamise teel ühe kokku paneks - olemasolev ''merge'' valib sama ajatempli puhul ühe või teise punkti.
  
 
[[Category:Digitaalne_rajaplaneerimine]]
 
[[Category:Digitaalne_rajaplaneerimine]]
 +
[[Category:Videokaardistamine]]

Redaktsioon: 14. veebruar 2020, kell 09:16

Sissejuhatus

Tegemist on vabavaralise tasuta utiliidiga, mis võimaldab erinevaid GPSides ja seotud tarkvarades kasutatavaid failiformaate teisendada, muuta ja analüüsida.

Paigaldamine

Installipakett

GPSBabel kodulehel on olemas installipakett Windowsile ja algkoodi TAR pakk Linuxile. Ubuntu all võib selle paigaldada ka lihtsalt nii:

sudo apt-get install gpsbabel

Ise kompileerimine

Sissejuhatus

6. mai 2018 seisuga on viimane ametlik väljalase 1.5.4 pärit jaanuarist 2017. Kui see versioon ei rahulda, võib Github'ist laadida alla kõige uuema arendusversiooni ning selle ise kokku kompileerida. On osutunud näiteks, et Garmin Virb X kaamerast pärit .FIT failid ei ole 2017. aasta GPSBabeli jaoks sobilikud. Ubuntu apt-get abil paigaldatav versioon on 2018. aasta mai seisuga veel vanem ehk 1.5.2 ning see annab nende .FIT failide teisendusel lihtsalt vea. Uusim ametlik väljalase 1.5.4 (jaanuar 2017) teisendab .FIT failid küll GPX formaati ära, aga ajatemplid on pärit aastast 1989. Foorumitest pärit jutu järgi lahendati see probleem ära 2017. aasta suvel, aga kuna uut ametlikku väljalaset pole peale seda tehtud, tuleb soovi korral ise kompileerida.

Eelduste paigaldamine

Antud teisenduse jaoks ei ole ilmselt vajalik, aga et meil tekiks kõikvõimas versioon, tasub teha nii:

sudo apt-get install libusb-dev

Git'ist kloonimiseks:

sudo apt-get install git

Vaja on paigaldada ka Qt. Samas vajab 6. mai 2018 seisuga uusim GPSBabel Qt versiooni vähemalt 5.7, samas kui Ubuntu apt-get annab versiooni 5.5x.

Et saada uuem Qt versioon, tuleb tootja kodulehelt laadida alla Open Source versioon enda operatsioonisüsteemile (Linux või Windows, 32-bit või 64-bit).

Seejärel anda alla laetud failile käivitamise õigused ning käivitada ta:

chmod 755 qt-unified-linux-x64-3.0.4-online.run
sudo qt-unified-linux-x64-3.0.4-online.run

Käivitada tasub root õigustes, sest siis paigaldatakse ta /opt kausta, muidu läheb kasutaja enda kodukausta.

Graafilisel installeril pakutakse suurepärast võimalust registreerida jne, millest saab mööda allääres oleva SKIP nupuga. Valitud komponentidest võib üldiselt valida kõige minimaalsema, juurde tuleks panna valik Qt 5.10.1 -> Desktop gcc 64-bit (või muu uusim/endale sobiv versioon).

Ilmnes ka, et vähemalt tol katsel oli vaja Qt versiooni valikuks käsitsi symlink teha:

sudo ln -s /usr/lib/x86_64-linux-gnu/qtchooser/qt5.conf /usr/lib/x86_64-linux-gnu/qtchooser/default.conf

Lisaks oli vaja selle sama faili sees aga path-id ära muuta, nii et faili sisuks sai:

/opt/Qt/5.10.1/gcc_64/bin
/opt/Qt/5.10.1/gcc_64/lib

Kui on soov mingi hetk see Qt maha võtta või komponente juurde panna/ära võtta, siis selleks tuleb käivitada:

sudo /opt/Qt/MaintenanceTool

GPSBabel kloonimine, kompileerimine ja paigaldamine

git clone https://github.com/gpsbabel/gpsbabel.git
cd gpsbabel
./configure LDFLAGS="-Wl,-rpath=/opt/Qt/5.10.1/gcc_64/lib"
make
sudo make install

gpsbabel on nüüd paigaldatud ja kõikjalt kasutatav. Versiooniks ütleb 1.5.4 (nii nagu viimane ametlik väljalase), aga katse Garmin Virb X kaamerast pärit .FIT failide GPX-ks teisendamisega toimis nüüd ilusti. Kompileerimiseks kasutatud kausta võib soovi korral ära kustutada:

 cd ..
 rm -rf gpsbabel

Näited

Filtreerimine sõltuvalt kaugusest

Kui on vaja filtreerida välja huvipunktid sõltuvana kaugusest mingist kesksest punktist, saab seda teha nii:

gpsbabel -i gpx -f lokkekohad.gpx -x radius,distance=38K,lat=58.47,lon=26.71 -o gpx -F lokkekohad_tartu.gpx

See näide filtreerib enam-vähem välja need lõkkekohad, mis jäävad Tartumaale või selle ümbrusesse. "38K" tähendab siin kaugust kesksest punktist (58,47N, 26,71E).

Marsruudi või rajalogi lihtsustamine

Sissejuhatus

Mõnikord on vajalik töödelda või talletada marsruuti või rajalogi, milles on ilmselgelt liiga palju punkte. Sel juhul võib abiks olla rajapunktide vähendamine. Üks põhjus selleks võib olla lihtsalt talletatava andmemahu vähendamine, aga olulisemaks muutub see juhtudel, kui on soov antud marsruuti või rajalogi edasi töödelda. Eriti võib liigne rajapunktide arv häirida juhul, kui rada töödeldakse käsitsi. Samuti võib mõnel juhul liiga palju punkte arvuti aeglasemaks muuta.

GPSBabel toetab rajapunktide vähendamist läbi kahe erineva filtri: position ja simplify. Neist esimene eemaldab rajapunktid, mis on üksteisele liiga lähedal, teine võimaldab rajapunkte eemaldada lähtuvalt sellest, et rajajoon hiljem võimalikult algupärane välja näeks. Ilmselt võiks abi olla ka filtrist, mis võimaldaks eemaldada punkte lähtuvalt ajalisest lähedusest, aga tundub, et see on hetkel puudu. position filtri korral on küll võimalik määrata, et punktid eemaldatakse ainult juhul, kui need ajaliselt lähestikku on, aga simplify filtri puhul ajalist parameetrit üldse ei ole.

Position filter

Position filter eemaldab punkte, mis on üksteisele liiga lähedal. Testimisel ilmnes, et antud filtril on (vähemalt GPSBabel 1.5.4+ development versioonis) olemas üks veidrus, kus kustutati ära oluliselt rohkem punkte kui loogiline tunduks. Internetist otsides sai leitud leht, mis väidab, et tegemist on bugiga. Lisaks aga leht, mille järgi võib tegemist olla ka lihtsalt bugiga dokumentatsioonis. Nii üldiselt tundub siis, et position filter ei võrdle eemdaldamisel punkti mitte ainult sellele vahetult eelnevaga, vaid kõigi eelnevate punktidega. Ning juhul kui samal rajal liiguti näiteks edasi-tagasi, siis eemaldatakse tagasi osalt enamik või kõik punktid. Tundub, et antud veidrusest aitab üle saada, kui kasutada lisaks distance parameetrile ka time parameetrit, näiteks:

gpsbabel -t -i gpx -f in.gpx -x nuketypes,waypoints,routes -x track,pack,start=2000 -x position,distance=5m,time=10 -o gpx -F out.gpx

NB! Tasub märkida, et sellist meetodit saab siiski kasutada ainult juhtudel, mil tegemist on rajalogiga ning see sisaldab ka ajatempleid! Marsruutide puhul ilmselt position filtrit kasutada ei ole mõtet (kui just ei ole kindel, et marsruut ei sisalda lõikuvaid ega kattuvaid osi).

Rajalogi lihtsustamine

Nii üldiselt tasub mainida, et marsruudi ja rajalogi lihtsustamised on veidi erinevad. Kui näiteks jalgrattaretke ette joonistatud marsruudi puhul võib üldiselt 7-11 rajapunkti kilomeetri kohta olla juba vägagi kvaliteetne rada, siis rajalogi puhul tundub, et see number võiks olla näiteks 30-70 punkti kilomeetri kohta. Marsruudi puhul on pigem oluliseks see, et punkte ei oleks liiga palju - marsruudi punktide töötlemine (kaardile kandmine, lihvimine) käib pigem käsitsi ning liiga palju punkte tähendab liiga palju tööd. Teisalt on käsitsi tegemisel jälle see eelis, et inimene suudab "kauni" raja kuju kaardile kanda kahtlemata väiksemate punktide arvuga kui automaatne süsteem seda suudaks. Rajalogi puhul võib suurem arv punkte olla õigustatud ühelt poolt seetõttu, et rajalogi ei ole tavaks enam (vähemalt sellisel määral või viisil kui marsruute) käsitsi töödelda. Teisalt tekitavad GPS seadmed ja nutitelefonid kohati kurvides päris ilusaid kaari, mida käsitsi joonistada polekski mõtet, otstarbekas või võimalik. Kolmandaks aga ei suuda automaatne joonistamise loogika saada kunagi hakkama sama väheste punktidega kui inimene käsitsi marsruudi joonistamisel.

Nii üldiselt tundub, et Garmin Edge Touring Plus GPS kasutab rajalogi talletamisel üsna head loogikat, et ühelt poolt optimeerida punktide arvu, kuid teisalt mitte rajajoont liigselt lõigata. Ühelt poolt ei talleta antud GPS seistes liiga palju punkte, samas tekitab neid rohkem kiiremal liikumisel. Samuti on ilmselt olemas mingi loogika, et kui liiga kaua liiga sirgelt liikuda, siis ikkagi pannakse vahele lisa punkt, et näiteks ajatempel hiljem näha jääks. See info vajab nüüd rohkemate rajalogide baasilt üle kontrollimist, aga nii üldiselt tundub, et keskmise õhtuse rattasõidu rajalogil talletatakse 40-50 rajapunkti kilomeetri kohta. Ja selle raja kvaliteedile midagi ette heita küll ei saa (välja arvatud muidugi juhtumid, kus lihtsalt GPS signaaliga probleeme on).

GPSBabeli abil rajalogi lihtsustades päris nii head varianti ei ole, seega sama kvaliteediga rajalogi saamiseks on ka peale lihtustamist üldiselt punktide arv suurem (a'la 55-65 rajapunkti kilomeetri kohta). Nii üldiselt tundub, et simplify/crosstrack filter on siinjuures peamine, mis ühelt poolt võimaldab punktide arvu väga palju vähendada, samas algset rajajoone kuju pea täielikult säilitades. position filter on selles osas märksa kehvem - ta hakkab kurve lõikama, eriti kui tegemist on järsu tagasipööramisega vms. Samas punktide arv nii palju ei vähene kui simplify/crosstrack puhul. Hetkel on "parima pakkumisena" välja pakkuda järgnev käsurida:

gpsbabel -t -i gpx -f in.gpx -x nuketypes,waypoints,routes -x track,pack,start=2000 -x simplify,crosstrack,error=0.0003k -x position,distance=3m,time=10 -o gpx -F out.gpx

Ehk siis kõigepealt eemaldatakse kõik punktid, mille eemaldamisena ei nihku rajajoon paremale-vasakule rohkem kui 30 cm jagu. Ühel näiterajajoonel sai seeläbi 13641 punktist 3253 punkti, samas kui 30 cm laiuste kõrvalekallete eemaldamine ei tähenda rajajoone kujule tegelikult "mitte midagi". Siinkohal võiks kasutada ka 10 korda suuremat väärtust (ehk 3 meetrit), ilma et rajajoone kujuga väga palju juhtuks. Punktide arv läheks veel oluliselt alla, samas miinuseks on see, et sirgetel lõikudel võib mõnes kohas kahe järjestikuse punkti vahe väga suureks minna. Kui simplify filtril oleks olemas ka võimalus ajaliselt määratleda, et "vähemalt 15 sekundi tagant tahan punkti väljundisse", võiks tegemist olla veelgi võimsama ja pandlikuma filtriga. Hetkel tuleb aga leppida sellega, et GPS seadmega sama kvaliteediga rajajoone saamiseks jääb ka tulemusse rohkem punkte.

Ülal toodud näites on aga peale simplify/crosstrack filtri kasutatud veel ka position filtrit. Tasub mainida, et seda kasutatakse üsna leebe seadistusega, ehk siis eemaldatakse punktid, mis on üksteisele lähemal kui 3 meetrit. Lisaparameeter 10 sekundit on vajalik siis selleks, et ei eemaldataks punkte, mis tagasiteel eelneva marsruudi lähedusse satuvad (vt probleemi püstitust eespool). Leebe seadistuse tõttu ei vähene punktide arv küll märkimisväärselt - näites toodud raja 3253 punktist sai seeläbi 3131 punkti. Pigem aga eemaldab see filter punktid, mis visuaalselt vaadates veidi silma häirivad - näiteks üksteisele väga lähedal olevad punktid, mille järgi võiks arvata, et rattur metsas siksakiliselt mättalt mättale hüppas. Suuremaks kui 3 meetrit pole aga soovitav seda filtrit keerata seetõttu, et siis hakatakse üsna pea juba reaalseid tagasipöördeid maha lõikama.

Märkus 14.02.2020: Tasub ilmselt tulevikus dokumenteerida ka seda, millisest seadmest ja millise iseloomuga rajalogisid tasub töödelda ja milliseid mitte. Peale Talvematka 2020 selgus, et (vähemalt jalgsimatkal) ja CAT S41 telefoniga oli rajalogi piisavalt hea (~50 rajapunkti kilomeetrile), et automaattöötlust polnud mõtet teha. Tehtud sai ainult käsitsi töötlus, et "isiklikud puu taga käimise pausid" jms välja korrigeerida ning algus ja lõpp paika lõigata.

Juhuslikud märksõnad

  • On olnud mõte, et äkki on võimalik GPSBabel'it kasutada selleks, et retkele minnes genereerida KML ja TCX failid automaatselt, st et ei peaks iga kord käsitsi Javawa RTWTool graafilist liidest kasutama. KML faili tekitamine pole kindlasti probleem (kuigi pole veel järgi proovitud), TCX puhul teeb asja keerukamaks soov pöördekohtade info lisada. GPSBabel küll toetab mingit sarnast bend funktsionaalsust, kuid selle täpsem mõte on läbi testimata. Kirjelduse järgi päris meile vajalikku asja see ei paku.
  • GPSBabel toetab radade ühendamist pack ja merge meetodil. Neist esimesel juhul ei tohi olla ajaliselt kattuvaid rajasegmente, teisel juhul võib. Siiski on puudu selline merge, mis kahest rajalogist ühtlustamise teel ühe kokku paneks - olemasolev merge valib sama ajatempli puhul ühe või teise punkti.