mirror of
https://github.com/eclipse-sailing-analytics/sailing-analytics.git
synced 2026-10-02 18:33:54 +00:00
678 lines
49 KiB
HTML
Executable File
678 lines
49 KiB
HTML
Executable File
<!DOCTYPE html>
|
|
<html>
|
|
<head>
|
|
<link href="sailing-fontface-1.0.cache.css" media="screen" rel="stylesheet" title="Default stylesheet" type="text/css" />
|
|
<link href="start.css" rel="stylesheet" type="text/css" />
|
|
<link href="release_notes.css" rel="stylesheet" type="text/css" />
|
|
<link rel="shortcut icon" type="image/x-icon" href="/sap.ico" />
|
|
<title>SAP Sailing Analytics - Admin Console Release Notes</title>
|
|
</head>
|
|
<body>
|
|
<div class="logoAndTitlePanel">
|
|
<a class="sapLogo" href="http://www.sap.com">
|
|
<img class="sapLogoImage" src="/images/logo-small@2x.png" alt="SAP Website"/>
|
|
</a>
|
|
<div class="sailingAnalyticsLabelPanel">
|
|
<div class="sailingAnalyticsLabel">Sailing Analytics</div>
|
|
</div>
|
|
</div>
|
|
<div class="yield_content">
|
|
<div class="contentWrapper">
|
|
<div class="mainContent">
|
|
<h2 class="releaseHeadline">Release Notes - Administration Console</h2>
|
|
<div class="innerContent">
|
|
|
|
<h2 class="articleSubheadline">May 2017</h2>
|
|
<ul class="bulletList">
|
|
<li>The logic of the "Control tracking from start and finish times" check box now behaves slightly
|
|
differently. As before, a default start of tracking time is derived from the race start time
|
|
(currently five minutes before race start). Likewise, a default end of tracking time is derived
|
|
from the race finish time (the time when the blue flag was lowered, or more technically,
|
|
when a FINISHED race state was set in the race log) which is currently two minutes after
|
|
the race has finished. However, previously, when deviating start of tracking or end of tracking times
|
|
were set through other channels, such as received from TracTrac or set explicitly through
|
|
the administration console, new events would have been written to the race log, fixing the
|
|
start of tracking / end of tracking times according to the derivation rules.<p>
|
|
This logic has caused undesired effects and has therefore been removed. For example, when
|
|
an end of tracking time has been set explicitly through the administration console then
|
|
it may have been overwritten by a new end-of-tracking-time event appended to the race log
|
|
when the race is loaded again. Similarly, when a new start time was provided, an explicitly
|
|
set start of tracking time would have been canceled. With the new behavior, explicit settings
|
|
of start/end of tracking will remain untouched.<p>
|
|
For "Smartphone Tracking" the check box therefore now mainly controls whether or not a start/end
|
|
of tracking time is written to the race log when the user starts/stops tracking for the first time
|
|
through the administration console: when the tracking times are to be controlled by the race's
|
|
start and finish times, simply starting / stopping to track a race with the smartphone connector won't
|
|
set the start / end of tracking times.<p>
|
|
For the TracTrac connector, when the check box is set, as before messages will go out to TracTrac
|
|
when the race start / finish times have changed. The feedback from TracTrac will adjust the
|
|
tracking times as received by the connector, but no race log entries for the tracking times
|
|
will be created anymore.</li>
|
|
<li>A new type of leaderboard has been introduced: a regatta leaderboard with competitor elimination.
|
|
Such a leaderboard creates a view onto a regular regatta leaderboard and allows the user to
|
|
eliminate a subset of the competitors from its display. The scores of all remaining competitors
|
|
are taken from the original regatta leaderboard without modification, including all
|
|
corrections, penalties and the discarding rule, including the live ranks. This means,
|
|
in particular, that the ranks shown for a race in such a leaderboard are not contiguous in
|
|
case there are eliminated competitors. The score sum for each competitor is computed as usual.
|
|
For the regatta rank, a contiguous count is applied. This way it is possible to create
|
|
a new ranking for only a subset of the competitors; a practice common for championships
|
|
that want to publish a separate youth leaderboard, e.g., for all competitors under a
|
|
certain age.</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">April 2017</h2>
|
|
<ul class="bulletList">
|
|
<li><code>/gwt/AutoPlay.html</code> can be fully parameterized. Previously, only few of the
|
|
available settings for Leaderboard and RaceBoard embedded into this view were effectively passed via URL
|
|
to the views. <code>/gwt/AutoPlay.html</code> is now based on the settings framework so that specific
|
|
URL parameters may have changed. Please recreate your bookmarks if you are affected by non-working parameters.
|
|
</li>
|
|
<li>The leaderboard configuration dialog in the admin console has been updated. Now it is possible to configure
|
|
a leaderboard with the whole range of settings it supports.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">April 2017</h2>
|
|
<ul class="bulletList">
|
|
<li>Marks can now be given any valid CSS color. This will be considered also in the
|
|
SAP Race Management app where the mark will be shown in their actual color in
|
|
the "By Marks" course editor.
|
|
</li>
|
|
<li>Polar diagrams (also known as VPPs) will now be updated after importing wind.
|
|
</li>
|
|
<li>Competitors that the TracTrac connector declares as "non-competing" are consistently
|
|
ignored. This may include camera boats, jury boats and other moving objects that do
|
|
not represent competitor boats.
|
|
</li>
|
|
<li>Upgraded to TracAPI 3.6.3 which offers improvements regarding the identification of
|
|
marks and waypoints.
|
|
</li>
|
|
<li>A bug regarding the regatta filter setting for the tracked races list has been fixed.
|
|
The filter setting now survives a refresh cycle of the tracked races list.
|
|
</li>
|
|
<li>When using the TracTrac connector, identification of marks has slightly changed for
|
|
gates and lines. Before, the mark IDs were constructed based on the control point's
|
|
name. Now, the control point's ID plus a numeric suffic (1/2) is used instead,
|
|
providing uniqueness at the same scope that TracTrac provides uniqueness regarding
|
|
their control point IDs.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">March 2017</h2>
|
|
<ul class="bulletList">
|
|
<li>A more compact internal storage format for GPS and Wind fixes is now being used. Instead of a full
|
|
64-bit "double" value for all components such at latitude, longitude, speed over ground or course over
|
|
ground, "smaller" data types such as "int" and "short" are now employed. The reduction of accuracy
|
|
that this brings about is negligible given the accuracy of the tracking systems used. For example,
|
|
the latitude values are encoded such that while covering the full range from -90° to +90°, the
|
|
resolution is at 4.6mm. Similarly, speeds are represented in their compact form in such a way
|
|
that speeds up to 500kts can be represented at a resolution of 0.015kts.
|
|
</li>
|
|
<li>When a race cannot be loaded successfully through the TracTrac connector, e.g., because its boat
|
|
class does not match the regatta's boat class, the tracker is now stopped, and a SEVERE log message
|
|
is written, giving the reason for the failure to load the race. This gives administrators an opportunity
|
|
to correct any errors in the underlying data and try again. Previously, tracking such a
|
|
was not possible without a server re-start because the tracker continued to exist.
|
|
</li>
|
|
<li>The application's locale now switches based on the client's "Accept-Language" HTTP header field.
|
|
This means that the application as well as all its parts, including the administration console,
|
|
will show in the user's default language if supported, defaulting to English otherwise.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">February 2017</h2>
|
|
<ul class="bulletList">
|
|
<li>Wind data in GRIB format can now be imported in the "Wind" sub-tab of the "Tracked Races" tab
|
|
in the <tt>AdminConsole</tt>. When one or more races are being tracked, with a tracking time
|
|
interval that includes the time point(s) for which the GRIB data is valid, the wind data at
|
|
the resolution of the GRIB file is added as separate wind fixes with type "WEB" to the race(s)
|
|
selected, or to all races if no race is selected.<p>
|
|
Multiple GRIB files can be specified; this is even necessary if GRIB sources are being used where
|
|
the so-called "U" and "V" or "speed" and "direction" components, respectively, are provided in
|
|
separate files. The importer will merge the GRIB sources to produce wind readings with true
|
|
wind direction and true wind speed.
|
|
Note that large GRIB files can result in many wind fixes being added to the WEB source. Make sure
|
|
the GRIB files you use are adequate in resolution and region as well as adequate in time. Obtaining
|
|
a forecast 72h in the future makes little sense for an in-shore race starting in 30min.
|
|
</li>
|
|
<li>The REST service for wind (/sailingservice/api/v1/regattas/{regatta}/races/{race}/wind) now considers
|
|
the center of the course to calculate the COMBINED wind readings. Previously, all wind readings for the COMBINED
|
|
wind track as published through the REST API were equally considered, regardless of how far away a
|
|
wind sensor was from the course. Now, sensors closer to the course count more than those further away.
|
|
Furthermore, the time between two readings in the COMBINED wind track in the REST output has been
|
|
reduced from ten seconds to one second.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">January 2017</h2>
|
|
<ul class="bulletList">
|
|
<li>Filter boxes now support quoting phrases, such as <tt>"Race 2"</tt> to make them a single search term.
|
|
Previously, when entering <tt>Race 2</tt> this would match all lines containing <tt>Race</tt> as well
|
|
as all lines containing the digit <tt>2</tt>, such as it occurs in <tt>2015</tt> or <tt>2016</tt>.
|
|
Enclosing the phrase with double quotes as in <tt>"Race 2"</tt> will consider the full string in quotes
|
|
as a search term. In the unlikely case of searching for a double quote you can do that by prefixing
|
|
the double quote with a backslash character, as in <tt>\"</tt>.
|
|
</li>
|
|
<li>When changing the start/end of tracking times in the "Smartphone Tracking" tab, it is now possible
|
|
to "unset" one or both of these time stamps. Next to the date/time entry field these is now a
|
|
"Set" checkbox. When the date/time field is modified, the box is automatically checked because
|
|
it seems reasonable to assume that the user wants this change to be committed. When committing
|
|
an empty date/time field with the "Set" checkbox ticked, the <tt>null</tt> time stamp which
|
|
makes this an open tracking interval is committed and will override any inference that may be
|
|
made based on the race's start and finish time. When unchecking the "Set" checkbox, the previously
|
|
committed timestamp is revoked (regardless of the contents of the date/time field), allowing for
|
|
inference to take place if the regatta has been configured for tracking times inference.
|
|
</li>
|
|
<li>There is a new permission, <tt>DATA_MINING</tt>, which is now required in order to use the
|
|
<tt>/gwt/DataMining.html</tt> entry point and the related back-end service.
|
|
</li>
|
|
<li>Quoted filtering keywords may now contain leading and/or trailing space characters that are
|
|
considered when applying the filter. For example, if you have regatta names "Regatta I - 2017" and
|
|
"Regatta II - 2017" and you would like to filter for "Regatta I" then you now may enter the
|
|
search term "Regatta I " (with a trailing blank) which then will no longer match "Regatta II - 2017".
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">December 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>Partial replication is now possible. If the system property <tt>replicate.on.start</tt>
|
|
that controls automatic replication upon start-up provides only a partial comma-separated
|
|
list of replicables, the connection to the master server (configured by the other
|
|
replication-related system properties such as <tt>replicate.master.servlet.host</tt> etc.)
|
|
will be used to replicate only those replicables whose IDs are specified in
|
|
<tt>replicate.on.start</tt>. All other replicables will operate locally.
|
|
Usually, the <tt>replicate.on.start</tt> system property is controlled
|
|
by the environment variable <tt>REPLICATE_ON_START</tt> that is set in the <tt>env.sh</tt>
|
|
configuration file used during server startup and influenced by the server environments
|
|
from <a href="http://releases.sapsailing.com/environments">http://releases.sapsailing.com/environments</a>
|
|
and overridden by the user details provided to the instance through the AWS EC2 machinery.<p>
|
|
The Administration Console (<tt>/gwt/AdminConsole.html</tt> entry point) will now
|
|
show which replicables a replica replicates, both, on the replica's administration
|
|
console's "Replication" panel, as well as on the master's "Replication" panel, there
|
|
for each replica.<p>
|
|
The master will restrict broadcasting its operations to those replicables for which
|
|
at least one replica has subscribed. While the initial load is requested individually
|
|
for each replica and can therefore be tailored to the replicas requested, the operation
|
|
broadcast channel is not specific to any replica. It therefore contains the operations
|
|
of all replicables for which at least one replica has subscribed. Replicas receiving
|
|
operations for replicables for which they did not subscribe will simply drop those
|
|
operations (note, however, that the replica will still have to read the operations from the
|
|
channel before dropping; this way, registering a replica may have bandwidth effects for
|
|
other replicas). Similarly, "backward replication" from a replica to a master will only
|
|
take place for those replicables for which the replica has requested replication from (and
|
|
therefore also "to") the master.<p>
|
|
With this it is now possible to replicate only the Security Service, using ID
|
|
<tt>com.sap.sse.security.impl.SecurityServiceImpl</tt>, running all other replicables
|
|
in "master mode." This will let the instance share user, permission, role and session management
|
|
details with the instance from which the Security Service is being replicated while
|
|
having its own master objects for all other replicables, such as the sailing application
|
|
(RacingEventService), mail service or the polar data service. Note that with this feature
|
|
the server replicating another instance's Security Service will grant the roles and permissions
|
|
to subjects authenticated against that replicated Security Service. For example, if a user
|
|
has been granted the <tt>admin</tt> role by that service then the user has that role also
|
|
in all other server instances replicating that Security Service. Therefore, use this feature
|
|
with extreme caution. Keep in mind that in the near future we will extend the permissions and
|
|
role concept by the possibility to restrict permissions and roles to "scopes" such as an
|
|
event or a regatta or an account. See also
|
|
<a href="https://bugzilla.sapsailing.com/bugzilla/show_bug.cgi?id=3504">https://bugzilla.sapsailing.com/bugzilla/show_bug.cgi?id=3504</a>.
|
|
</li>
|
|
<li>The server can now optionally restore all races it had tracked the last time. This is
|
|
similar to a web browser's capability to restore the tabs the user had open when the browser
|
|
was terminated or crashed. To enable this feature, use the system property
|
|
<tt>restore.tracked.races</tt>, using the command line option <tt>-Drestore.tracked.races=true</tt>.
|
|
So far, the default for this system property is <tt>false</tt>, so by default, when the property
|
|
is not provided at all on the command line then the tracked races loaded last won't be restored,
|
|
and the server will start out with an empty set of tracked races.<p>
|
|
Note that the wind tracking properties, as set when initially tracking the race, are also restored
|
|
to their last state. If a live race has last been tracked with live wind tracking, with wind directions
|
|
being corrected by the local magnetic declination, then upon server restore the same live tracking will
|
|
be started again, including live wind tracking with the same declination correction settings.<p>
|
|
When the "Stop Tracking" feature is used, implicitly tracking wind will be stopped in case live wind
|
|
tracking had previously been requested for that race. This change is also considered during the restore
|
|
process where such a race will no longer receive live wind tracking upon restoring it.<p>
|
|
When a tracked race is removed from the server then it will not be restored anymore upon the next
|
|
server restart with the restore option enabled. When an entire regatta with a number of tracked
|
|
races linked into it is removed then the tracked races are removed as well and will not be
|
|
restored upon server re-start.<p>
|
|
The restore progress can be monitored using the JConsole or any other JMX monitoring tool. In the
|
|
<tt>com.sap.sailing</tt> category you will find the <tt>RacingEventService</tt> object. Among its
|
|
attributes there are now the two new ones: <tt>NumberOfTrackedRacesToRestore</tt> and
|
|
<tt>NumberOfTrackedRacesRestored</tt>. See the following two screen shots:<p>
|
|
<img width="100%" src="images/JConsoleNumberOfTrackedRacesToRestore.png"><p>
|
|
<img width="100%" src="images/JConsoleNumberOfTrackedRacesRestored.png">
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">November 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>When launching a server, a system property <tt>polardata.source.url</tt> can
|
|
be provided in order to specify a server base URL from where to import polar
|
|
data into the upstarting server. Usually, this would be the "archive" server's
|
|
base URL, such as https://www.sapsailing.com. Note that the exporting server
|
|
needs to already support this feature and the importing and exporting server
|
|
should be at roughly the same version to ensure binary compatibility for the
|
|
polar sheet data.
|
|
</li>
|
|
<li>In the <em>Tracked Races / Competitors</em> tab there is now a new button "Import Competitor"
|
|
that opens a dialog for selecting an import source. The Manage2Sail source is configured through
|
|
the same URL as used for the result importer. Select the regatta from which you want to import,
|
|
then check for which competitors there are matching / similar existing competitors. Single
|
|
selection on the left lets you map to one of the matching existing competitors. Ultimately,
|
|
select those competitors (including those you mapped to existing ones) you want to import.
|
|
Optionally provide a search tag for them which will be added to the new and mapped-to
|
|
competitors for easy retrieval later when selecting competitors to add to a regatta
|
|
or race.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">October 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>A regatta now has an additional property: "Buoy zone radius in hull lengths." It
|
|
can be used to determine the radius of the zone around the marks in terms of
|
|
hull lengths. This sets the default for the race viewer (RaceBoard.html entry point)
|
|
based on the hull length as known from the boat class.</li>
|
|
<li>When producing the QR code for the Race Management App's device configurations,
|
|
the access token parameter was not properly URL-encoded. In case the access token
|
|
contains a '+' character it is incorrectly decoded by the app, letting the authentication
|
|
fail. This issue has now been fixed in the AdminConsole, and the access token parameter is
|
|
now properly URL-encoded.</li>
|
|
<li>Tracked races can now also be filtered by the regatta to which they belong.
|
|
When selecting a regatta leaderboard, by default the table of tracked races will be
|
|
filtered by the regatta whose leaderboard was selected. The regatta filter can be
|
|
used in conjunction with the regular text filter field.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">September 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>When denoting a regatta for smartphone tracking, the "By Marks" course designer is
|
|
automatically selected if no active regatta configuration was set yet, or a warning
|
|
and question to the user is issued, strongly suggesting the use of the "By Marks" course
|
|
designer. Background: using the "By Name" course designer could accidentally delete a
|
|
valid course layout.
|
|
</li>
|
|
<li>Regattas now have an additional setting: "Control tracking from start and finish times."
|
|
With it, the start and finish times for a race as entered into the race log, e.g., through
|
|
the Race Management app, can be used by tracking connectors to control the tracking for
|
|
that race. So far, the TracTrac connector and the Smartphone connector have been
|
|
enabled. When a start time for a race
|
|
is received and the "Control..." flag is set, the tracking start time will be set to
|
|
five minutes before the race start time. Similarly, when the blue flag is lowered, signaling
|
|
that the race has finished, the tracking end time will be set to two minutes later.
|
|
This should make an operator's job easier when the race timing is maintained properly
|
|
through the race log, i.e., through the Race Management app.<p>
|
|
In turn, for the Smartphone tracking connector, start/end tracking times are recorded
|
|
automatically upon start and stop tracking actions only if the regatta is <em>not</em>
|
|
marked as "Control tracking from start and finish times." Background: with this it is
|
|
possible to start tracking for a number of races scheduled for a day and having the
|
|
Race Management app control the tracking times automatically.
|
|
</li>
|
|
<li>The "start of tracking" property on a tracked race now has to be set to a valid, non-empty value
|
|
in order for fixed to be accepted into the race. As before, an empty "end of tracking" value
|
|
means an open-ended interval, and fixes at or after the start of tracking time point will then
|
|
continue to be accepted.
|
|
</li>
|
|
<li>The device mappings dialog now shows the time point of the last fix received from each mapping
|
|
and has a convenient filter text box.
|
|
</li>
|
|
<li>Thread management has been improved. Fewer and more reasonably-designed thread pools
|
|
are now created, and thread priorities less than normal (for background operations) now
|
|
correctly map to operating system thread priorities, making foreground tasks more
|
|
responsive. The less excessive concurrency has furthermore healthy effects on memory
|
|
mamangement and garbage collection.
|
|
</li>
|
|
<li>Fixed a bug in the smart phone tracking course designer. When adding or removing marks
|
|
now, unsaved changes to the waypoints and control points tables are preserved.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">July 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>According to some change in a tracked races lifecycle, fix-tracking no longer depends
|
|
on tracking races via racelog event but is bound to denotation only. So fix-tracking
|
|
via smartphone apps or uploading tracking files can also be used in combination with
|
|
e.g. TracTrac.
|
|
</li>
|
|
<li>Because fix-tracking is now more flexible (see above), it is no longer restricted to
|
|
GPS-fixes.
|
|
</li>
|
|
<li>It is now possible to track fixes from Bravo foiling sensor devices, currently used in
|
|
Extreme Sailing Series events only. This kind of data can be uploaded via a new dialog
|
|
within the AdminConsole (Connectors > Smartphone Tracking)
|
|
</li>
|
|
<li>When a competitor is suppressed in a leaderboard, now the other competitors ranking
|
|
worse will be "promoted" by one rank per better suppressed competitor. This way, live
|
|
ranks will be correct if, e.g., a "Flexible Leaderboard" is used for a separate scoring
|
|
scheme for only a subset of the competitor.
|
|
</li>
|
|
<li>When entering a fixed position for a mark in the "Smartphone Tracking" environment it is
|
|
now possible to enter a time stamp for the fix. This way it is also possible to adjust
|
|
a mark's position to a fixed lat/lng for some time point in the past.
|
|
</li>
|
|
<li>A series within a regatta can now define a maximum number of discards applied in that
|
|
series. When combined with leaderboard-wide discards, generally discards can be distributed
|
|
across the leaderboard as needed, but restricted by the maximum specified for each series.
|
|
Leave the maximum empty to not provide any maximum. Setting to 0 will cause no scores to
|
|
be discarded in that series.
|
|
</li>
|
|
<li>An event now has a "Base URL" which should be used to enable useful e-mail notifications with
|
|
links embedded in them that lead to the correct server. If a notification is to contain
|
|
a link to a dedicated event server, the event cannot be reached through www.sapsailing.com,
|
|
and so if this generic link is used as a default, users will end up not finding the page
|
|
linked to by the notification.
|
|
</li>
|
|
<li>The checkboxes "Track Wind" and "Correct by Declination" are now switched on by default
|
|
for smartphone-tracked races
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">June 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>Some REST APIs have slightly changed. The /api/v1/leaderboards/{name} resource now
|
|
has the "netPoints" and "totalPoints" stuff right. The "netPoints" always refer to
|
|
scores which may be reduced due to discarding rules. Total points always refer to
|
|
the points before applying any discarding rules. Those numeric values for which so far
|
|
accidentally String types with double-quoted values were used have been changed to
|
|
numeric types, represented in the JSON documents without double quotes.
|
|
</li>
|
|
<li>It is now possible to use overlapping leaderboard groups in an event, such that one
|
|
leaderboard can be part of more than one leaderboard group of the event. This comes in
|
|
handy if there are different schemes by which the regattas or leaderboards may be grouped
|
|
and is particularly useful for large events for filtering the regattas in the event
|
|
overview. Please note that in case a leaderboard is part of a leaderboard group with
|
|
an overall leaderboard ("series scoring"), the leaderboard group with the overall
|
|
leaderboard must be provided as the first of the overlapping leaderboard groups in
|
|
the scope of the event.
|
|
</li>
|
|
<li>Earlier releases have introduced an issue with leaderboard configuration and with binding
|
|
tracked races to their leaderboard slots. When a filter is set for the tracked races list,
|
|
changing the leaderboard selection or changing the race column selection such that the
|
|
tracked race for a selected race column is not visible due to the filter, the connection
|
|
between the race column and the tracked race is removed.<p>
|
|
In order to reduce chances for failure, now at least changing the leaderboard selection
|
|
will de-select any selected race column, making sure that nothing needs to be selected
|
|
in the potentially filtered list of tracked races.<p>
|
|
However, trouble remains: changing the tracked races filter while having a race column
|
|
with a tracked race connected selected in the table on the left will unlink the race
|
|
column's tracked race. As a workaround, you'll have to either de-select the race column
|
|
in the left table before changing the filter, e.g., by Ctrl-clicking the race column
|
|
selected. Or you remove any filter text for the tracked races list before you change
|
|
the selection in the race column table. This will make sure that the race connected
|
|
to the race column that you may select next will be available for automatic selection.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">May 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>Smartphone tracking support has been improved. When starting to track a race that has no
|
|
start-of-tracking time set yet, the start-of-tracking time will be set to the time point
|
|
when tracking has been started. Similarly, when stopping tracking and no end-of-tracking
|
|
time is set for the race yet, the current time is set as the end-of-tracking time for
|
|
that race.
|
|
</li>
|
|
<li>Regatta structure import from Manage2Sail now takes the boat class name from the
|
|
regatta, not the division element, giving better results.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">April 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>In the "Race Manager App" regatta configuration settings, a new preference
|
|
"Activate result entry" has been added. It can enable or diable result entry
|
|
during or after the finishing phase in the Race Manager app. With this, it is
|
|
possible to configure up-front whether a race officer is offered the possibility to manage
|
|
results directly from the Race Manager app. This should <em>not</em> be used if an
|
|
external, official regatta management system is being used to capture and manage
|
|
the official scores.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">March 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>For smartphone tracking, added shortcut to start/stop tracking of
|
|
race to each individual race (play/stop button in action column).
|
|
</li>
|
|
<li>When starting/stopping to track a race using smartphone tracking the
|
|
tracking start/stop time is set to "now" if no time has previously been set.
|
|
</li>
|
|
<li>With the <b>MANAGE_MARK_POSITIONS</b> permission, users of the smartphone tracking feature can now
|
|
conveniently manipulate course mark positions from the <em>RaceBoard.html</em> entry point. When having
|
|
the permission, a new button "Edit Mark Positions" will be shown. Marks can then be selected from a
|
|
table, new fixes can be added and existing fixes can be moved. Note that the "Delete" menu item is
|
|
currently still disabled. Delete may be supported in future versions, though.
|
|
</li>
|
|
<li>The sailors info link is now also available for single regatta events in addition to multi regatta events that used to have this feature.
|
|
If a sailors info link is configured for events that are part of a series,
|
|
this isn't shown on the event page because the link to the series uses the same space in the UI and has higher priority.
|
|
</li>
|
|
<li>It's possible to configure language specific sailors info website links for events.
|
|
There is a default value that can be overwritten on a per locale base.
|
|
No sailors info link is shown for UI languages if there is neither a default link nor one for the specific locale,
|
|
even if there is one for another locale configured.
|
|
</li>
|
|
<li>The mechanism to handle RegattaOverview settings has been changed to a more generic approach.
|
|
This leads to slightly changed URL parameter names so that old bookmarks could be broken in a way
|
|
so that the actual shown set of races is different using the new version because the old parameters aren't correctly recognized.
|
|
All automatically generated links to this page in Home and AdminConsole have been updated to use the new parameter names.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">February 2016</h2>
|
|
<ul class="bulletList">
|
|
<li>Several improvements regarding the creation of race metadata (events, regatta, etc.) including:
|
|
automatic creation of default series, dialog for creating a default leaderboard group
|
|
</li>
|
|
<li>The RaceBoard URL Parameter "canReplayDuringLiveRaces" has been removed.
|
|
This parameter was used to allow users to trigger autoplay for live races on non-live points in time.
|
|
The permission "CAN_REPLAY_DURING_LIVE_RACES" and role "moderator" now grant this functionality to users.
|
|
</li>
|
|
<li>The "Manage Media" button in RegattaOverview is now bound to the Permission "MANAGE_MEDIA".
|
|
The Roles "eventmanager" and "mediaeditor" grant the "MANAGE_MEDIA" permission.
|
|
</li>
|
|
<li>The "Edit mark passings" button in RegattaOverview is now bound to the Permission "MANAGE_MARK_PASSINGS".
|
|
The Role "eventmanager" grants the "MANAGE_MARK_PASSINGS" permission.
|
|
</li>
|
|
<li>The user management page now provides a "Refresh" button to reload the user list.
|
|
</li>
|
|
<li>The user management page now also lists sailing roles and permissions in the respective suggest boxes.
|
|
</li>
|
|
<li>The "Edit Points" module is now bound to the Permission "MANAGE_LEADERBOARD_RESULTS".
|
|
The Role "eventmanager" grants the "MANAGE_LEADERBOARD_RESULTS" permission.
|
|
</li>
|
|
<li>There is now a UI element in the header of "Edit Points", "Admin Console" and "Races Overview" pages
|
|
that indicates the authentication and makes it possible to sign in/sign out without leaving the page.
|
|
The pages "Edit Points" and "Admin Console" will show a message instead of the page content
|
|
if you aren't autenticated or don't have the required permissions.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">October 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>The "RaceLog Tracking" panel was renamed to the more intuitive "Smartphone Tracking".
|
|
</li>
|
|
<li>Competitor and course information can now be copied independently from one race to another within a Smartphone-tracked leaderboard.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">November 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>Adding a competitor to a leaderboard or a regatta pre-sets the competitor's boat class
|
|
according to the leaderboard's / regatta's boat class.
|
|
</li>
|
|
<li>When done with creating a regatta, the user can have the corresponding regatta leaderboard
|
|
created with a simple click instead of having to navigate to the "Leaderboards" tab.
|
|
</li>
|
|
<li>Trim leaderboard and leaderboard group names during creation, removing leading and trailing
|
|
blanks. These names can occur in URLs, and trailing blanks in particular may be trimmed,
|
|
causing the objects to not be found.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">October 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>The "RaceLog Tracking" panel was renamed to the more intuitive "Smartphone Tracking".
|
|
</li>
|
|
<li>Competitor and course information can now be copied independently from one race to another within a Smartphone-tracked leaderboard.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">September 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>A new scoring scheme for elimination rounds has been added. It will first be used
|
|
at a major wind surfing event.
|
|
</li>
|
|
<li>The "Device Configuration" tab has been moved into a new top-level tab
|
|
"Race Committee App".
|
|
</li>
|
|
<li>Included magnetic declination data for 2016 already.
|
|
</li>
|
|
<li>Bug fix: in rare cases, adding several series to a regatta in one go swapped the order
|
|
of the series to be created. This has now been fixed.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">August 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>Race log tracking now allows administrators to set the start and end of tracking for a race.
|
|
Competitor and mark positions as well as wind data are filtered based on the start/end of tracking
|
|
intervals.
|
|
</li>
|
|
<li>Setting the boat class for a regatta and when creating a competitor has been unified and now
|
|
uses a suggest text box which makes suggestions based on all the boat classes known by the
|
|
application. In both cases can users now also enter a "free-form" boat class which is then
|
|
created by the server if not known yet. Note that for such boat classes no boat class icon
|
|
will be present when showing the regatta on the web page.
|
|
</li>
|
|
<li>Added boat classes Soling, Lago 26, Kielzugvogel, PWA (Professional Windsurfers Association)
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">June 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>An event an now have a "Sailors' Info" URL configured. If provided, there will be a button
|
|
displayed on the event's web page that navigates to this link. It can be used, e.g., to link
|
|
to official documents such as the notice of race, sailing instructions, weather information
|
|
or similar.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">April 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>Competitors can now have a flag image assigned. This image should ideally be
|
|
sized 18x11px. If such an image is assigned, it overrules the nationality flag.
|
|
Use this feature to provide club flags for sailing league events.
|
|
</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">February 2015</h2>
|
|
<ul class="bulletList">
|
|
<li>The Event panel now links the event name to the event page in the new design. The old "RegattaOverview"
|
|
link is now shown in the panel below, shown when selecting the event in the table above, called
|
|
"Event Overview."
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">December 2014</h2>
|
|
<ul class="bulletList">
|
|
<li>We added user management. The /gwt/AdminConsole.html entry point for a fresh server set-up uses
|
|
admin/admin as username/password. You can change the password in the "Advanced > User Management"
|
|
tab where also new users can be created. If you assign a use the role "admin" then the user will
|
|
be able to use the administration console. Stay tuned for a more sophisticated set of roles and
|
|
permissions to be added in the future.
|
|
</li>
|
|
<li>Reverse replication is now possible for selected events. When a replica instance receives a
|
|
modifying operation, such as a user logging in (creating a user session) or a wind fix being
|
|
entered through the Race Committee App, this change will be sent from the replica to the master
|
|
and from there be replicated to all other replicas attached.
|
|
</li>
|
|
<li>Starting a server with auto-replication enabled has been changed. The REPLICATE_ON_START environment
|
|
variable no longer is a Boolean value (True/False) but now has to list the replication services to be
|
|
replicated from the master. The default environments for replicas at
|
|
<a href="http://releases.sapsailing.com/environments">http://releases.sapsailing.com/environments</a>
|
|
show how this works.
|
|
</li>
|
|
<li>The "Connectors" category has a new tab in the administration console, entitled "Regatta Structure Import".
|
|
If your regatta management system happens to be <a href="http://manage2sail.com">Manage2Sail</a>
|
|
you can enter an event ID and show the list of regattas, then set defaults for how they shall be
|
|
created in the SAP Sailing Analytics. This allows you to import and create many regattas at once,
|
|
saving the laborious effort of manually creating them. Obviously, this can come in handy at large
|
|
events with regattas on many course areas in several different boat classes.
|
|
</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">July 2014</h2>
|
|
<ul class="bulletList">
|
|
<li>Replication has become much more robust and efficient. The initial load which used to be sent in a
|
|
single huge (although compressed) stream of data from the master to the replica(s) was hard to get
|
|
transmitted in the face of flaky and slow network connections. We've changed this: now the initial
|
|
load is transmitted as a sequence of messages using a message broker infrastructure. If a single
|
|
message doesn't arrive, it will be re-sent until it got through. The messages are buffered for several
|
|
minutes, so the initial load transmission can even survive and recover from severe network outages.<p>
|
|
|
|
For the incremental replication process, we added compression, making the transmission more bandwidth-efficient
|
|
and therefore quicker and leaner. In addition, we've cleaned up the protocol a little, avoiding the
|
|
sending of redundant data, adding to the effects of compression. Replicating five live races with
|
|
approximately 40 to 50 competitors each, with four active wind measurement units each, requires approximately
|
|
30kB/s of network bandwidth between master and replica.
|
|
</li>
|
|
<li>Events now have lots of new attributes, particularly start/end date and multimedia content URLs</li>
|
|
|
|
<li>Regattas can now be edited to <em>not</em> perform start time inference based on start mark passings.
|
|
Usually, when no start time is set by the race committee app or by the tracking provider or manually
|
|
through the administration console, the start time is inferred from the mark passings for the start
|
|
line. However, this can lead to unpleasant effects when the race committee aborts or postpones a race
|
|
and doesn't set a new start time for some period of time. When during this period one or more boats
|
|
cross the start line, a new start time would be inferred implicitly, showing scores in the leaderboard
|
|
and starting to compute all sorts of metrics. To avoid this, uncheck the checkbox
|
|
"Use start time inference from start mark passings" in the regatta create / edit dialog.</li>
|
|
|
|
<li>When creating a regatta in the administration console, the regatta name is now taken from the create
|
|
dialog's "Name" field as-is and is no longer automatically extended by appending the boat class name
|
|
in parentheses to the base name. This is important to know if you so far have created several regattas
|
|
within the scope of the same event by simply providing the event name and the boat class name, relying
|
|
on the administration console to extend the regatta name by the boat class name because now with this
|
|
strategy your regattas would all be named the same. If you want to continue using some base name and
|
|
see the boat class name after the base name in parentheses you will now have to add that to the "Name"
|
|
field yourself, as in "Kieler Woche 2014 (470)". With this change, you can avoid having special
|
|
characters such as "/" in the regatta name which used to be a problem in particular for RESTful web services
|
|
that use the regatta name as a URL element. Boat classes such as "B/one" and "J/70" traditionally
|
|
had issues with this. Now, the regatta can simply be named "My Event (J70)" instead, and web service
|
|
access is hassle-free. The boat class can still be called "J/70" which can be useful if the result
|
|
management tool or the tracking partner spells it that way.</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">March 2014</h2>
|
|
<ul class="bulletList">
|
|
<li>XML export of leaderboards now also taking into account competitors that haven't sailed a race but got a score</li>
|
|
</ul>
|
|
|
|
<h2 class="articleSubheadline">February 2014</h2>
|
|
<ul class="bulletList">
|
|
<li>Series name can be edited</li>
|
|
|
|
<li>Now one can add a new series to an existing regatta</li>
|
|
|
|
<li>Introduced new series scheme where competitors are scored contigously over all fleets</li>
|
|
</ul>
|
|
<h2 class="articleSubheadline">January 2014</h2>
|
|
<ul class="bulletList">
|
|
<li>New version of TracTrac connector that fixes issues with concurrent loading
|
|
of many races</li>
|
|
|
|
<li>Wind data can be imported from Expedition log files and from Igtimi WindBots</li>
|
|
|
|
<li>Competitors can be assigned fixed colors</li>
|
|
|
|
<li>Video files can be interactively linked to races</li>
|
|
|
|
<li>Admin Console consistently sorts alpha-numeric items such that
|
|
numbers embedded in text are sorted by their numeric values (Race 2
|
|
precedes Race 11)</li>
|
|
|
|
<li>AdminConsole has more consistent filter behavior as more columns are
|
|
used for filtering; some sorting options were added</li>
|
|
|
|
<li>Added a button to set the start time received of a tracked race. This time
|
|
isn't persistent, so it'll be forgotten after a server restart</li>
|
|
|
|
<li>Tracking a race with a wrong regatta is now forbidden</li>
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
<div class="spaceBar"></div>
|
|
</div>
|
|
</body>
|
|
|
|
</html>
|