Bug on climb pro

Because I have thousands of files I recorder in the past 20 years and all have different point density. And I want to be sure that what happened last Saturday will never happen again. It was a very frustrating experience.

What you say does not make any physical sense, sorry. No matter how many points a track has, it will always be a segmentation approximation. So what is the required precision for Edge 1030+?

Internet has millions of tracks at different precision, and the reason is that very long tracks can be very heavy in terms of points. I used to load tracks into my Etrex and I never experienced any issue.

Roberto Ena said:

Because I have thousands of files I recorder in the past 20 years and all have different point density. And I want to be sure that what happened last Saturday will never happen again. It was a very frustrating experience.

The file you are using won't work well. You can get a very good idea whether a file is good enough by overlaying it on a map.

The file you provided is not good enough. If you don't want it to happen again, don't use these bad files.

Roberto Ena said:

What you say does not make any physical sense, sorry. No matter how many points a track has, it will always be a segmentation approximation. So what is the required precision for Edge 1030+?

Obviously, the track is going to have segments. It needs to be "good enough". Aweatherall suggested points every 50m.

Your track clearly does not follow the roads very well! You are having navigation problems that are related to it not being "good enough".

Historically, tracks were created by recording the ride/hike, with points collected every second or so.

Route planners use more points in curves and fewer points in straight areas. This works fine because the track still follows the roads.

OK.

50 meters sounds fair.

So, in summary: if an user load a gpx track file with a density of 200 meters per point (which still was a fair density for files that were recorder few years ago), what happens is:

1) the climb pro feature is more or less useless, because it relies on that file (this is reasonable)
2) the device gets some sort of internal error, and even if the user changes its destination, the climb pro page retains the previous climbs (as I documented with my video). This is a bug.

Right?

Your problems here might be due to a file that isn't appropriate. Your problems in the other thread are clearly the result of using an inappropriate file.

That people don't appear to be experiencing the issue suggests that your problems are due to the file.

To know if it's really a bug, you have to see what happens when you use an appropriate file.

======================

I think Garmin might have, on some units, added (or is considering adding) climbpro for calculated routes (where one isn't using a track file). Originally (and currently?), it used the elevation in the file. It wouldn't be "too hard" to add this feature (Climbpro for calculated routes).

Thanks, could you please answer clearly to my question?

Loading a gpx file with a resolution of 200 m causes this:

"2) the device gets some sort of internal error, and even if the user changes its destination, the climb pro page retains the previous climbs "

Right?

It should never get an "internal error". it's not clear what might be the cause of it. I can't comment on a track file I know little about.

Are you stopping navigation before "the user changes their destination"?

Does a track file with a higher resolution have the problem?

I use track files created on ridewithgps. These have variable resolution. I haven't seen any issues with Climbpro (on a 1030+ or a 1030).

======================

A file with a resolution of 200 m won't work well for navigation unless there aren't many curves.

The activity recording is points every second (roughly). At about 8 km/h (moderate climbing speed), that means a point every 2 meters. Keep in mind that tracks don't need as many points for straight paths.

I think the discussion is just going around in circles. The threadopener does not want to see that the gpx file should contain so many track points that the paths / roads are covered as accurately as possible. He is of the opinion that his inaccurate track must be enough - especially since the course calculation follows the course of the road anyway. And he is not completely wrong: if the Edge already calculates a realistic route, why is one still "off course" when one follows it?
(Yes, I know why - because Edge refers to the original track and not to the calculated route)

Unfortunately I don't know if using a better gpx file could have avoided the issue, I am not going 150 kms again :)

And I prefer not to upload the full video unless you give me "go ahead" because my language was very rude, especially towards my unit.

If you have any debug task for me, I'll be happy to help.

Please please please try to get my point, as a customer: I don't care if I get approximated results from an approximate gpx, this is fair.

But I have thousands of old gpx with variable precision. Will my garmin freeze again just because I loaded a poor gpx?

Lots of other people (I'm one of them) appear not to have any issues (with navigation or climbpro) with the tracks they use. Your one example isn't acceptable for navigation. So, IF your climbpro issue is related to that, not many people will see the climbpro problem.

I wouldn't use such a file (for navigation). I would either recreate it or load it to something and edit it.

I don't know if your device will freeze.

I do know that you will have "off course" (and, at times, other navigation) issues with files like the one example you provided.

Note that Garmin doesn't really read these forums. (They do for a few things but not for much of it.)

========================

With a bunch of features (like distance to destination and virtual partner), the device pauses them if you go off course. It's possible the unit does something like that with Climbpro. That is, the file you load might need to trace your intended path accurately for climbpro to work properly. It could be the device isn't working properly with all the off-course/on-course changes your bad file is causing. So, both problems might be resolved with using a better file.