Messages

You can force the app recalculate them if you export/import them as GPX.
Also you can test the next version (beta version) that you can find in the forum.

While we are trying the newer versions (still not as good in this as the version 6 was)
Is it possible to let recalculate them always at the end?

Or better, is it possible to have a setting option to choose which algorithm to use for computing ascending and descending time? Computation wasn't wrong for me in later apps (at least for my type of activities, here in the Alps).

Many thanks, Orux!

Hello,
well the beta version works sure better, even if it is not perfect yet 😉
Anyway, good work Orux!

Attached are some screenshots showing results of the same trip recorded by 2 OruxMaps on the same phone, 8.5.5 GP and 8.5.5beta21, then with DEM recalculated quota in GP version using 2m dem files, and a Suunto9 watch.

...and the two attachments from the suunto watch

Cloud

Hello,
well the beta version works sure better, even if it is not perfect yet 😉
Anyway, good work Orux!

Attached are some screenshots showing results of the same trip recorded by 2 OruxMaps on the same phone, 8.5.5 GP and 8.5.5beta21, then with DEM recalculated quota in GP version using 2m dem files, and a Suunto9 watch.

Buenos días, orux no graba correctamente el tiempo de subida y bajada.
La grabación del tiempo total es correcta pero el tiempo de subida y bajada es inferior y las estadísticas son erradas. Adjunto el file de ayer donde se puede ver que caminamos por 7 horas pero el tiempo de subida es de 50 minutos más o menos.
La versión instalada es la 8.5.5
Cual podría ser el problema?
Gracias
Giovanna

Maybe is the issue also described in this other thread? https://oruxmaps.org/forum/index.php?topic=31897.msg42125#msg42125
If it is, it is still an open issue with Oruxmaps 8.5.5

I think in the thread at the link they suppose the track has not only uphill and downhill, so different from the one you refer to, right?
Are you stating that you tracked a path with only uphill and downhill, the moving time is right, but uphill and downhill times are underestimated? That is the problem I notice, too.
IMHO it seems to be an issue with the algorithm used in understanding when you are walking uphill, downhill, or flat.

I think it's because of that, using DEM-files for altitude those times improves quality.

Also me the same issue... 

I notice time ascending and time descending summed together are near to the moving time. Anyway moving time is far from the totale time even if there were non long pauses: is there something considering me not-moving if I am moving really slowly? Maybe a threshold or an integer number tracking it instead of a decimal number?

In addition to this, I also notice on other tracked routes that, after the track is saved in the database, from the properties, using the button "fix altitude button with DEM files", those times improve (become more realistic), growing such that the sum is near to the total time, as desired.

Really anyone noticing those results?

Sometimes I forgot to stop recording when I finish my hike trip, so I have some tracks that includes a trip by car: statistics are so useless and the tour is longer / more than actual.

I would like to delete a portion of the recorded track. Could you implement something to correct tracks like that ones ? (I notice that a deletion of a segment is possible, but my tracks usually are made of a single segment...)



In an online forum I read about a solution that might be: export the track, edit with a text editor, then import it. I was in trouble during the export, because OruxMaps tells me "export completed" but I can't understand where the file was saved, neither I found it (I don't know what name it could have...)



Any help, suggestion, or idea?

Thank you very much for the very good and flexible app! I love it ^_^