OpenCPN Beta Version 3.3.2410 Released

[bdbcat]

Gilletarom...

"Rotated Mode"

Appears only in the Menubar->Navigate menu if the user has rotated the chart display using the "[" or "]" key.

Dave

[bdbcat]

cagney....

re:
Options->Ships->Own Ship->Advance route waypoint on arrival only.

A bit complicated, but here goes.

First, a definition.

The "normal range" is defined as:
The distance from ownship to a line which passes through the destination waypoint and is at right angles to the current route segment

In the route console display, this "normal" range is the second number shown. It is only shown if it differs from the actual range by more than 10%. By simple geometry you can see that the "normal range" will always be less than or equal to the actual range to the waypoint.

The simple idea of the "normal range" is that it allows you to cut a corner by steering manually if you want to, and the waypoint will advance automatically even though you have not actually gotten within {arrival radius} of the waypoint.

An artist could draw a nice picture for the Wiki....

OK, keeping that in mind:

When following a Route O normally and traditionally decides to advance to the next waypoint if:

1. The "normal range" is less than the declared arrival radius.
--or--
2. Ownship is moving away from the target waypoint, and has been for more than two seconds.

Option two helps you if you really want to cut a corner by a large distance, in such a way that the "normal range" will never be less than {arrival radius}. We want to automatically advance in this case.


So, the new option simply disables (2) above.

This allows for the case where sailing upwind to the waypoint, for example. In the process of tacking, or catching a fish, or whatever, you may easily be temporarily moving away from your target for a short time. You may even have to jibe or wear if you are a square rigger.. You don't want to advance the waypoint automatically in this case, since you will just have to correct it manually.

Testing of these features is difficult statically, since we need to calculate actual velocity over a specific time period.

I think Caesar uses this underway recently, and may comment more.

Pictures would help. Any artists around with time?

Thanks for digging into the documentation so aggressively. We all appreciate it.

Dave

[cagney]

Dave

Thanks, that makes i clearer.

With "Advance route waypoint on arrival only" active the route waypoint can still be advance with the boat quite some way from the active waypoint, and much further away than the arrival radius. In other words the boat has not yet arrived.

This whole thing would be easier to understand and explain if

1. The "normal range" is less than the declared arrival radius.

instead read

1. The "actual range" is less than the declared arrival radius.

As it is, "arrival" does not necessary mean arrival.

Anyhow.... of course I can see the problem that this solves when tacking to reach a mark.

And Jon was right, it is difficult to summarize this correctly, in a good name for the option.

Thomas

[Mollymawk]

"Advance route waypoint on arrival only"...

No, I hadn't used this (though I will now enable it for next time I use a programmed route, which is rarely).

I actually hadn't fully understood what it did (or rather, hadn't fully understood O's existing behaviour.

Now that I do understand, I have two observations:

- The current title is very misleading. It says that the waypoint will only be advanced on arrival. Yet, as I understand from Dave's explanation, it will in fact also be advanced when passing the waypoint.

- If the option only disables advancing the waypoint when sailing away from it, why not change the title to something along the lines of "advance waypoint when moving away"? (And invert the logic so the current behaviour is with it ticked, and unticking it disables that behaviour.)

- Route advancement is tricky to get right. But one idea: maybe the default could be only to advance if moving away from the point and towards the next point?

Let's have input from more people, please, now Dave has explained it nicely for us!

Caesar

[Mollymawk]

Un-killable dialogs...

Dave, here reliable way to reproduce this for me, let me know if it works for you:
1. double-click to open Object Query
2. switch to another app, switch back to O
3. close Object Query by pressing OK (not with the title bar close button)
4. at this point, you cannot open the Object Query dialog again if you try to
5. switch to another app, switch back to O
6. the Object Query reappears...

Here are my findings so far:

- Clicking OK does not call S57QueryDialog::OnClose. Therefore the dialog does not get destroyed, even though it is closed.
Closing with the titlebar button does call OnClose.

- When re-activating the app, the Object Query dialog (though it was closed before deactivating) is included in AppActivateList when it is cycled through by MyFrame::OnActivate (chart1.cpp:2775). Thus that function calls Show() on the dialog and it reappears.

