[CZ] Import GPX stopy - spočtená nastoupaná výška je nyní hrubě podceněna

Petr Andrš shared this problem 12 months ago
Solved

Předpokládám, že to souvisí s touto změnou v poslední verzi 4.15.

chg: profound change in computation of elevation values + united computation for existing/imported/recording tracks/routes

Plánuji si trasy pro jízdy na kole v mapy.cz a exportuji je do GPX jako stopu (tak to prostě mapy.cz dělají), importuji do LocusMap a používám pro navigaci. Dříve nastoupané metry co se ukazují u importované stopy velmi dobře korespondovaly s tím, co mi následně naměřil cyklopočítač s barometrickým výškoměrem. Hodnota z cyklopočítače byla většinou trochu nižší než výpočet Locusu, ale výpočet Locusu byl velmi dobrý horní odhad toho co mě čeká. S novou verzí aplikace se hodnoty u nahraných stop ponížily někde i více než o třetinu a jsou o desítky procent nižší než co bylo následně naměřeno barometrickým výškoměrem. Pro úplnost uvádím, že volbu Update elevation mám při importu neaktivní, protože mapy.cz mají podstatně přesnější výškový model.

Replies (6)

photo
1

Zdravím Petře,

pro posouzení bych od vás potřeboval nějaký vzorek na kterém můžu cokoliv otestovat. Ideálně tedy oveřenou trasu kterou importujete do aplikace + očekávané hodnoty. Děkuji

Jiří M. aka Menion

photo
1

Přikládám dva soubory. 1. je export naplánované trasy z mapy.cz s výškovými hodnotami podle modelu mapy.cz. 2. je záznam průjezdu této trasy z cyklistického počítače s barometrickým výškoměrem.

Pokud plán trasy naimportuji do Locus 4.15.2 napočítá se elevation gain 206m, verze 4.14.2 napočítá 325m. Mapy.cz u té trasy ukazují 253 m (a je známo, že mapy.cz ve výpočtu podhodnocují). Cyklopočítač s barometrem napočítal 284m. Pokud nechám přepočítat aplikací Strava dle jejich modelu, který mají vytvořen z dat od uživatelů s barometrickým výškoměrem, dostanu 307m. Aplikace GPS Visualizer zde https://www.gpsvisualizer.com/profile_input napočítá 299 m resp. 256 m podle toho jestli nastavím parametr Elev. gain threshold na 2 nebo 3 m, což jsou hodnoty, které se mi osvědčily jako nejvíce odpovídající realitě, nějaké vysvětlení k tomu je zde https://www.gpsvisualizer.com/tutorials/elevation_gain.html

Celkově se tedy asi rozumná očekávaná hodnota pohybuje nejpravděpodobněji v intervalu 280 - 310 m.

Můžete uvést jakým způsobem se výpočet v Locusu změnil a co bylo důvodem?

photo
1

Zdravím Petře,

díky za trasu a za detailní info. Příště vás pozvu na čaj (bydlím v Horních Počernicích) ať se nemusíme tolik rozepisovat :). Nicméně, váš odkaz na GPS vizualizer je přesná trefa. Inspiroval jsem se velice jednoduchým algoritmem přesně tam a treshold je v Locusu nastaven na 5 metrů. Testoval jsem to na velkém množství tras (několik desítek tisíc) a průměrně se hodnota napočítaných převýšení snížila na cca 90% původních hodnot.

V případě velmi rovných tras je ale pravda, že hodnoty mohou být naopak snížené až moc, jak je vidět i zde. Komplikovaný problém.

Proč ke změně došlo: předchozí algoritmus byl extrémně komplikovaný a navíc byly dva. Jeden při záznamu (kdy nebyl znám průběh "co bude") a jeden po záznamu, když už bylo vše známé a dalo se tedy lépe počítat. Tento nový algoritmus je tak snadný, že logiku sjednocuje a navíc je pro mě snadné přenést ho kolegům na web a na iOS.

Tedy řešení:

- možnost nastavit hodnotu filtru (nabourá konzistenci mezi platformami)

- dynamicky měnit hodnotu podle typu trasy (komplikované pro běžící záznamy)

Atd atd. Ještě to musím více promyslet.

Diskuze se vede i již zde na fóru pokud by vás to zajímalo: https://forum.locusmap.eu/index.php?topic=8339.0

Zatím díky a pěkný večer.

photo
1

Když jsem zkoušel jakou musím v GPS Visualizeru nastavit hodnotu Elev. gain threshold aby to spočítalo nastoupané metry stejně jako teď nově Locus, tak sem se dostal k hodnotě 6 m.

