82 lines
3.2 KiB
Markdown
82 lines
3.2 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
|
|
|
|
## Multiuser
|
|
|
|
I am minded to avoid writing any of that user registration/authn stuff
|
|
and just use a third-party SSO thing like Authelia to cover password
|
|
resets etc. Installation instructions will include "set up a reverse
|
|
proxy for this app which sends Remote-User and other Remote-* info as HTTP
|
|
headers".
|
|
|
|
|
|
However, we do still need some changes
|
|
|
|
1) trackpoints are no longer unique by time
|
|
2) also sessions
|
|
3) we want a `users` table with id and name/fullname/email to tie them back to
|
|
4) if there is no userid for the current Remote-User header, make one
|
|
|
|
|
|
|
|
|
|
## 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 ...
|
|
|
|
-
|