sailing-analytics/TODO

Axel
====

 - implement risk assessment: 1) risk of getting too close to layline in top sector; 2) risk of getting
   passed by successors due to wind shifts; in all this consider wind patterns (how shifty / gusty is the wind?)

 - understand how to add layers on top of Google Map and use this to visualize, e.g., wind field or risk

 - improve look of boats in Google Map; consider using canvas, draw to a canvas and use the result as marker image
   in map in order to display boat direction properly

 - for WithID objects use their ID, particularly in Mongo  

 - Test adding waypoints to an existing course using TracTrac server and see if events are transmitted.

 - test disconnecting before the 60s are over and then let the poller run into the 60s timeout and ensure
   it gets along with the already cleaned-out structures

 - add test cases for leaderboard sorting rules in case of ties

 - add test cases for leaderboard columns with untracked races in conjunction with max points
   and score overriding

 - add test cases for leaderboard with untracked races with score correction that need to
   count for discarding

 - Use wind estimator to feed another wind track

 - make manuevering time a parameter coming from the boat class and use it in hasDirectionChange to
   consider that some boats turn faster than others

 - 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.

 - allow a WindTrackImpl to receive multiple Wind objects with equal time stamp but different position

 - implement a smart incremental update capability for leaderboard

 - allow a column to specify its preferred sorting order (ascending / descending)

 - consider a per-user preferences page where leaderboard columns can be personalized at runtime

 - construct a frame/panel containing leaderboard, event/race selector and TracTrac 2D client.
   The TracTrac time line shall influence what is shown in the leaderboard.

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

 - auto-reconnect a leaderboard to its tracked races; this would require that the connector
   parameters required to track a race are encapsulated and stored with the leaderboard

 - 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

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

 - mark position entry capability, supporting "lost mark tracker" use case

 - refactor DAOs to use getters/setters and encapsulate LeaderboardDAO ranking logic so it's safe

 - 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.

 - Check if this is a bug: when a competitor is selected on the map (e.g., with a mouse-over)
   and the competitor does not show (yet) in the ranking list, it seems that the tool tip on
   the map is not shown. Does the lack to find the competitor in the list result in an
   exception?

 - 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...). When done, clean up (among others) the CompositeCollection/CompositeIterable
   and Pair/Triple clones.

 - 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. Consider introducing
   a configurable "Boat Model" for each boat class where rules for smoothening and maneuver detection
   can be configured per boat class. This can become helpful when we have to decide whether what seems
   like two contrary maneuvers following each other immediately can really have happened like this.

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

 - SwissTiming connector

 - ManyPlayers collaboration: widgets, UI integration, GPS and wind data integration

 - 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.

 - Consider renaming knotspeed field to currentSpeedOverGroundInKnots in showboatpositions service

 - 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