This commit allows every ride file to specify a set of "metric overrides":
values to use in place of those for RideMetrics we would otherwise compute.
The most gratifying immediate result of this change is that we can associate a
"skiba_bike_score" metric override with each Manual CSV file, thereby
eliminating the need for a bogus "bs" parameter in RideFilePoint.
In the future, though, we can also save these overrides to a GcRideFile using
a syntax something like this:
<override>
<metric name="skiba_bike_score" value="100"/>
<metric name="average_speed" secs="3600" km="30"/>
</override>
(Note that average_speed needs to store time and distance in order to
aggregate properly.)
Then we can add a dialog that allows the user to override the computed value
of a metric for any given ride. For example, if my HRM was on the fritz
during a ride, I could estimate my average HR and override that metric.
(We might want to show these overrided metrics in a different color, so that
it was clear they weren't the computed values.)
Finally, I think we could actually use this feature to eliminate the Manual
CSV format altogether, and just use GcRideFiles without any samples or
intervals, but with metric overrides for all the available metrics.
RideFile data points now include lon and lat members for the longitude
degrees and latitute degrees from the source ride files. As a result
most of the RideFile readers now set longitude and latitude to zero for
each data point, except for:
* Gc Format Files - now support read/write
* Wko Format Files - now support read
* Tcx Format Files - now support read (smoothed if smart recording)
Although there are no features within GC at this point in time that use
positioning data this may change over time. Critically, as users save
files to the new GC file format whilst adding interval data it is
important that this positioning data is not discarded before new
features arrive.
Replace handcoded binary search in RideFiletimeToDistance() method
in RideFile with lower_bounds, since it is more efficient. The
distanceToTime() method has been removed since it is not used.
Eventually, I'm going to remove interval as a member of RideFilePoint, and
only use RideFileIntervals. But I have to rework a bunch of other code first,
so for now the two will coexist.
These were part of an earlier attempt at a GC-specific ride file
format. They aren't in use now, and they'll be replaced by the new
one when it's done.
created a method to find QSettings (settings.h) and stopped it from leaking.
The leak looked like this...
==7800== at 0x4C2726C: operator new(unsigned long) (vg_replace_malloc.c:230)
==7800== by 0x64FD232: (within /usr/lib/libQtCore.so.4.5.0)
==7800== by 0x64FDB62: QSettings::QSettings(QString const&, QString const&, Q
Object*) (in /usr/lib/libQtCore.so.4.5.0)
==7800== by 0x4738E5: PfPvPlot::setData(RideItem*) (PfPvPlot.cpp:361)
It offers to split at any time gap over 30 seconds and also at any interval.
If the time gap is over 5 minutes it defaults to checked, otherwise it
defaults to unchecked.
Anywhere you check, it will split the ride at that point overwriting the or
original ride with a shorter one and creating new rides after the split points
The original would get renamed with a .bak so it could be recovered.
