OpenCPN Version 2.4 Beta Build 612

[bdbcat]

Ahoy (again), OpenCPN'ers...

OpenCPN Version 2.4 Beta Build 612 will soon be available for download from opencpn.org.

Monitor the opencpn.org Downloads page to find and download the latest Beta version.....

Source is available now on sourceforge git repo.

Changelog
170. Correct cm93 Longitude 0 Viewport calculation
171. Add some translate strings in ais.cpp
172. Small conditional touchups for Mac build

Release Beta 2.4.612

Notes:

172. I will soon have some news/instructions for a workable Mac build of 2.4.612. Please stand by.
How many Mac capable Beta testers do we have? Any?

Sorry for the 611 glitch
Good Luck

Dave

[Netsurfer]

Hi testers ...

Windows version is now available for download.

Donwload link: http://opencpn.de/sites/default/file....612_setup.exe
Download page: Download OpenCPN | Official OpenCPN Homepage

Thanks Dave!

Gunther

[motorbaad]

The issue with direction pointers showing the wrong way in shipping lanes, has not yet been solved. As this is a matter of safety i think it should be corrected before the next stable release.
XP SP 3, CM 93/2 2009.

[bdbcat]

motorbaad....

Unfortunately, this is not fixable to everyone's satisfaction.

The "recommended route centerline" feature contains no information regarding the TSS structure. They are completely independent features.

The little arrows on the track centerline feature are not meant to indicate direction at all.

The best compromise may be to modify the symbology for the route centerline to either a)duplicate or b)entirely remove the little arrows from the symbolized line. At least this will eliminate the visual disparity.

Comments?
Dave

[cagney]

What "motorbaad" don't like is the way the arrows are pointing in RCRTCL.
Even having them pointing the "correct way" would not be right either, as there is no guarantee what so ever for ships tracks in relation to the recommended track. The best solution in my mind is to use the same symbols as for RCTRC, which is basically the same thing. For an example go to position -10.759011,141.056174 at the western approaches to "Prince of Wales Channel" in the NE Gulf of Carpentaria.



Thomas

[bdbcat]

Thomas....

Good idea. We can change this simply in the .RLE file.

My idea was to create a new symbol, looking like a "two-lane" version of the symbol you propose. But your concept is easier, and better looking, too.

Dave

[HappySeagull]

Wow..as the Americans say on special occasions,"Outstanding"!....All these features and still less than 20mb...!the layers,gps tweak,currents,icons etc etc.

With the gps hooked up,The cute little gps indicator goes to sleep but "ownship" is awake.If I proke it with the mousecursor,it comes back.(winxp)

[sailorF54]

I had a look at the offending RCRTCL... symbols.

CM93 must be using the old symbols RCRTCL01 to 04 symbols that were designed that way (with arrows pointing the wrong way).
OpenCpn (I've checked) is using a 'classical' implementation (at least similar to others that can be found by googling)

Now in more recent documentation, new symbols RCRTCL11 to 14 are defined (the old one are absent) with the arrows pointing the right way.
IHO PUBLICATION S-52 APPENDIX 2 ADDENDUM TO ANNEX A, PART I, USERS´ MANUAL EDITION 3.4 (2008)
http://www.ecdisregs.com/get_pdf.php?id=48&action=view

The codes for those newer symbols are available by Googling (but they seem to incorporate vectorial subsymbols that I could not trace....)

Edit
Based on what I've found, designing new symbols could be a way (just inverting the arrows)

[HappySeagull]

...not a big deal.It comes back by itself sometimes(It's when the O window is minimised or behind,say this browser window...)May be nothing...I'm marking time here,then I'll check..nope!It came back just fine!....so likely a ghostinthe machine,first run.Sorry I mentioned it.

[bdbcat]

Happy Seagull....

Thanks for the quick input.
Any more detail on the sleeping status box? I cannot reproduce this problem on XP.

Dave

[Littlechay]

I am happy to beta test on the Mac. I haven't managed to build in Xcode yet but I'll get there. Alternatively if somebody can package a dmg I can test easily. relocating from Piriapolis to Cape Town next weekend but will happily test.

[Netsurfer]

Dave ...

Originally Posted by bdbcat

Any more detail on the sleeping status box? I cannot reproduce this problem on XP.

You can (probably) reproduce it by

1. having the toolbar in horizontal orientation
2. making the window just as small as that there is enough space for the toolbar
3. adding some more icons (be enabling plugins) to the toolbar

By doing so the GPS status box (window) is moved to the lower left corner but it isn't redrawn until there is e.g. another change to the window size.

@Thomas

Originally Posted by cagney

Even having them pointing the "correct way" would not be right either, as there is no guarantee what so ever for ships tracks in relation to the recommended track.

Why not? Any example (area)?
Is the reverse direction of the arrows consistent? Because if so, why not just make them pointing to the opposite direction? What would be wrong with this way?

Gunther

BTW: Attached a screenshot from CMap program (colours are a bit weird because it is a 256 color mode application which my screen capture program can't handle the correct way - but only the display of the RCRTCL is important here).

[sailorF54]

Originally Posted by sailorF54

I had a look at the offending RCRTCL... symbols.

CM93 must be using the old symbols RCRTCL01 to 04 symbols that were designed that way (with arrows pointing the wrong way).
OpenCpn (I've checked) is using a 'classical' implementation (at least similar to others that can be found by googling)

Now in more recent documentation, new symbols RCRTCL11 to 14 are defined (the old one are absent) with the arrows pointing the right way.
IHO PUBLICATION S-52 APPENDIX 2 ADDENDUM TO ANNEX A, PART I, USERS´ MANUAL EDITION 3.4 (2008)
http://www.ecdisregs.com/get_pdf.php?id=48&action=view

The codes for those newer symbols are available by Googling (but they seem to incorporate vectorial subsymbols that I could not trace....)

Edit
Based on what I've found, designing new symbols could be a way (just inverting the arrows)

Inverting the arrows - Just a proof of concept
Pen-up and pen down vector values for S52 computed by hand (a pen and a piece of paper), no fine-tuning...

[luke austria]

I'll be testing as much as possible on Mac. I've managed to build a 2.4.xxx, but it was a lot of tweaking and fumbling - no way of "normal" productive work. And still there is a lot of config to do (debugging is almost impossible, release doesn't work and so on).
If there is someone out there who can provide a nice XCode-Projekt: I'd love to get it!

BTW: NMEA via TCP would be nice to have, I could provide the code - is someone else using Polar COM and OpenCPN together?

++Luke

[bdbcat]

SailorF54....

Nice graphics work

However, I worry about this.

There is NO CONNECTION between the RCRTCL and any TSS that may be nearby. So the corrected graphic is no more provably accurate than the original graphic.

I agree it "looks" nicer, though.

Still thinking....

Dave