OpenCPN Beta Version 3.1.1309 Released

[hoolie]

But I for one am entirely happy with screen cluttering because I can see the full range of displayable objects. I can then suppress those that are not of use or interest ... ... ...

[bdbcat]

Folks...

1. We won't change the word "Other" to "All". Two reasons:
a. We are the only commercial grade ECS which makes even an attempt to follow IHO/IMO standards. While we are not perfect in all IHO recommendations, we try. And we'll keep trying.
b. "Other" is not "All". "Other" is that set of SENC items that have been so encoded by our chartsymbols.xml template. And chartsymbols.xml was derived directly from the IHO Presentation library. If you really want "All", use Mariner's Standard, and tick all the boxes.

One possible exposure for OpenCPN that deviates from IHO is this: In Category "Mariner's Standard" it is possible to exclude objects coded as "Display Base". This is not formally allowed by IHO. In fact, it should not even be possible to show "Display Base" alone, as it is deemed insufficient for safe normal navigation. Maybe we should fix this?

Dave

[P_Dub]

Dave, I agrree with you 100% for this remark. No one should be allow to deviate from IMO standard and vessels of anykind should be represented with its actual size; as it is one of the essence of the use of electronic chart system.
Best Regards.

[bcn]

Just to support Dave to adhere to the IMO standards (while they are meaningful of course).

And perhaps an idea for a feature in the vector chart settings:
allow for various user defined and selectable settings - but those should contain always the "Display base" set of information as a minimum.

Normally a user will not play that much selecting and deselecting single items.
Probably you have some scenarios you feel comfortable with and will use those accordingly to the circumstances.

bcn

[fastm]

Hello Dave,

the TCP sorce was GpsGate 2.6, but I tried with NavMonPc and I had the same result.
The data is read correctly with CR/LF character by Firefox, but recorded with the VDR plugin it appears without the CR/LF; I'll try to check better the data flow but I'm not an expert.
I have another question: why does OpenCPN recognize the gps and ais data and not the other nmea data?

Thanks,

Stefano

[Hakan]

Dave and Cagney

Quote: .........attempt to follow IHO/IMO standards.....

I fullY agree with your statements and opinions in this.

Now my mind take the keys:
And talking about safety. We use a navigational program to help us to a convenient, accurate and hopefully wise control of the boat. But coming to safe for my and others lives, in the bitter end it's only my self being responsible. I cant trust a simple PC to be alive next minute. There must always exist a "plan B" when needed. Taking that in consideration, if there is a key board switch or not is more about convenience then safe for my life.
And I really trust OpenCPN to be a most qualified help to acquire good decisions.
Stop.. Thanks all.

[bdbcat]

Stefano...

Do I understand that the data you showed was a VDR recording? If so, could you attach that VDR file?

The ownship lat/lon SOG, etc. is correct because it travels to all PlugIns by a separate direct route. We do it this way so that generic PlugIns do not need to decode NMEA if they only need ownship data. Similar for AIS.

Anyway, lets look at the data stream VDR file, if possible.

Thanks
Dave

[fastm]

Hi Dave,

it's not exactely a VDR recording, I try to explain: the original data is a nmea recording done with NavMonPc; this is replayed with NavMonPc and sent over a virtual serial to GpsGate (2.6) and from it sent with a tcp server. Then OpenCPN, and other client, receive it on another PC on the network.
I recorded the received data with VDR and the file shows no CR/LF (nmea_tcp_data_VDR.txt), but the data shown by Firefox shows CR/LF (NMEA_data_over_tcp_Firefox.txt).
Then I recorded the tcp stream with Wireshark and in my opinion the data contains the CR/LF (od/oa), so it seems that is OpenCPN to receive the data without CR/LF (Nmea_over_tcp.pcap).
I'm not an expert and I'm just trying to understand, so I hope this helps.
In attachment you'll find the mentioned files.

Thanks,

Stefano

[Gilletarom]

Hello Dave, hello Thomas, hello All,

I understand the importance of post No. 47 of Dave. Long, observing the file opencpn.ini, I was convinced that "Other" selects "All objects". I was convinced that "Other" were equivalent to "All".

Now I understand that since the file "chartsymbols.xml" exists, it is no longer true.

I understand the great responsibility that I took in translating "Other" to "All". French language file will be corrected in the next few days on this point.

I want to say how the translators undertake their own responsibility. I am sure that, if in the future, a sailor has serious difficulties because the French translation is done poorly, then the justice of my country require accounts.

Also, for me, it is not serious to require users to know OpenCPN all IMO documents. Especially as they are in English and that too few sailors correctly read the language.

I also want to ask earnestly that the lists of objects displayed with "Base", with "Standard" and "Other" by OpenCPn are published on opencpn.org and are put in help OpenCPN.

[bdbcat]

Stefano...

OK, this is a legitimate bug. It seems that incoming TCP messages are stripped of cr/lf by OpenCPN, in error.

