-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: AIS relative motion vectors #323
Comments
What exactly do you mean with "relative motion"? |
The motion vector of the other vessels (ais targets) relative to own ship.
These are the vectors usually shown by a radar with ARPA that tracks contacts or as you would draw them on a maneuvering board to calculate CPA. Using them you immediately see when on collision course: the relative motion vector is pointing at you. And it tells you, how to change your course and speed to open up the CPA. more on this topic and theory can be found here (page 59) https://msi.nga.mil/Publications/RNMB and https://www.youtube.com/watch?v=8YUic4LdWFg There is no need for a separate view looking like a maneuvering board, the relative motion vectors could be displayed on the chart directly but visually distinguishable from true motion vectors (dashed). You just have to be aware of how to read these vectors, they do not show an actual track on the map. Switching to heap up mode is useful here as well (head up + range rings effectively give you a maneuvering board). RM vectors should be disabled by default to avoid confusion but can be activated by the user if they want to. A RM vector display is usually only available on commercial equipment and not on consumer products. So, it would be really nice, if AvNav supported this. It could look something like this. |
If you could point me to the relevant sections in the code, I would try to implement it myself. |
For the computations: |
Is there a way to load the sources directly into the browser without processing it through the gradle whatever thing? How can I change the code and immediately run and debug it in the browser? |
|
No. |
Thanks. OK, will try that. - It works, nice. Why do you draw dashed lines by drawing every single dash and do not use |
In the beginning I was trying to remain independent of the context drawing API to be prepared for different back ends (like WebGL or something OpenLayers specific). Maybe this could be changed as I don't think I will still go for any other drawing back end. |
So, here is my take on it. Have a look, please. It's a really cool project and nice to work and play with. Why didn't I find it earlier? Actually I had the idea of writing something like AvNav as well. It started with a server/proxy for tile based charts for use in OsmAnd, then I thought of adding own ship's position and other data to the map, but didn't have the time. Then I found AvNav. Someone already did the job. Very nice. Thank you. rmv.mp4 |
Thanks a lot. |
Thoughts on AIS data, updating, CPA computation.
example QM2 HDG=010 STW=0 SET=280 DFT=3 COG=280 SOG=3
|
drifting vessel with HDG!=COG displayed correctly
This is also helpful when you get visual contact with the target. You see how it is oriented (HDG) but you know how it actually moves over ground (COG). With HDG for COG this quickly gets confusing. |
For the HDG part: |
HDG stuff - What Aldebaran says is exactly what I said.
The problem in AvNav is, that both the target icon and the course vector use either HDG or COG (as selected in the settings) simultaneously. They always point into the same direction. This is wrong!
The true motion vector is the estimated track over ground for the selected time span, it is not related to HDG at all. Using HDG for its direction as in the example above yields a completely meaningless line that suggests a movement of the target that actually does not exist. This is why this is dangerous. It does not make sense to have a Please think about it and look at the images I posted carefully. |
Will just have a look... |
Yes and no, but this is no problem because you always have to see (COG,SOG) as vector. A zero length (or very short) vector has effectively no orientation, the value of COG with SOG=0 does not matter. This nonsense COG is an artifact of the polar coordinates. It's actually not wrong, it's just meaningless because SOG=0. The true motion vector displayed will be very short in this case, so the direction does not matter.
Yes, because it doesn't make sense, but COG as fallback would be ok.
It is, but indirectly. If the tug he describes goes astern, having the true motion vector point ahead is wrong. Ask him about it, I know what his answer will be. He focused on the orientation of the icon because it was aligned to COG, that was his complaint. The true motion vector was also using COG which is correct. He never wanted the TMV to be aligned with HDG. After introducing the useHDGasCOG switch and enabling it, not only the icon was aligned with HDG but also the TMV. This is wrong and doesn't match the situation he describes. He doesn't talk about the orientation of the TMV because it was correct before the HDG=COG option was introduced.
Can understand that, but what AvNav displays as true motion vector when using HDG for COG is rubbish and dangerous. Consider the consequences of this. I would not hesitate to fix this and already did. It's not a breaking change, it's broken. ;) You want to make AvNav as useful as possible with the data that is available. Superb! But it doesn't make sense do display data, just to display something even if it is wrong. IMHO it's better display nothing at all, than to display wrong data. Computing true motion vector from HDG is only correct if HDG=COG
These assumptions are almost never satisfied, especially not
I cannot think of any convincing argument for computing the true motion vector from HDG, it's just wrong. If you don't have a (COG,SOG) vector, you cannot display a true motion vector, end of story. Better don't show a TMV at all than a wrong one that suggests a movement of the target that is not the case and may lead to a collision. It's a bit like the problem with the SailInstrument. Here the calculations were also wrong, COG/SOG/HDG/STW were carelessly mixed. If you don't have HDG/STW one can fallback to COG/SOG to compute ground wind instead of true wind, assuming COG=HDG (otherwise TWD wrong). That is somehow ok, and first of all it is less dangerous because wind speed is not used for collision avoidance. |
It's a pretty interesting experience to see how different people implement these calculations, but no one gets it completely right. There's also a plugin for SK that computes derived data, it also contains errors. I would really like to test products from B&G, Raymarine, Garmin..., feed them with test data and see what they show. Here the power of open source comes into play and many people can check and contribute to the code. This is great. The root cause of these errors seems to be the common misconception that a ship moves over ground into the direction of it's heading. This is almost never the case and furthermore it is not the general case. There is current and leeway. Everyone holding a yacht master or the like knows how to work out a course to steer, usually graphically on paper. You calculate the (true) heading you have to hold to reach your destination at a certain bearing. This heading is usually not equal to the bearing, this is the reason for performing these vector gymnastics in the first place. So, it should be obvious that a ship doesn't move over ground into the direction of it's heading, but still it is commonly assumed. A graphic like in #323 (comment) is what you actually want the chartplotter to show to you and this is nothing special or uncommon, this what happens in reality all the time. |
Here an example of AvNav (with TMV from HDG) vs OpenCPN (has no such option), both fed with the same data.
|
I hope all of this in convincing enough to remove the use-HDG-as-COG-option.
|
I just checked again in the code. Maybe I missed some points... Would be helpful to have some testing data available that shows a situation where AvNav does not compute it like this. |
Additional remark: |
Does this describe how it currently is or how it should be? I observed (examples above) and found in the code that the course vector (aka true motion vector) is computed using HDG if this is selected in the settings.
That the course vector of ais targets is computed using HDG. That's what I want to point out all the time. Or did I talk rubbish and got confused between your original code and my changes? That's possible. |
Maybe I really mixed your and my changed code. Sorry for the noise then, but then this is clarified for sure now. |
I readded the HDG/COG setting but added a fallback to COG if there is no HDG. Sorry for the confusion, but now this is topic has been discussed thoroughly. So, if someone asks... |
Thanks for testing and looking into it.
Yes, it appears confusing at first, when you are not used to the concept of RMVs. Did you watch the YT video? 👆 To read them the following helps.
|
Sorry I was not clear. The concept of the relative motion vectors is clear. And I like it. For the rot I'm not really sure if we should like to have it like this. Maybe a small indicator close to the ship symbol would be better. |
|
I added optionally curved TMVs and RMVs. The estimated true and relative track is drawn including the rate of turn information and shows up as a curved line if the target is turning. This is very valuable information in situations when a big ship is turning slowly. This is currently not possible to see in avnav since there is neither a turn indicator nor is the rate of turn displayed in the AIS data. You would have to observe how a target changes its course between AIS updates. The curved paths can show you potentially dangerous situations right away long before a CPA warning is displayed (CPA computation doesn't consider ROT). example
on the right you see how the vessel is changing course, but keep in mind that it is played back 20 times faster ☝️ curved-mvs.mp4 |
is implemented |
It would be nice to have the possibility to display relative motion vectors for AIS targets. The transformation is trivial and the usefulness for collision avoidance is great. All commercial radar/AIS systems support that.
There could be a shortcut for switching between true/relative. Or one could enable relative vectors additionally in the AIS settings and show them as dashed lines. Additionally there could be a marker on the relative motion vector at the location of the CPA.
The text was updated successfully, but these errors were encountered: