Ocpn-Draw and Boundary

[Hakan]

Jon.
Confirmed! Very nice. And new exiting features as well.

Thanks
Håkan

[rgleason]

Jon, I am finding it hard to keep up with you guys! I have compiled it and just tried it briefly it looks very interesting. I need to expllore it more but will have to do that later.

It is now on

Opencpn Beta Win File Thingie rguser rgpass

Look in directory 4.1.1108 PI Win
for ocpn_draw-0.4.522-ov4.1.1108

You will also find files for
Watchdog
Weatherfax

Will try & test ocpn_draw more extensively later! Thank you Jon!
Looking very interesting.

[jongough]

Rick,
Just to keep you on your toes I have put up another patch, 555, which makes Boundary Points work the same as Boundaries, i.e. they can be "Exclusion", "Inclusion" or "Neither". If they are "Exclusion", when you have range rings showing and at least one range ring, then the range ring will be filled in. If they are "Inclusion", then the same will apply, but a boarder will be drawn round the range ring. If they are "Neither" then all you will get is range rings.

I have updated the JSON message that is passed back to requests for if a point is in a boundary to include the "BoundaryObjectType" which can be "Boundary" or "Boundary Point" and the "BoundaryType" which can be "Exclusion", "Inclusion" or "Neither". This will allow the Watchdog plugin to use these messages for both anchor watch type events and "keep out's".

I think I have all the items that people requested done now. Just possibly a bit more tidying up of the interface and icons.

Jon

[Hakan]

Jon
Excellent work you've done! Nice coding and a very good result.
I've tested the most, except Watchman connections, on Windows 10 and XP and also built on both VS2010 and 13.
My own primary use will be EBL in connection with my radar and boundaries with text notes for mussel growth extensions here around.
Many thanks
Håkan

[rgleason]

Jon,
The plugin is working well. I should give it another comprehesive test today or tomorrow, but I did git fetch and compile this morning, so I have the lastest.
I noticed you added a delete to DR just last cycle, great.

This is good, I need to test it more. My watchdog sound alarms are not working in Windows, do they work for you? I left several messages for Sean about this.
In the compile README there are no notes requiring inclusion of portaudio, and watchdog compiles fine, also watchdog does find the GUID.

I have updated the JSON message that is passed back to requests for if a point is in a boundary to include the "BoundaryObjectType" which can be "Boundary" or "Boundary Point" and the "BoundaryType" which can be "Exclusion", "Inclusion" or "Neither". This will allow the Watchdog plugin to use these messages for both anchor watch type events and "keep out's".

I had a couple of thoughts about your new DR tool which I think is very useful.
There are a couple of ways to think about entering a DR:
1. Set the parameters including direction and then hit ok
2. Set the parameters for intermediate waypoint and enter the direction with a temp wp for defining direction.

There are also a couple of alternatives that might be very useful once the DR string has been laid down:
1. Right click: Rotate DR string by moving endpoint
2. Right click: Rotate DR string by moving start endpoint.
Maybe these are the same choices just dependent on proximity?

Another might be to extend or stretch the DR Object from either end.
1. Right click: Stretch DR string by simply adding (or subtracting) incremental wp segments as defined by the mouse location, keeping the direction the same.

I need to test the Inclusion and Exclusion alarms more for Boundary and Boundary Points with Rings and while doing that make some better screenshots for the manual.

Then I need to add these features to the manual.

Its turning into a great user toolbox!
Boundaries, Boundary Points with inclusion and exclusion, EBL, DR, Text points. Thank you Jon. Also Hakan, thank you for your help too.

I've uploaded the latest compile to
Opencpn Beta File Thingie rguser, rgpass

4.1.1108 PI Win directory.

[rgleason]

Another right click selection for DR string that would be very nice is
"Move entire DR string."

[jongough]

Rick,
I have just tried under windows and the watchdog is not working for me. It does not seem to be firing the message to OD to check for inside or outside boundaries. It works under linux, so I am not sure what is going on. I will have a quick look.