The AIS decoder/processor does not care, and does not check for cr/lf. So AIS works fine. However, Dashboard does require cr/lf on incoming messages. This is why Dashboard will not show data from TCP stream.

It's an easy fix. I will try to verify on all public TCP sources I can see.
Also, I will commit a fix to github master tonight. All interested TCP users who can build from source are encouraged to test this new version before the next Beta.

Thanks
Dave

[GHammond]

Dear Gurus

Bug involving large number of charts in 3.1.1309 on linux

Scenario 1: use GE2KAP to make a lot of charts (I charted a big chunk of Malaysia at 8km resolution resulting in 1164 charts in a directory.)

Add this directory to OpenCPN. I had already added a CM93 directory beforehand.

Zoom in and out. The results are (a) either OpenCPN closes completely or (b) the quilting fails leaving lots of gaps between the GE charts with the CM93 charts showing in the background.

The logs simply end like this:

06:29:32 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/WMalaysia/8km/WMalay2_w5_00047.kap
06:29:32 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/WMalaysia/8km/WMalay2_w5_00064.kap
06:29:33 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/WMalaysia/8km/WMalay2_w5_00045.kap
06:29:33 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/WMalaysia/8km/WMalay2_w5_00058.kap
06:33:35 PST:

Scenario 2: using the same set of charts I have also created chart groups. When I place this directory of 1164 charts into the final group I can crash OpenCPN simply by clicking on the name of the chart group. To replicate, add a directory with a large number of charts, go to the main OpenCPN screen with the cursor over an area that those charts would apply to, right click on the screen, choose "Chart Groups", click on the group containing the directory. OpenCPN exits. In this case the log ends like this:

19:47:02 PST: Removing oldest chart from cache 1617
19:47:02 PST: /home/pete/boat/charts/KAP charts from Google earth/8km_Borneo/Borneo3_b4_00076.kap
19:47:02 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/8km_Borneo/Borneo3_b1_00075.kap
19:47:02 PST: Removing oldest chart from cache 1620
19:47:02 PST: /home/pete/boat/charts/KAP charts from Google earth/8km_Borneo/Borneo3_b4_00075.kap
19:47:02 PST: Initializing Chart /home/pete/boat/charts/KAP charts from Google earth/8km_Borneo/Borneo3_b5_00068.kap

This is an Arch linux system completely up to date.

I have tried playing with the open chart limit. Behavior is the same with the default opencpn.conf settings and with NCacheLimit=200. It makes no difference whether the settings for OpenGL are checked or not; it makes no difference whether Smooth Panning is checked or not. This behavior is not new to 1309; I had the same behavior with the previous beta.

Scenario 3: if I switch to a directory with over 2000 charts in it, sometimes OpenCPN doesn't even begin to load them - it just crashes when I assign the directory to a Chart Group. Or if it does load them, it crashes when panning. Again, the log shows nothing useful.

I'd be happy to upload a chart directory with a suitably large number of files somewhere if it would help.

Any way in which I can help further to debug this?

And, as a final note, lest this seem like an extreme use of OpenCPN, those of us sailing in SE Asia have to contend with vast areas of semi charted water and here Google Earth is invaluable.

Thank you a wonderful program.

Pete

[bdbcat]

Hello all testers....

Please take a look at your outstanding Flyspray Tracker issues. I think we can close some with 1309. I prefer that the creator of the Task do the Close Request, so that everyone gets heard and is happy....

Thanks
Dave

[HappySeagull]

(in XP)...the"Apply" button in the Vector charts dialogue does not apply anything. I must press " ok" to see changes made. Anyone else?

Suggest perhaps "Other" could be re-labelled as "IHO Recommend" . This would be the reset button for those of us who are fascinated by the panopoly of sharp tools in "Mariners Standard" and all the other buttons too. The next thought is that O might default to IMHO on a restart- no "save"! but I would not like to be the one to suggest it, especially if such would negate the Offset Dialogue that is so useful....

[bdbcat]

Happy...

"Other" is just "Other". IHO does not recommend it particularly.
IHO does recommend that "Standard" be the default catagory on startup.
IHO recommends that watch officers RTFM, perhaps on those dark and lonely midwatches between occasional glances at the radar. We could do the same

Dave

[bdbcat]

Pete....

I would love to get a single directory containing thousands of large scale raster charts for testing. Of course the NOAA east coast has lots of charts. But not very many adjacent large scale issues.

Maybe some kind of free file-sharing service? I have no recent experience with this...

Meanwhile, on linux, you can get and install ddd. This is a GUI debugger. If you run O until it crashes, you can get a stack backtrace and post a screenshot. This will tell us exactly where O crashes. With that info I can possibly aggravate the problem and get a crash with a more moderate number of charts.

Feels like an out-of-memory condition to me, caused by poor cache management in O.

Thanks
Dave