Pro Elev. gain threshold asi neexistuje univerzální hodnota, optimální hodnota se bude lišit podle kvality vstupních dat - množství šumu a navíc nemyslím, že by se míra zašumění dala rozumně spolehlivě poznat a podle toho threshold nastavit. Pro data kvalitního modelu terénu mapy.cz nebo barometru může být nejlepší 2m a pro data z GPS ani 10 m nemusí stačit. Takže by mi přišlo nejlepší mít možnost si hodnotu threshold někde, třeba skrytě, předefinovat podle toho jak to používám.

Teď jsem si uvědomil, že mám záznam té trasy i z Locusu na levném telefonu (dávám přílohu), kde je nadmořská výška z GPS, v nastavení Altitude manager mám vypnuto použití SRTM a Altitude filter na Light. Tam Locus v nové verzi napočítá nesmyslných 743 m a ve staré dokonce 886 m. Výška z GPS je natolik nepřesná a fluktuující, že se z toho prostě nedá dostat nic smysluplného, zejména v méně kopcovitém terénu.

photo
1

To máte samozřejmě přesně pravdu. Proto jsem to celé dělal na velkém vzorku tras a snažil jsem se dojít k nějakému univerzálnímu číslu. Předchozí algoritmus vím že trošku přestřeloval, proto to snížení v průměru na 90%.

Nastavení per zařízení by bylo nejspíše ideální, to souhlasím. Nabourává to nicméně onu konzistenci napříč našimi platformami, tedy to co spočítá Android, by měl spočítat i web i iOS. Aby tohle fungovalo, musela by si každá trasa pamatovat tento "treshold". Což by se asi dalo zařídit.

Pěkný poslední záznam, díky. Při aplikaci nadmořských výšek ze SRTM dat je stoupání krásných 231m.

photo
1

Konzistence bude v případě výchozího nastavení. Pokud si to uživatel bude chtít změnit, bude varován a dál to bude jeho boj. A nemusí na to nutně být GUI, stačí něco jako nastavení časů navigačních hlášek.


Pokud do záznamu z předchozího komentáře doplním výšky přes Update elevation v Locusu (tedy předpokládám SRTM), tak dostanu 231 m v nové verzi a 386 m ve staré. Pokud výšky nahradím v mapy.cz tak je to 195 m a 330 m. Čili horší data jako má SRTM potřebují vyšší míru filtrace, ale i tak je ten nový filtr příliš silný.

photo
photo
1

Zdravím,

zkusme tedy v další (Beta) verzi novou možnost nastavení velikosti "threshold" hodnoty pro každou trasu. Default zůstává 5 pro všechny trasy které hodnotu nemají definovanou. Pokud bude probíhat záznam v aplikaci, při zapnutém barometru či nahrazování výšky SRTM daty nastavím tuto hodnotu nižší. Test ukáže.

photo
1

Já sem svoje workflow popsal na začátku, importuji GPX stopy, které již obsahují kvalitní výšková data, z Google Drive. V Track manageru u foldru kliknu tři tečky a import. Potřebuju aby vlastní threshold šel nastavit při tomto způsobu získání GPX stopy a bylo by fajn moct to nastavit jednorázově (globálně nebo na folder) a nemuset to přenastavovat po každém importu.

photo
photo
1

Zaznamenal jsem úpravu ve verzi 4.16, kdy lze po zapnutí této funkce v Expert settings měnit elevation threshold pro jednotlivé stopy. To je pro mě použitelné, ale přesto bych uvítal možnost přenastavit si výchozí hodnotu globálně nebo pro složku stop do které importuji. Zajímavé je, že abych se dostal na stejné nastoupané metry jako na gpsvisualizer.com, musím v Locusu nastavit hodnotu elevation threshold o 1 menší.

photo
1

Zdravím Petře,

aplikace s filtrací jak jsme se bavili je již nějaký čas venku a příliš připomínek jsem nedostal. Nechal bych tedy zatím stav jak je.

Porovnávám navíc trasu plánovanou v Mapy.cz na webu a následně imprtovanou do Locusu Map a dostávám v podstatě identické hodnoty. Myslím že tedy dobrý ...

c22d3e6cf2bd130048fba7e90e6d83dc

photo
1

No o mapy.cz je právě známo, že ty jimi napočítané výškové metry jsou podhodnocené, výškový model sice mají přesný, ale výpočet mají hodně zjednodušený aby byl rychlý, protože se to přepočítává při plánování okamžitě při každé úpravě a načítání výškových dat je stojí strojový čas.

photo
1

Může být. Pro mě je zásadní, že uživatel který do apky dá trasu z externí aplikace nedostane absordně odlišný výsledek o toho co očekává (co viděl ve zdrojové aplikaci).

photo
Leave a Comment
 
Attach a file