Locus Map - forum

Support => Troubles & Questions => Topic started by: Graf Geo on July 17, 2023, 14:52:07

Title: Nonsense values in merged track
Post by: Graf Geo on July 17, 2023, 14:52:07
A small problem with the displayed track statistics for merged tracks:

Sometimes I forget to activate the track recording at the start of a tour and do this only after, for example, 0,56 km.
I then create the first 0,56 km with the route planner and then merge the two tracks. The part with the route planner logically does not contain any time values.

The merged total track then contains the correct total distance (e.g. 20,93 km, of which 20,36 km was recorded and 0,56 km was created with the route planner). The altitude profile is also correct.

However, nonsense is displayed for the track time: 469238:54:07.
Likewise with the pace: 1344958:37

I know that Locus cannot calculate correct values in this case. However, it would be more elegant if then nothing or 0,0 is displayed than such fantasy numbers.

Screenshot 1 shows the statistics of a recorded tour. Length 20.36 km.
The first 560 m are missing and were created with the route planner.
Screenshot 2 shows the statistics of the merged track (20.93 km).

(Such nonsensical values always occur when a recorded track and a track created with the route planner are merged).
Title: Re: Nonsense values in merged track
Post by: Menion on July 21, 2023, 09:22:35
Hi,
when you merge tracks, there is an option "Merge with gaps". Do you have enabled this? If not, give it a try. I understand, there should be no real gap, but this "gap" helps the app separate internally both track and computed time than should be expected.

Btw. with the latest version, the app saves times computed by the route planner, but because there is no "start time", times are computed from "0". So it may cause a problem in some cases, like here.
Title: Re: Nonsense values in merged track
Post by: Graf Geo on July 21, 2023, 13:27:32
Hi Menion,

thank you for the answer. It makes no difference whether I merge the tracks with or without gap - if the section created with the route planner is at the beginning of the merged track, the nonsensical values are generated.

But if the section created with the route planner is at the end, there are no such fantasy values.
Title: Re: Nonsense values in merged track
Post by: Andrew Heard on July 22, 2023, 01:04:30
Quote from: Menion on July 21, 2023, 09:22:35times are computed from "0". So it may cause a problem in some cases, like here.
@Menion - "like here" - no link was provided.
Title: Re: Nonsense values in merged track
Post by: Menion on July 24, 2023, 08:49:08
I though "like here" > "like in this case". Anyway does it happen also with the latest version? I'm trying various combinations with the latest Beta version and no such issue detected, damn.
Title: Re: Nonsense values in merged track
Post by: Graf Geo on July 24, 2023, 16:14:23
Hello Menion,

still the same generation of fantasy-values with V 4.17.2.4 Afa Beta
Title: Re: Nonsense values in merged track
Post by: Menion on July 26, 2023, 10:03:49
I wasn't fixing anything about it. I still can't simulate this issue, sorry.

Maybe some video or exact steps may help?
Title: Re: Nonsense values in merged track
Post by: Graf Geo on July 26, 2023, 13:31:27
Hmm, something must have happen. Here is an example:


Today I create the same missing part again and merged it with the recorded track.
Result does not show fantasy values. Strange.

You can reproduce this with attached 3 tracks:


Merge the recordes track with track 1: Fantasy values
Merge the recordes track with track 2: No Fantasy values

Title: Re: Nonsense values in merged track
Post by: Menion on December 11, 2023, 15:15:21
Old topic, sorry ...

Analyzing and .. interesting problem.

The last point of the "Startteil..." route has an almost identical location as the first point of the original recorded route. This is probably what you wanted. Because of this, the app refused to insert a space (break point) between them and the result was, that time was from "0" (1. 1. 1970) till the day of the second route. This was not the case of the second manual route, where the last point was not identical.

I've improved this behavior, so it should be better in the next app version.