OpenTracksApp
Possible improvements on the Statistics graphs/plots of recorded tracks
Is your feature request related to a problem? Please describe.
The value of pace is difficult to read precisely from the graph as the y-axis limits are way to far from the average:
- it's not possible to zoom in the y-axis direction
- it's not possible to hide other signals (for example: elevation)
The green/blue color legend assigned to Elevation and Speed/pace is barely distinguishable with a light theme and eye protection (night filter) on.
Describe the solution you'd like
Plots of Elevation & pace from recorded tracks - either by time or by distance - could be improved in the following way:
- allow scaling and limit setting of the y-axis for better visualization
- make use of a dual y-axis for decoupling the scale of the two signals: for example you could plot the elevation on the left-hand y-axis and the pace on the right-hand y-axis, still using the same x-axis (time or distance)
- click on the legend entry toggle hide/show of the associated signal. A user may want to hide a signal if it does not display relevant information.
- would be super nice to have a light low-pass noise filter on speed/pace raw data.
Additional context
May be related to:
- Charts: allow to hide elevation #1297
- Something (scale?) wrong with elevation graphs #1241
- Hairline for graphs #1596
- Allow rounding elevation scale domain #795
App version v4.16.1 installed from f-droid on android 10 and used for tracking running sessions.
Any improvement of the diagrams would be nice. Currently, no library is used (aka everything implemented in OpenTracks).
@dennisguse I wanted to jump into this thread, rather than have everything in the PR, so my apologies for the potential notification bombardment.
Do the maintainers of this project have a preference for a charting library that they'd be interested in using? I would not be opposed to experimenting with something like https://github.com/patrykandpatrick/vico or just directly using Jetpack Compose as a basis for generating slightly nicer charts and opening a PR, but I also don't want to step on anyone's toes if they already have something else in mind for this app.
The charts are more a convenience feature - usually data evaluation is done on a computer using software like https://github.com/SamR1/FitTrackee or https://www.goldencheetah.org/
If you want to work on this and try something out: have fun!
Regarding libraries: not a strong fan to using libraries that are outside of Android's main line. The challenge is that those are usually not long-term supported and then you need to migrate to something else. For the charts, however, I would be fine using a third-party library. One idea would be to leave the original charts in place (make them inaccessible by the user), so they can be re-enabled again in the future.
Jetpack compose requires Kotlin and OpenTracks is completely in Java. And I don't see a point in mixing both languages or migrating to Kotlin. There are enough other things that provide user value first ;) (like #1954) or cleanups (like #1834).
PS/ At some point I was even thinking about removing the charts completely...
PPS/ Another option would be to use the DashboardAPI and render the charts in another application (similar to OSM Dashboard).
Ah, I see what you mean. And yep, I should have checked the language compatibility haha :)
re: your PS - do you think that's for maintainability? I ask because I use this app specifically for tracking my heart rate, and seeing how the last 5-7 minutes went (and whether or not I maintained the HR zone I was shooting for) is very helpful for me. I was interested in at least adding a couple of useful features to this area, and hunting for a faster, easier chart solution. If in the long term you think this whole area might go away however, I'd rather spend my efforts elsewhere :)
@grobolom that sounds like a problem the charts would not necessarily be well suited for. At least not the ones that we have the moment as those are way too small to be easily readable while training.
What about adding a new tab with proper UI for heartrates?
PS/ charts may go away if the maintenance effort becomes too high. At the moment, they are okay ;)
Hmm - that's not a bad idea. A dedicated HR chart would definitely make things easier. On the other hand, I could make several relatively simple (I hope) changes that would make them much more useable:
- add a setting to default the zoom to the last X seconds (60/120/180/240/300)
- update the code that calculates the Y index to draw more 'tightly' around the data, so more of the chart space is used for relevant information
Between the two above elements and the ability to disable the other lines on the graph, I think it would make it quite useable without needing to rebuild the charts entirely. I'm happy to mess around with it and open a PR, and if it's not ideal then we'll reject it and do something else :)
I think logarithmic scale for the pace might be useful, lets say a stop while running causes a spike in the pace of 100 min/km, then most of the interesting part is squashed in the lower tenth of the screen.
Also an option to smoothen the graphs would be nice.
Just chiming in on the smoothing suggestion which i think would be a nice feature to have.
What you would likely want is some form of lowess/loess smoothing. Basically it's similar to a moving window average.
This could also be a possible solution to smooth gps elevation sufficiently to use it for elevation gain.
Unfortunately I don't have the skills myself to implement it but I maybe the info will help.
