63 lines
2.7 KiB
Markdown
63 lines
2.7 KiB
Markdown
|
# Development and Design notes
|
||
|
|
|
||
|
|
|
||
|
|
## WIP, Puzzles and TODO
|
||
|
|
|
||
|
|
* rename Track to Gpx, it deals only with parsing.
|
||
|
|
* can we lose this "if isJust lat && isJust lon && isJust ts" wart?
|
||
|
|
* probably we should store points in a more efficient form than
|
||
|
|
a singly-linked list
|
||
|
|
|
||
|
|
* boring stuff like auth[zn]
|
||
|
|
* need a web server in haskell that
|
||
|
|
* [done] accepts file upload and parses the gpx file
|
||
|
|
* [done] serves the data points in some format elm can digest easily
|
||
|
|
* [done] need a database of some kind so the data can be saved
|
||
|
|
* [done] frontend can get data from backend
|
||
|
|
* [done] for DX, backend can serve the js files needed by frontend
|
||
|
|
* [ad hoc] we only have yesod-core, may need other parts as well
|
||
|
|
* [done] detect and refuse uploads which overlap an existing time frame (http 409) so that we can script upload-all-the-tracks.
|
||
|
|
* could we converge the Point and Trkpt to make sql better?
|
||
|
|
* [done] move Store into Point
|
||
|
|
|
||
|
|
* on timeline, show power, cadence, speed, height, ascent (checkboxes)
|
||
|
|
* done some
|
||
|
|
* need speed and ascent
|
||
|
|
* need checkboxes
|
||
|
|
* zoom gesture on graphs causes map to adjust
|
||
|
|
* zooming map causes graphs to adjust
|
||
|
|
* threshold display: adjust vertical slider to show time spent at
|
||
|
|
or above a particular intensity. Indicate somehow the length of
|
||
|
|
each continuous stretch at that intensity
|
||
|
|
|
||
|
|
## Sessions
|
||
|
|
|
||
|
|
|
||
|
|
The calendar (TBD) displays sessions. a session is a sequence of
|
||
|
|
measurements describing a ride or a race or a trip. we can extract
|
||
|
|
potential sessions from the data by looking for series of points not
|
||
|
|
more than x (10?) minutes apart, but the rider may override
|
||
|
|
that. Consider: I ride solo to the start point of a group ride, join a
|
||
|
|
tandem partner to do the group ride, then ride solo home. There is not
|
||
|
|
necessarily ten minutes between them.
|
||
|
|
|
||
|
|
After a new track is uploaded, we look at all the points covered by
|
||
|
|
draft sessions, and rearrange them to cover the new points. Draft
|
||
|
|
sessions are then presented to the rider who may approve them as-is -
|
||
|
|
perhaps involving other data collection as well ("perceived effort" or
|
||
|
|
"which bike setup was this" or ...) - or chop them up using
|
||
|
|
information they have but that the computer doesn't
|
||
|
|
|
||
|
|
Aside: in theory we don't even need draft sessions and we could have
|
||
|
|
the rider create sessions from the calendar page. However, that's a
|
||
|
|
GET and might be slow if it has to figure out what all the sessions
|
||
|
|
would be every time someone looks at it. So the draft session is just
|
||
|
|
to precompute that and make the view easier
|
||
|
|
|
||
|
|
The summary of a session is for display on the calendar and might
|
||
|
|
change depending on the nature of the training effort. e.g. for a
|
||
|
|
long slow ride we show total distance, for interval training we show
|
||
|
|
time spent in HR zones ...
|
||
|
|
|
||
|
|
-
|