Incorrect course points distance
Ptosiek opened this issue · comments
When using this file (had to zip it)
BB_Loop.tcx.zip
with course_indexing set to true, the resulting distances are incorrect (cf first points in screenshot):
So this file contains several time the same course point (at different time). My guess is that this:
inner_p_check = np.where(
(0.0 <= inner_p) & (inner_p <= 1.0), True, False
)
will find the point 'too late', probably because the first 'original' course point was removed after downsampling.
But maybe it's because the inner_p contains negative value ?
[-1.30880983e-04 -2.54499666e+00 -2.28468095e+00 -2.63298573e+00
-3.35629025e+00 -7.24880940e-01 2.35766962e+00 -4.03876418e+00
-5.17857143e+00 -1.31062866e+01 -2.59921773e+00 -2.27057057e+01...
My thought on the process:
We might want to set the course_points distance before downsampling actually, and if possible when files contains time+distance like this one we would be better reading the distance directly from trackpoint rather than recalculating it manually ?
Hi @Ptosiek ,
this is a difficult case, almost like a bug in the course file. (Probably output by RideWithGPS, right?)
The coordinates (latitude) of the first course point is backward from the first coordinates of the course.
Even more unlucky, the goal of the course is located backward from the first coordinates of the 'course', resulting in this behavior. A round-trip course or a course with multiple laps can make it difficult to determine the current distance on the course.
Usually course points are assumed to be on the course. However, it is possible, since Garmin Connect allows course points to be set at remote points not on the course.
A less good workaround is to eliminate the first course point.
However, as long as the course creation program is outputting this course file, I need to make some modifications to the first course point determination.
Looking more closely, I found that the second point of the original course (Yes, deleted by downsampling) is set back about 1 meter from the starting point.
The first course point is then set against that point.
If the starting point had been moved a few meters to the east and the first course point no longer existed, it would have worked correctly.
But maybe it's because the inner_p contains negative value ?
Yes, positive values between 0 and 1 indicate the course point is in the 2 close points of course.
We might want to set the course_points distance before downsampling actually, and if possible when files contains time+distance like this one we would be better reading the distance directly from trackpoint rather than recalculating it manually ?
Oh, getting the distance from the original course file is one idea.
I know only json format of RideWithGPS course seems to have distances of course points. (It has full texts and expandable for the future, such as voice reading).
Hey,
Yes it's a file from RideWithGPS
For the record I prevented downsampling, I am getting this instead:
So there's still a bug somewhere.
Unfortunately seems there's no required field in tcx/course point format and each file I try are slightly different.
But I will try to handle the case when 'Time' is set, directly in the tcx loader (and then not run part of modify_course_points).
What's the case of adding start and end course points by the way ?
Hi @Ptosiek ,
As you have probably already noticed, if you include self.distance = self.distance / 1000 # [km] in the try-except block of the downsample, it will be correct.
(Downsampling is executed, but the try block that creates a cond using rdp is not executed.)
downsampling:1969 -> 1969
[ 0.001 0.388 0.546 1.925 3.665 4.186 4.665 5.006 5.084 6.906
7.541 7.759 7.954 8.864 9.025 9.033 10.76 10.777 10.796 10.821
11.474 12.522 14.521 14.553 14.846 15.356 15.87 16.409 17.583 17.726
17.746 18.804 19.387 19.399 19.552 19.912 20.044 20.719 23.058 26.22
26.344 27.861 29.689 30.574 31.723 31.904 35.885 35.987 39.675 61.057
61.078 63.428 63.582 63.592 63.633 63.977 63.981 63.987 64.415 64.795
64.8 65.346 65.479 65.765 66.871 67.058 67.062 67.159 67.691 67.714
87.125 87.283 87.67 87.702 87.733]
However, this is equivalent to not doing downsampling, so this code cannot be adopted.
Hi,
Yes it's just that downsampling is failing for that file (cf the PR I opened on crdp branch).
That's why I was saying that it's the combination of downsampling and calculation of distance after, that is problematic.
So most likely, we would be better off running modify_course_point before downsampling