For DR, isn't the whole point to say how fast you are going, the direction you are going to see where you think you will end up? Making it more than that is rather like route planning. You can move individual DR points by right clicking and selecting move, but this will rather destroy the real meaning of the DR plot. If there is a need for a more general planning tool, then that could be added, but I would need to know more details about what is required and what to do with the resultant objects. It is quite possible to put out a route based on the DR object (this is not done currently and would require a bit of work, but it would be possible), or any other path type object, I would just need to know the specification of the output.

I would like to stop making major (?) changes to the plugin and get it settled in so that it is ready when the next stable version of OCPN is released. I think that more input from the other users is needed, otherwise I am concerned that the tool will become too complicated (it probably is getting that way already) for general users. Perhaps Dave or Pavel can provide some input as to what should/shouldn't be added. After all Dave is the one that wanted this as a general drawing tool.

Jon

[rgleason]

Jon, I agree we want it to be ready. Also you've programming like crazy and are probably read to put down the pencil for awhile and do something else. Your project certainly took on a life of its own!
I am perfectly happy to wait for others comments and ideas, requests which I think will be in ways which ask for a little more flexibilty to adjust the DR, but I may be proven wrong. I do think we need to use it in practice and learn more.

[rgleason]

Thank you Jon. I hope many others will start using this tool

[rgleason]

Jon, I found a rendering problem when OpenGL is on, because the inclusion "center" area gets rendered with hatch, when it should not. Please see attached. I hope you can fix it. Thanks.

[rgleason]

Sean and Jon,

I moved the boat inside the "Boundary Point Inclusion" example.
Then copied the Guid from "Boundary Point Inclusion" properties and pasted that Guid into Watchdog > Configuration > Edit.
I then tried the Watchdog button to get Guid from the Boundary Point Inclusion example. It got the correct Guid. This was with opengl on and off.

However, the alarm notice is, as you can see, the "Anchor is outside the inclusion area"

Also the alarm is still not sounding.

I have recompiled both Ocpn_Draw and Watchdog this morning with fresh git, and have used yesterday's compile of opencpn with fresh opencpn.lib for both plugins.

I think it the alarm has something to do with portaudio, but first we have to get the reversal of outside and inside alarms fixed. Then deal with the audio in Windows. By the way, the audio for windows, was a problem before the reversal of outside and inside cropped up.

What happens in Linux?

[rgleason]

I am also wondering why the lines for boundaries arent rendered, yet the Boundary Points do have lines. It seems to be independent of opengl on or off. Is it possibly that the line is rendered first, then the pattern is rendered thus covering the lines?
Or perhaps for the boundaries, the pattern has to be just inside of or outside of the line depending on inclusion or exclusion?

I think I mentioned this once before. Jon has exhausted himself trying to fix this, so I think a fresh view by someone like Sean if he has the inclination might be helpful. Or some suggestions to fix it. Thanks.

[rgleason]

In the main Beta Ocpn 4.1.1108 thread, I get the sense there is a rush to get the bugs out, particularly mapping, and issue. Why not make sure there aren't any bugs? I think that is going to take more time, also while making sure, there are other things that need to be confirmed and done, like some additional features, plugins and documentation which also take time.

[transmitterdan]

Originally Posted by rgleason

In the main Beta Ocpn 4.1.1108 thread, I get the sense there is a rush to get the bugs out, particularly mapping, and issue. Why not make sure there aren't any bugs?

It is logically impossible to prove any non-trivial software system is free of bugs. What I think we need are regression testing of all features. There are many features of O that require specialized hardware thus they only get tested by the few that have the equipment. If each hardware dependent feature had low level data creation capability like VDR then creating a regression test suite would be at least conceivable. But O is so rich feature wise and has so many hardware platforms to support that we reach a place where just finding all the bugs is more difficult than fixing them.

VDR is a good regression testing tool but it bypasses the internal data collection code (e.g. UDP/TCP NMEA data input). So bugs in the low level data input code is not included. A separate server program that played out the IP packet data could solve that and it would not require any plugin as the server would be indistinguishable from the real hardware.

Sorry for hijacking this thread but I don't know where to discuss this topic. Perhaps what is needed is a dedicated set of regression testers and tool sets.

[rgleason]

Dan. I think I understand part of this rekated to nmea and vdr, and having a server, but what is regression testing? I agree it is more difficult negotiating multiple platforms.