- I note that a similar or identical re-showing-windows routine appears in both MyApp::OnActivateApp and MyFrame::OnActivate. If I remove the ifdef __WXOSX__ block from MyFrame::OnActivate, everything seems to work fine.
Maybe we can just remove it?
If not, when is it needed?

- Regarding problems with the OK button: on most platforms (and certainly OS X) this button is not compliant with Human Interface Guidelines anyhow. The dialog already has a close button. 'OK' here is meaningless; it's just a modeless info panel.
Can we just remove this button? (The same applies to the OK button in the AIS query window.)

Caesar

[Hakan]

Originally Posted by Mollymawk

Un-killable dialogs.............'OK' here is meaningless; it's just a modeless info panel.............
Caesar

Molly...
In Win I can't say it's meaningless because it's big and easy to catch with the mouse on a swinging boat. The very little tiny system close button, [X], is a real challenge to hit.
Håkan

[bdbcat]

Caesar...

I'm looking into the Mac dialog problems.

I think your suggestion re: OnActivate Frame is good. Just checking my notes, etc. It looks like this is an area where wx3.0 is greatly improved over wx2.8, so goofy workarounds in OCPN are becoming less necessary.


But meanwhile, I note that modeless dialogs with "OK" buttons are not uncommon in Windows and linux land. They may annoy all those non-modal Mac users, I guess.
But I sort of think of the "OK" button as a "Dismiss" command in Win and gtk. "Close this window because I don't want to see it anymore."

And, that little red X is hard to hit....

Lets revisit this for 4.2

Dave

[bdbcat]

Caesar...

I pushed a commit which looks like it will fix the OS X dialog issues.
Works OK on Lion. Please test and comment.

Still some shaky looking code here, #ifdef'ed for OS X. Needs a good hard look for the next Release....

Thanks
Dave

[Hakan]

Win XP, 3.3.2410 pull: 2014-12-14.
Dashboard, Grib, WMM, Launcher and VDR are activated.

The mouse right click function "Hide this chart"/"Show this chart" in quilt mode is no longer usable. There are two different scenarios: First using OpenGL and second OpenGL is of.

1)
When I hover over the chart bar and right click the "Hide this chart" box is shown for a fraction of a second and then disappears again. In this scenario the chart info box is shown with text.
2)
When I hover over the chart bar and right click, the box is shown but sometimes without text. When the mouse is moved to reach the box it disappears. The chart info box is indicated but mostly without text.

Sometimes when I have switched OpenGL on and off a couple of times OCPN hangs and can’t be closed in a normal way.

There is though a rather new right click menu item "Hide this chart" but if used we have a "Catch 22", since there is no way to again show the chart.

I’ve tested it on two different Win PCs and it’s the same result on both.


I can't say which commit introduced this behaviour since I haven't test the function for a time.
Håkan

[Hakan]

Hi, again..
Now on Ubuntu 12.04, the same source version as above, >> last commit: "Merge pull request #223 from Ptizef/master"
The above malfunction with the chart box "Hide this chart" function is not a problem in Ubuntu but to check it I'd to load my raster charts and that was not that nice:

After catch build, and rebuild, the OpenGL pictures for raster charts are just blobs, CM93 is as usual. Without OpenGl all raster charts and CM93 are as usual but the tools menu disappeared.
My lof file is attached.
Håkan

[rgleason]

Just git fetch & compiled:

Build succeeded.
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\ALL_BUILD.vcxproj" (default t
arget) (1) ->
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\plugins\dashboard_pi\dashboar
d_pi.vcxproj" (default target) (8) ->
"C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.vcxproj" (default tar
get) (10) ->
(ClCompile target) ->
c:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\math.h(632): wa
rning C4005: 'M_PI' : macro redefinition [C:\Data-Dart\Up-Soft\Navigation\opencp
n-git\build\opencpn.vcxproj]
..\src\chcanv.cpp(754): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(754): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(754): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(755): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(755): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(755): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(756): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(756): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(756): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(757): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(757): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(757): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(768): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(768): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(768): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(769): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(769): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(769): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(770): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(770): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(770): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
..\src\chcanv.cpp(771): warning C4805: '|=' : unsafe mix of type 'bool' and ty
pe 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn
.vcxproj]
..\src\chcanv.cpp(771): warning C4805: '|' : unsafe mix of type 'bool' and typ
e 'int' in operation [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\build\opencpn.
vcxproj]
..\src\chcanv.cpp(771): warning C4800: 'int' : forcing value to bool 'true' or
'false' (performance warning) [C:\Data-Dart\Up-Soft\Navigation\opencpn-git\buil
d\opencpn.vcxproj]
25 Warning(s)
0 Error(s)

