sailing-analytics/TODO

Axel
====

 - consider multi-select in race tree view to initialize set of race columns

 - support Up/Down buttons to fix the ordering of configured race columns

 - Finish a first draft version of a GWT admin and leaderboard UI

   * "top" display, with time slider
   * leaderboard page (scrollable!) (still missing the leg details; add a +/- button at the top
     of each column to expand/collapse; implement a smart incremental update capability for leaderboard)
   * adjustable delay and time per leaderboard
   * edit mode for carry, disqualifications / net / total point adjustments
   * consider a per-user preferences page where leaderboard columns can be personalized at runtime
   * mark position entry capability, supporting "lost mark tracker" use case

 - clarify how to marshal exceptions across a GWT/RPC call properly

 - allow a user to set a display name for a competitor that may differ from the name that
   the tracking provider uses for the competitor

 - why isn't all memory released when the last race of a series is untracked? Does this have to
   do with the new leaderboard design? It probably should; a tracked race should only be eliminiated
   if no more leaderboard is referencing it; but then it should mercilessly be GCed.

 - Estimate wind not only based on a snapshot in time but also on a time interval, looking for
   maneuvers. Assuming that the wind doesn't change radically, averaging over an n seconds interval
   with n, e.g., being 30s, maneuvers should help in detecting wind direction.

 - Use wind estimator to feed another wind track

 - Fix issue with CellTable not updating propertly after an editing fails on the server and after
   reverting a score correction to "" which should show the uncorrected net points again

 - come to a reasonable code sharing architecture between GWT client and server logic.
   Example: distances, bearings etc. which is currently handled in com.sap.sailing.domain.base
   may also be useful in the client. However, these classes are not subject to GWT compilation
   (and may not pass...).

 - allow for tail length customization

 - display advantage line in Google map

 - Need to adjust PartialNavigableSetView to work on any ordered sequential structure

 - Make threshold for track smoothening configurable. Currently, we have millisecondsOverWhichToAverage.
   This is also used as response to getMillisecondsOverWhichToAverageSpeed. Probably, we should at least
   additionally have a common way to eliminate impossible or highly unlikely fixes. This could rather be
   a configurable speed threshold. Once the outliers have been eliminated, smoothening in terms of
   weighted averaging around the time point requested should happen, based on an acceleration model
   that eventually could be specific to the boat class. The acceleration model would tell us how to,
   e.g., based on splines, interpolate and smoothen what remains from the fixes.

 - When a getTrackedRace(...) call is launched for an event/race where it becomes evident that
   the race won't show up (e.g., because the event is removed or no longer tracked), unblock
   any calls to TrackedEventImpl.getTrackedRace(...), e.g., by allowing for a check on the TrackedEvent
   that indicates that the race being waited for won't show up anymore.
   Clean up tracked races automatically if no connection can be established; currently, these
   tracked races never show up because they wait forever for their race course definition

 - Implement refined version of isValid in GPSFixMovingTrack taking into account the
   speed as contained by each individual fix

 - Add user authentication and authorization as well as a role model. Typical roles: spectator (anonymous
   and identified), moderator, administrator

 - Refactor the way the DomainFactory concept works, under the assumption that we'll have another
   connector for SwissTiming and VirtualEye. Our domain model including the Tracked... stuff should remain in place.
   Therefore, the link between the domain objects RaceDefinition, Leg, Course and Event with their
   tracking counterparts such as TrackedRace, TrackedLeg, TrackedLegOfCompetitor etc. should remain
   unchanged. However, the TracTrac-specific things such as the mapping from TracTrac's client objects
   (Competitor, Race, Event, Route, ControlPoint) to our domain model counterparts needs to be specific
   to the connector. Ideally, the SailingServiceImpl wouldn't have to know anything about TracTrac.
   Clarify also, where in the com.sap.sailing.server bundle we need dependencies on particular
   tracking connectors.

 - Distribute wind data to their respective races; capture expedition wind not by race/event anymore because
   wind is already recorded by time and position; when seeking wind information, look for information
   closest in time/space; consider throwing NoWindException if certain thresholds are crossed

 - Launch Expedition wind capturing upon startup because it should no longer be event/race-specific

 - consolidate time point defaulting for servlet REST APIs

 - Now that we can update Course's waypoints, consider creating a RaceDefinition right upon
   receiving the Event/Race from TracTrac, using an empty list of waypoints. This may simplify
   the entire life cycle of RaceDefinition objects.

 - Improve Mongo-based tests by using Mongo transactions instead of waiting for prior transactions to complete


Simon
=====

+ Make "Stop" button work such that race and thread disappear from the Python runtime

+ Allow users to override net points / total points; enter disqualifications etc.

+ Leaderboard umbauen auf Timeslider support (dazu liefert Axel stabiles start und finsh)

+ Animation Mode (3 sekunden, ...)

+ Build wizard page for initial configuration

+ Wind expedition listener bei addrace automatisch konfigurieren
+ Wind tracking einschalten für prod für laufende Rennen
+ Einstellbar: Threads sofort starten (Wunsch: Checked=True)

+ Total Points einbauen

+ Wind sofort anzeigen

+ Current Race speichern damit iPhone das nutzen kann
+ iPhone UI implementieren