You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I looked into the code of the CPA calculation to see how it is done and what the state attributes front, back, pass, done actually mean.
This may also serve as a kind of documentation to others because I did not find any details on this topic in the docs.
The implementation in NavCompute.computeCpa and NavCompute.computeApproach does two things, it computes
the point where both tracks cross (our track and the target's track, ground tracks)
the point, where both (we and target) reach minimum distance to each other, the CPA
It also computes the times needed to reach these points. Negative times mean, that the point has already been passed.
This is looks very nice, I checked the equations, perfect!
Knowing this, I looked at the code that uses this data. There I spotted some minor issues and changed some things.
The CPA computation takes the position, course and speed of two vessels and linearly extrapolates their tracks to determine the crossing point and CPA. This assumes the initial conditions are given at the same time. But actually it uses the current data of our ship and the older AIS data for the other ship, which can be several minutes old. So, there should be a correction for this difference in time. This can be done easily by pushing the AIS data forward to current time and so I did. (The same applies to the relative motion vectors, I fixed this as well in 3f7b350)
DCPA (distance of CPA) was set to current distance to the target if distance<DCPA (this is actually impossible but might have happend due to the missing correction for the time difference) or if TCPA<0 (time to reach CPA as already passed.) and TCPA was set to 0. IMHO this is a very confusing workaround, because CPA is well defined and changing the computed value like this confuses the user. I removed that.
If CPA could not be computed DCPA=TCPA=0 was set, I removed that, too. If it could not be computed, CPA is undefined and not 0.
The warning flag on an AIS target was set when DCPA and TCPA go below threshold, but also for TCPA<0. I changed this to require TCPA>=0 to excludes passed CPAs, the distance can only increase after passing CPA. The flag was only set on the target with smallest TCPA, I changed this to set the flag on all targets below threshold to highlight all of them as dangerous.
I also changed the sorting of targets in the AIS target list. When sorting by DCPA or TCPA, passed CPAs (TCPA<0) are pushed down in the list and targets with the warning flag set are pulled up.
I added sorting by priority, it combines DCPA and TCPA values relative to the configures thresholds and made it the default. So, targets with small DCPA and small TCPA are listed first. Targets with TCPA<0 are sorted by distance.
Furthermore I tweaked the fields shown in the AIS list and info page. I changed the unit of TCPA to minutes, a single number is easier to grasp, more compact and minutes seem to be the appropriate unit here.
The state attributes front/back where assigned when we pass the track crossing point before/after the target, but it was not checked if we already have passed it. I changed this as follows, which make more sense IMHO.
front = we will cross track of target in front of target
back = we will cross track of target astern of target
pass = we have crossed the track of the target already or crossing point could not be calculated (stationary target)
done = we have crossed the track and have passed CPA
The text was updated successfully, but these errors were encountered:
I looked into the code of the CPA calculation to see how it is done and what the state attributes
front, back, pass, done
actually mean.This may also serve as a kind of documentation to others because I did not find any details on this topic in the docs.
The implementation in
NavCompute.computeCpa
andNavCompute.computeApproach
does two things, it computesIt also computes the times needed to reach these points. Negative times mean, that the point has already been passed.
This is looks very nice, I checked the equations, perfect!
Knowing this, I looked at the code that uses this data. There I spotted some minor issues and changed some things.
The CPA computation takes the position, course and speed of two vessels and linearly extrapolates their tracks to determine the crossing point and CPA. This assumes the initial conditions are given at the same time. But actually it uses the current data of our ship and the older AIS data for the other ship, which can be several minutes old. So, there should be a correction for this difference in time. This can be done easily by pushing the AIS data forward to current time and so I did. (The same applies to the relative motion vectors, I fixed this as well in 3f7b350)
DCPA (distance of CPA) was set to current distance to the target if distance<DCPA (this is actually impossible but might have happend due to the missing correction for the time difference) or if TCPA<0 (time to reach CPA as already passed.)
and TCPA was set to 0. IMHO this is a very confusing workaround, because CPA is well defined and changing the computed value like this confuses the user. I removed that.If CPA could not be computed DCPA=TCPA=0 was set, I removed that, too. If it could not be computed, CPA is undefined and not 0.
The warning flag on an AIS target was set when DCPA and TCPA go below threshold, but also for TCPA<0. I changed this to require TCPA>=0 to excludes passed CPAs, the distance can only increase after passing CPA. The flag was only set on the target with smallest TCPA, I changed this to set the flag on all targets below threshold to highlight all of them as dangerous.
I also changed the sorting of targets in the AIS target list. When sorting by DCPA or TCPA, passed CPAs (TCPA<0) are pushed down in the list and targets with the warning flag set are pulled up.
I added sorting by priority, it combines DCPA and TCPA values relative to the configures thresholds and made it the default. So, targets with small DCPA and small TCPA are listed first. Targets with TCPA<0 are sorted by distance.
Furthermore I tweaked the fields shown in the AIS list and info page. I changed the unit of TCPA to minutes, a single number is easier to grasp, more compact and minutes seem to be the appropriate unit here.
The state attributes
front/back
where assigned when we pass the track crossing point before/after the target, but it was not checked if we already have passed it. I changed this as follows, which make more sense IMHO.front
= we will cross track of target in front of targetback
= we will cross track of target astern of targetpass
= we have crossed the track of the target already or crossing point could not be calculated (stationary target)done
= we have crossed the track and have passed CPAThe text was updated successfully, but these errors were encountered: