<waypoint> describes a waypoint in a dive profile. A waypoint always marks a change in the course of a dive profile modelled by a dive simulation program, or a new set of data recorded during a real dive by a dive computer. Changes (events) are:
an alarm given by the dive computer,
a decompression stop announced by the dive computer,
an updated CNS value,
an updated OTU value,
the setting of a (new) value for the maximum oxygen partial pressure (when diving with a rebreather),
a new by a dive simulation program calculated oxygen partial pressure,
the use of another breathing gas at a certain depth,
a new tank pressure value,
a new value of the water temperature,
a new value of a device's battery charge condition,
a new compass heading,
a change in the "leading tissue",
a new value for the calculated No Decompression Time.
All these changes occur at a certain depth at a unique moment. Therefore <depth>, and <divetime> must be given in every <waypoint> statement (exception: the calculation of an ascent profile — see below).
May be a dive computer — e.g. to save memory — is not storing every in principle recorded parameters with every new sample, but only when its value did change the actual one (e.g. water temperature which normally changes only slowly). But when converting the dive profile into UDDF, in every waypoint all parameters recorded by the dive computer should appear to avoid irritations. This should be done, regardless of whether a respective parameter changes from one waypoint to the next, or not.
From one <waypoint> statement to another, the parameters vary linearly.
Neither from physical (decompression calculation) nor mathematical (shape of the dive profile) point of view it makes sense to use a non-linear function for the depth values, because the behaviour of a diver is non-deterministic — "chaotic" — (from previous waypoints one cannot conclude to the next one). Therefore, a dive profile approximation via a spline or other, non-linear function will never give enhanced accuracy, or understanding.
The same is valid for the other parameters. Again, it makes no sense to assume non-linear behaviour.
Of course, it's in the programmer's sole discretion to offer/try other interpolation methods. :-)
For example, if descending with a uniform velocity of 5 metres per minute down to 20 metres, only two <waypoint> statements are necessary to entirely describe the descent profile:
<!-- the first <waypoint> statement in a profile MUST ALWAYS -->
<!-- be the depth 0 metre, and the time 0 seconds as well as a -->
<!-- <switchmix> statement to determine the breathing gas -->
<waypoint>
<depth>0.0</depth>
<divetime>0.0</divetime>
<switchmix ref="air"/>
</waypoint>
<waypoint>
<depth>20.0</depth>
<divetime>240.0</divetime>
</waypoint>
Of course, the above described descent could also be modeled as follows:
<!-- the first <waypoint> statement in a profile MUST ALWAYS -->
<!-- be the depth 0 metre, and the time 0 seconds as well as a -->
<!-- <switchmix> statement to determine the breathing gas -->
<waypoint>
<depth>0.0</depth>
<divetime>0.0</divetime>
<switchmix ref="air"/>
</waypoint>
<waypoint>
<depth>5.0</depth>
<divetime>60.0</divetime>
</waypoint>
<waypoint>
<depth>10.0</depth>
<divetime>120.0</divetime>
</waypoint>
<waypoint>
<depth>15.0</depth>
<divetime>180.0</divetime>
</waypoint>
<waypoint>
<depth>20.0</depth>
<divetime>240.0</divetime>
</waypoint>
For the whole descent takes place with a uniform velocity of 5 m/s, the three middle <waypoint> statements can be omitted — they provide no additional information; in a graphical representation of the profile they wouldn't be visible (as long as they are not marked otherwise :-) ). Dive simulation programs should store profiles with the least necessary number of waypoints. Dive computer store time/depth values in certain intervals (e.g. 20 seconds), therefore a profile logged by a dive computer may contain a lot of <waypoint> statements.
If in between a change occurs, e.g. water temperature varies, this event has to occur inside a new waypoint (without this change of water temperature still only two <waypoint> statements are necessary, as descent takes place with uniform velocity):
<!-- the first <waypoint> statement in a profile MUST ALWAYS -->
<!-- be the depth 0 metre, and the time 0 seconds as well as a -->
<!-- <switchmix> statement to determine the breathing gas -->
<waypoint>
<depth>0.0</depth>
<divetime>0.0</divetime>
<switchmix ref="air"/>
<!-- if temperature values are to be given in the following, -->
<!-- it's the best to start with it in the first <waypoint> -->
<temperature>283.15</temperature>
</waypoint>
<waypoint>
<depth>10.0</depth>
<divetime>120.0</divetime>
<!-- thermocline at a depth of 10 m -->
<temperature>278.15</temperature>
</waypoint>
<waypoint>
<depth>20.0</depth>
<divetime>240.0</divetime>
</waypoint>
Events, which occur at same time at same depth must be given in the same <waypoint> statement. The appearance of more then one <waypoint> statement one after the other with same depth/time values is not allowed.
Inside the parent elements (<ascent>, <descent>, <inputprofile>, and <samples>) <waypoint> must be given. Because the simplest possible dive profile consists of three waypoints (beginning of dive at the surface, descending with uniform velocity to the maximum depth, ascending with uniform velocity to the surface) at least three <waypoint> statements must be given in every <samples> section. Modeling a descent profile, at least two waypoints (beginning of dive at the surface, and descending with uniform velocity to the target depth) must be given.
It's not allowed to omit the waypoints at the surface (beginning and ending of dive).
The authors know that many dive computer manufacturers refuse to store these two waypoints ([time = 0, depth = 0], and [time = end of dive, depth = 0]) together with the profile data in their devices. This may be due to the fact that a dive computer in principle is able to detect the beginning of a dive only by a depth greater than zero metres, and also the end of a dive is recognised only as the last waypoint recorded with a depth greater than zero metres. Here, the dive computer should allow to start the dive one interval before detecting descending, and also should allow to end it at the surface one interval after the recording of the last detected depth greater than zero metres. For the sake of "simplicity" the manufacturers often do without this (although the respective visualisation program of a manufacturer shows the beginning of the dive at [time = 0, depth = 0], and the end at the surface... — this means, the visualisation program tacitly adds these two not stored waypoints to the dive profile). Because the data of a dive profile described with UDDF shall be consistent, the two waypoints at the surface at start and end of dive are compulsory in UDDF. If necessary, an application program has to add these two waypoints if an uploaded dive profile is to be stored in UDDF format. The original, recorded dive profile is not falsified by this procedure. Everyone knows that a dive starts and ends at the surface! :-)
In case the recording device isn't using a constant sample rate for storing the waypoints, after the last recorded waypoint a "fair" ascending time shall be applied for the ending of the dive.
Calculation of ascent profiles,
Calculation of tissue saturation on the basis of a profile with different breathing gases, or breathing gas changes
:
When calculating ascent profiles (see <calculateprofile>) the different changes
of breathing gases (in case) at certain depths can also be modeled via <waypoint> elements
(<mixchange> -> <ascent> -> <waypoint>).
Of course, it's not possible to set the time in this case. Another special feature is the calculation of tissue saturation on basis
of a dive profile with different breathing gases, or changes of the breathing gases respectively. Also for this task it's necessary
to provide information about the breathing gas changes separately from the real profile data via <waypoint> elements. Treating
these jobs it's not necessary to set <divetime> elements inside <waypoint>.
<ascent>, <descent>, <inputprofile>, <samples>
<alarm>, <batterychargecondition>, <calculatedpo2>, <cns>, <decostop/>, <depth>, <divemode/>, <divetime>, <gradientfactor>, <heading>, <measuredpo2>, <nodecotime>, <otu>, <remainingbottomtime>, <remainingo2time>, <setpo2>, <switchmix/>, <tankpressure>, <temperature>
<ascent>, <descent>, <inputprofile>, <samples>