ten dotycny jsem byl asi ja, zitra (resp. ) uz dneska to zkusim dohledat. Jelikoz jsem tehdy jeste nemel vyskomer a pouzival jsem na kole jenom klasicky cyklo pocitac a pak PDAcko s GPSkou, napsal jsem si programek, ktery si vytahne z track logu vyskove udaje a patricne je upravi, aby se apon trochu blizily realite. Ale uplne presne to samozrejme neni ani tak.
Umi to pracovat s track logem, ktery produkuje OZIExplorer.
Pokud si psal vlastní program, jaký si použil algoritmus pro korekce.
Něco jednoduchého jako používám v Touratech, tedy pouhé odstraňovaní přebytečných bodů, které jsou příliš blízko u sebe a nejvíce způsobují chyby ve výšce nebo něco chytřejšího?
Algoritmus jsem pouzil velmi jednoduchy - snazil jsem se pro mereni vysky nepouzivat vsechny body, ktere jsou treba i jednotky metru od sebe, ale brat v potaz body, ktere od sebe byly dale. Samozrejme je tam i tak zkresleni, ale uz daleko mensi, nez puvodne. S uplne prvnim nejjednodusiim resenim jsem se vubec neparal a proste jsem vysledek vsech zaznamenanych bodu vydelil dvema a taky to vice mene sedelo ;). Ale to je prilis velka divocina ;).
Pak se da udelat jeste nejaka jednoducha korekce vylozene velkych chyb - napr. obcas pri ztrate signalu a znovunalezeni je gpska schopna skocit v nadmorske vysce o nekolik desitek metru najednou, to taky neni problem eliminovat.
Bohuzel ten program jaksi nemohu najit :(. V nejhorsim bych to mohl napsat znovu, neni to nic sloziteho.
Tak to je stejný princip jako ten filtr v Touratechu.
Složitější algoritmy by byly na bázi filtrování šumu signálu. Tedy např. udělat několik vzorků na úplné rovině. Z nich určit šum, který tam nepatří a takový filtr pak použít na celý tracklog.
Jenže bohužel výsledky stejně nejsou nic moc, často horší než jen to jednoduché vynechání bodů, které jsou moc blízko u sebe.
Ten šum je totiž velmi rozdílný při různých podmínkách.
Nenapsal si na srovnání jakých úletů to potřebuješ.
Tady je pro pořešení nastoupaných metrů:
Teď jsem to zrovna psal před pár dny do sousedního threadu s jakým nastavením trackprocessoru v Touratechu to používám.
Je to tady v tom threadu:
http://www.nakole.cz/diskuze/tema.php3?id=6655
Tam bys to asi normálně nehledal, proto dávám odkaz.
Asi si to chce zkusit pohrát s nastavením. To co používám pouze vyhodí všechny body, které jsou blíže jak 5m u sebe, čímž se docílí toho, že zmizí ty rychlé výkyvy.
Testoval jsem to na více projetých trasách od kterých jsem znal nastoupané metry z jiných přesnějších zdrojů a porovnával a došel k tomuhle nastavení. Samozřejmě to není ideální, ale průměrně se to tak trefuje nejlépe a odhaduju, že chyba nástopaných metrů po úpravě by už neměla být větší než 5% (samozřejmě často bude i menší).
No, zrovna u té Meduzovy trasy tohle ale nepomohlo... Tam byly úlety v poloze ve stovkách metrů, kterých si ten nástroj nevšiml. Tohle se asi musí ze záznamu vyházet ručně.
Řešil jsem to včera a předevčírem s Crempou...
Ten nástroj neumí řešit úlety bodů, které jsou někde mimo a ani není k tomu určen.
Jen v podstatě vymaže některé body, když jsou moc hustě.
Pozičně mi body normálně moc neulétavají až na občasné případy, když se stojí na místě, tam se to občas stává. Mohlo by to vadit pro maximální rychlost, kterou Crempa počítá tedy pravděpodobně správně.
Ta mě ale nezajímá, ta stejně nikdy nemůže být z gpsky správně (a nejlbíž správné hodnotě je přímo z údaje na gpsce) a na tom mám tacháč (vozím ho kvůli tepáku, jinak bych ho nevozil).
My vždy řešili jiný problém. Pozičně byly body správně (samozřejmě občasný úlet o pár metrů je možný a ničemu nevadí), ale výška při horším příjmu signálu kolísá neustále sem tam.
A při častém záznamu třeba ve stoupání tak místo aby body měly za sebou výšku dejme tomu 832; 832,5; 833; 833,5m; atd. tak to lítá nahoru dolu a je tam třeba 832;834;833;835; atd.
A takhle to nasčítá pak neskutečné metry, už jsem viděl i 2,5tis. nastoupaných metrů při reláných tisíci.
A na tenhle problém slouží to nastavení trackprocessoru, co jsem psal a ten právě vyřeší, že jen některé body to vymaže, pak se tam ty výškové skoky neprojeví.
Samozřejmě ty poziční úlety zvlášť při zastávkách, ty se musí případně vyhodit ručně (ale ty jsou vidět i v mapě a ručně to vyhodit není problém, pokud někomu stojí za to si s tím hrát).
Ale nevim, jestli jste probírali i ty nastoupané metry. Tam musí být někde problém. Protože když to na totožném tracklogu (ať už na tom původním neupraveném nebo projetém trackprocessorem) ukazuje na Crempovi o mnoho metrů více než mi nasčítal Touratech z těch stejných dat.
A tady jsou jen dvě možnosti. Buď je na Crempovi chyba v určování nastoupaných metrů nebo Touratech při tom používá nějaký chytřejší algoritmus (ale to není moc pravděpodobné, protože pokud tam ty chyby s lítající výškou sem tam jsou, tak to prostě nasčítá ty nesmysly oproti reálu taky - tam pak ale trackprocessor pomůže).
Ten výškový problém s těmi lítajícími body nahoru dolu tam ale Meduza neměl, takže trackprocessor to nijak neovlivnil (změna o 10m v celku je nic).
A sakra, tohle jsem u něj nereklamoval :-( My řešili jen tu bláznivou rychlost... A psal, že to někdy zkusí vyřešit.
No, ale když jsem ty body vyházel ručně, tak nastoupané metry klesly asi o 100m...
Koukni niže, tam máte další konkrétní příklad, který případně můžete projít.
Netvrdím, že to sčítá špatně, je možné, že Touratech opravdu používá nějaký složitější algoritmus než jen nasčítat rozdíly výšek vždy dvou po sobě jdoucích bodů (tedy pro stoupání u případu, že ten druhý bod má výšku vyšší).
Ty nastoupané metry jsou podle mě kromě samotného profilu jediný opravdu zajímavý údaj a u toho aspoň mě to zajímá, jak to je opravdu reálně (samozřejmě nějaká mírná nepřesnost do nějakých 5% je fuk). Protože to mi při započtení obtížnosti povrchu a terénu + skouknutí profilu hodně řekne o obtížnosti trasy.
Narazil jsem na tuhle parádní věc, jenže to existuje jen v Němčině :-(
http://www.gps-freeware.de/Default.aspx
P.S. Potřebuje to .NET Framework 2.0
Nějaké screeny z programu http://www.gps-freeware.de/Beschreibung.aspx
Dle obrázků to má funkcí opravdu hafo. Ale ta němčina mě také odrazuje.
I když já vlastně k Touratechu nic dalšího nepotřebuju, mám ho dokonec i koupený a z funkcí, co je u toho softu to spoustu umí taky (třeba 3d profil trasy a další). Statistik nad tracklogem sice Touratech tolik neumí, ale to mě upřímně moc nezajímá, zajímají je v podstatě jen profil a ty nastoupané a metry a pak samozřejmě trasa jako taková, abych podle ní mohl dělat nové trasy.
Co kdyby to Medved prelozil?:-)
:-)
Bez zdrojáků jsme nahraní... Sice existují i brute-force nástroje, které se umí šťourat i ve výsledném EXE nebo DLL souboru, ale to je strašný opruz něco takového dělat, obzvlášť u celého programu... To už bych radši dal těch pár šlupek za TTQV :-)
No...jestli jsem to dobre pochopil, je to free program? Jestli ju, tak by programator urcite nebyl proti, aby se udelala jazykova mutace.... A urcite by se zaridil.
Ale to by se mu muselo napsat...nemecky:-) A to ja umim jen pozdravit a podekovat:-)
Jak jsem se kdysi snažil pročítat forum na jeho stránkách, tak se zatím docela brání i angličtině... A o tom, že by poskytoval nějaké lokalizační soubory k přeložení také nevím...
Nápodobně :-)))
Aha...skoda...jde sam proti sobe...nemec, no:-)
Spíš bych to čekal u Frantíka :-)))
No ti jsou jeste horsi:-)
Tak by mohl alespon Medved udelat ceskej manual:-)
A pro možnost případně řešit ty nastoupané metry jsem vytvořil i jeden muj příklad z loňského bikování v Jeseníkách.
Tady:
http://data.mlok.net/gps/Kralicak/
jsem uložil dva tracklogy. Ten první je přesně jak jsem ho stáhnul z GPSky a obsahuje mírnou chybu ve výškových metrech, ale ne moc velkou. Druhý je projetý trackprocessorem v Touratechu.
Když si nechám zobrati nastoupané metry v Touratech, tak pro originální tracklog ukazuje 1834m, pro upravený pak 1722mm.
Dle několika GPSsek dle barometrických výškoměru s korekcemi to bylo právě cca těch 1700m. Dle mapy mi to vyšlo přibližně ještě o něco méně (v mapě ale nenasčítám těch něco málo úseků, kde to je jen lehounce zvlněné).
No a když to hodí na Crempu, tak originál trasu ukazuje nastoupaných 2131m a upravenou trasu 1921m. Na tom odkazu jsou uložená pdfka reportů.
A jak Touratech, tak Crempa mají stejná vstupní data. Touratech ukáže metry, které odpovídají realitě a Crempa výrazně více než je skutečnost.
Kde je problém netuším, ale někde být musí.
A nechtěl bys to s ním řešit Ty ? ;-) Víš mnohem lépe než já o čem s ním diskutovat...
Přiznám se, že ani ne :-)
Klidně přiznám barvu a řeknu, že mi je úplně fuk, co to na Crempovi ukazuje, já to nepoužívám.
Ale pro ty co to používají jsem nahodil konkrétní případ, který by se dal řešit, pokud budete chtít, teď už se snažte sami :-)
Díky všem za rady.
Moe první představa byla, že si v nějakém programu zobrazím zaznamenou trasu (jak na mapě, tak výškový profil) a ručně naposouvám těch pár úletů. zatím mám záznam jen z krátké testovací vyjížďky, tak ještě nevim, jak se mi to bude chovat na delších trasách, jestli toho nebude moc. Aele tak ta automatika by to kdyžtak řešila lépe, než jsem čekal :)
Ten Touratech vypadá jako vhodnej program, zatím jsem na prácí se záznamama neměl vůbec nic. Vyzkouším a uvidím, případně se ještě ozvu
Ono stejně potřebuješ mít nějaký SW, který pracuje s rastrovou mapou. A tady je na výběr v podstatě jen Touratech a Oziexplorer.
Pokud to chceš mít legálně, tak zadarmo není ani jeden, ale je fakt, že Ozi je o něco levnější. U Touratechu nestačí verze light, protože ta je očesaná už moc, nejsou tam třeba výškové profily a další důležité věci. Je tedy třeba verze standard a tu už není nejlevnější.
Tak to ja vetsinou uz v PDA OziExploreru pomazu rucne takove ty "evidentne ustrelene body" (treba pri nabihani GPS), ktere jsou videt na prvni pohled (popr. i trasu spojim do jedne, pokud se treba nekde ztratou signalu "rozpoji") a pak abych nemel tech bodu tolik, uz jen pouzivam to "filtrovani" v PC verzi OziExploreru, ktere odstrani z trasy ty "prebytecne body", aby byl vysledny soubor mensi, ale dal uz tu vysku radeji nekoriguju, protoze tezko odhadnout, co by mi tam zaneslo vetsi zkresleni ...