[rgleason]

Gilletarom...
"Rotated Mode"
Appears only in the Menubar->Navigate menu if the user has rotated the chart display using the "[" or "]" key.
Dav

-Exclusive radio button selections in Options
* North up ---> shows north arrow upper left
o Course up ----> shows read arrow upper left
o Rotated ---> shows rotated arrow from north up (left or right)?

When shortcut key affects orientation of chart(s) the appropriate mode is shown.
Don't "hide" the rotated condition, please.

PS: Bdcat, I know you have put this to bed, but perhaps a small improvement after 4.0 is out?

[bdbcat]

Rick...

We will leave it as-is for 4.0.

It is funny, the "[]" rotation key was "discovered" only recently. I think no-one (except Sean) will really use this option. I can't see much value in real life.

And I suspect it was implemented primarily in order to test OpenGL performance.

Dave

[Gilletarom]

Hello Dave Hello to all developers,

I am still working to improve the translations in French but also in OpenCPN plugins.

As usual, I am against the fact that, during the reading of plugins language files, after reading language files from the heart of O, the translation of an item of a plugin replaces the previous translation of the same item present in O or another plugin.

There is in particular a word that appears very often with different meanings from one use to another. It is the word "Course". In some cases, it seems that the developer using "Course" has meant "COG", in other cases, it seems that the developer has meant "Magnetic course."

In addition, I understand "Heading" meant "Magnetic course."

Is it possible that the developers definitely agree on the following rule:
- Each time that the word "Course" is used, it will designate the "COG"
- Whenever the word "Heading" will have meaning "Magnetic course."
- Never the word "Course" will be used instead of "Heading" and vice versa.

This rule would greatly facilitate the work of translators. And if it could be implemented before the release of the next stable release, that would be great.

It might be finding similar rules in other words, but it would take probably too much extra work code. So I just ask the implementation of "Course" and "Heading".

Thank by advance. Gilletarom.

[rgleason]

There may be some accepted Nautical Dictionary that we should all be using, and perhaps it should be referenced in the manual (maybe it already is referenced). Thank you Gille for keeping us on track . Maybe Thomas has one he uses?

Some references:
Heading. The course to steer; as in: Change heading to 090°.
HEADING - The direction in which a vessel's bow points at any given time.

"In navigation, a vehicle's course is the angle that the intended path of the vehicle makes with a fixed reference object (typically true north)", and "The track or course over ground, is the actual path followed by the vessel" [italics added] and "The angle between heading and track is known as the drift angle or crab angle".

single word requests - In navigation, what's the difference between bearing, heading, direction, and course? - English Language & Usage Stack Exchange
*A vessel or vehicle points where it points, that is the heading. It's course is the actual line it travels. So if your boat is facing north (navigational 0 degrees) and the currents are easterly (moving TO the east) thus pushing you off-track to the eastside of your intended track, you have to compensate for the current. This is done by steering your bow slightly into the oncoming current, in this case to port or slightly west of north. In a current of approximately 2 knots, you might have to compensate -10 degrees off bearing (your destination), say heading 350 degrees, so that your Course can remain due north at 0 degrees, where your "bearing" lies. That 10 degrees is a "drift" or "crab" angle, named that since crabs walk sideways, kind of like your ship is doing by heading differently from your true course/bearing.

Wikipedia
Course (navigation) - Wikipedia, the free encyclopedia
navigation, a vehicle's course is the direction over the ground the vehicle is currently moving in.
The heading is the direction to which the "nose" of the vehicle is pointing. Directions (course to steer, course, heading and route course) are typically measured clockwise from north, either true or magnetic, in degrees from 0° to 360°, following compass convention (0° being north, 90° being east, etc.). For land based vehicles (like cars) heading and course are typically identical, but for aircraft and vessels the action of wind and current may cause the two to differ significantly.[1]