OpenCPN Version 1.3.5 Beta Technical

[GPS-Marco]

Added OCPN to the applications supporting GRIB.

GRIB - Wikipedia, the free encyclopedia

Saluti, Marco.

[BernardOfCa]

I am new to this forum so I am not sure if this is a known problem or not:

I am seeing a strange behavior with the NOAA ENC chart US5CA61M.000 (San Pedro Bay in California). Some of the chart (the inside of the LA Harbor) is not showing. See attachement.

Note: At the time I took the snapshot, that chart was the only one in my list.

Unrelated to this (but related to an earlier discussion in this thread), I have closely monitored the display of AIS Message 5 on OpenCPN. My observation is that all the Message 5 I decoded were correctly displayed on OpenCPN.

[dacust]

Originally Posted by BernardOfCa

I am seeing a strange behavior with the NOAA ENC chart US5CA61M.000 (San Pedro Bay in California). Some of the chart (the inside of the LA Harbor) is not showing. See attachement.

That is correct.

ENC charts are built that way. There is a higher detail chart for that missing square. If you have all the charts loaded, in the chart selection bar, you'll see another dark green bar showing there is another chart in that location.

If you have a chart that does not fully enclose an area, when you move to the open area, it will automatically load the next chart (if you have it added in Tools>Charts). If the detail chart is fully enclosed by another chart, you have to specifically choose it.

If/When chart quilting is added to OpenCPN, you'll see both charts on the screen at the same time.

ENC charts were definitely designed for systems using quilting.

-dan

[dacust]

Originally Posted by GPS-Marco

Added OCPN to the applications supporting GRIB.

GRIB - Wikipedia, the free encyclopedia

Saluti, Marco.

Cool!

We got coding, testing, collaboration, documentation, graphics, and now: marketing!

-dan

[BernardOfCa]

Originally Posted by dacust

That is correct.

ENC charts are built that way. There is a higher detail chart for that missing square. If you have all the charts loaded, in the chart selection bar, you'll see another dark green bar showing there is another chart in that location.

<cut>

ENC charts were definitely designed for systems using quilting.

-dan

Thanks for the information. This "feature" makes it difficult to use the ENC charts in my home water. I will keep testing with raster charts.

[janp391]

I have MaxSea and OpenCPN installed on the same laptop and also use the same cm93 charts. When I zoom in or out in OCPN and a new chart has to be uploaded of the system it take a very long time to do this compared to MaxSea. MS do it almost directly. Is there a way to speed up this operation in OPCN. As I have both system on the same computer it is easy to compare, (are not running them on the same time)

[cagney]

Dave
I'm quite happy with build 1122.
#26 Greenwich Meridian problem seems solved. What's your take Sinbad?
#41 The over zoom solution is OK.

I had a fresh look at some ENC:s around Hawaii and as very few of them had been converted to SENC:s this kept my computer busy.
When converting more than one ENC at the same time I experienced crashes most times. Firing up ddd I managed to catch one of them, see below.

janp391
I don't recognize the scenario you describe at all. CM93 on my box loads more like you describe MS. I suppose that Dave will be interested in this once he is back. Can you come back with more about what kind of system/setup you got? Also.. it would be interesting to know memory utilization when running MS and OpenCPN , swapfile setting etc. OpenCPN is quite aggressive in memory use, so maybe you are seeing some thrashing??
Interestingly, right now OpenCPN (cm93 and a bunch of kiwi charts loaded), on my computer, while idle uses a touch less memory than Firefox(2 windows open with altogether 21 tabs).

Thomas

[Psyches]

Originally Posted by janp391

I have MaxSea and OpenCPN installed on the same laptop and also use the same cm93 charts. When I zoom in or out in OCPN and a new chart has to be uploaded of the system it take a very long time to do this compared to MaxSea. MS do it almost directly. Is there a way to speed up this operation in OPCN. As I have both system on the same computer it is easy to compare, (are not running them on the same time)

janp391, can you tell us a little about your chart setup? How many directories, how many charts in each?

I'm also seeing an issue - every time I load a chart after the SENC is built, it takes 30 sec or more to show the chart. It looks like there is an easy fix - but Dave needs to be involved, and he's out for a few days.

The problem happens due to an issue in validating the SENC. For the tech-inclined, this is in s57chart::GetUpdateFileArray(). This process happens every time the SENC is loaded, and it searches the entire chart directory ignoring the original chart filename when looking for updates. So, building the update array actually opens and reads from every single chart with a numeric extension (.000, .001, ...) that isn't a catalog (CATALOG.031). It doesn't limit the search to files with a particular style name. For my current full NOAA chart distribution, that's 1,741 file opens. Which is, uh, a lot. Open another ENC chart that already has the SENC...and that's another 1,741 file opens.

Instead, OpenCPN needs to be filename aware, and only open update candidates to the chart in question, not all charts. Better yet, I think OpenCPN should be consistent between raster and vector charts, and manage the SENCs during chart import, not upon every ENC open.

Mark

[Psyches]

Originally Posted by Psyches

I'm also seeing an issue - every time I load a chart after the SENC is built, it takes 30 sec or more to show the chart. It looks like there is an easy fix - but Dave needs to be involved, and he's out for a few days.

Here's the 2nd issue I've found, which happens when actually building the SENC. It's similar to the first issue - too many files are checked. One of the first steps in building the SENC is to get the "nice name", in s57chart::GetChartNameFromTXT(). To do this, the entire chart directory is scanned for .TXT files. Every file is opened, and every line read from each file until a line is found starting with the chart file name. Then, everything after a "-" in the line is taken to be the nice name.

My current standard NOAA distribution has 3,238 TXT files. Usually the nice name will be found before reading all of them - but many of them are usually opened and fully read before finding a match. For example, README.TXT is usually returned first, but is never the right file. In the worst case, 3,237 opens and 4.65MB of lines will be read before finding the right one. And, if another SENC is built...potentially 3,237 files are opened again.

In the NOAA dist, the names seem standardized. I'm not sure about cm93 or other ENC chart sets...but I expect the search could be limited by filename. And I think at least an option should exist for indexing these exactly once at import, rather than upon first access.

Here's another fairly easy idea to dramatically improve ENC usability: the time-consuming stuff should be done in a separate thread, in advance of when the data is likely to be needed. For example, once the chart stack is built, a thread could be spawned that builds any needed SENCs for all charts in the stack; that way, the likelihood of actually needing to build an SENC while UI is waiting on it, is greatly reduced.

Mark

[janp391]

Mark
I am not sure that I answerer your questions, but the cm93 consists of 21399 files in 922 ?
I am using a laptop, Toshiba Equium with CPU 1,5GHz and 1GB in RAM . OS is XP SP3. Swapfile is determined of Windows.
The CPU usage is between 5-75% when starting OPCN but rise to 100 % for app. 5 sec. when loading a new chart. MS is not over 30% when loading charts.
The computer I use in my sailingboat is a small one with a CPU of 500 MHZ, RAM 512 MB and a SSD of 8GB. It runs on 12 VDC no fan, no moving parts. OS is a Tiny XP. But it runs MaxSea without any problem, and it could be nice if I can run openCPN on this computer.

[Psyches]

Originally Posted by janp391

Mark
I am not sure that I answerer your questions, but the cm93 consists of 21399 files in 922 ?

Thanks janp391 - I'm not clear; 922 directories? And seriously, 21,399 files? Will you attach a full directory listing as a .txt, so we can see your structure? That is, start cmd.exe, and do this:

c:\cm93rootdir> dir /s/b >> c:\charts.txt

Do this for all chart dirs you gave to OpenCPN (if more than one), and attach the charts.txt to a post here. That'll make it easier to see what's going on in your setup.

Thanks!

Mark

[Ptizef]

Hello Dave
Many thanks for all these improvements in 1122 !
Everything seams OK
Grib tool works fine , with lo definition , very small or no influence on scrolling and zooming speed
point 41 is OK

Jean Pierre

[janp391]

Originally Posted by Psyches

Thanks janp391 - I'm not clear; 922 directories? And seriously, 21,399 files? Will you attach a full directory listing as a .txt, so we can see your structure? That is, start cmd.exe, and do this:

c:\cm93rootdir> dir /s/b >> c:\charts.txt

Do this for all chart dirs you gave to OpenCPN (if more than one), and attach the charts.txt to a post here. That'll make it easier to see what's going on in your setup.

Thanks!

Mark

Mark
Thank you for your help
I am not following you, but I have done like this. I have the CM93 charts under D:CM93
I start OCPN and go to Toolbox under charts I find D:CM93 and the press Add Selection and ok. Then I can see the chart I need in OCPN. I have just the CM93 selected
In D:CM93 if I open properties it will show 21399........
Is there another way to set up the charts?

[yachtvalhalla]

FWIW, I have the 2009 updated cm93 charts in a folder under the C: drive.

Their properties are Size 1.30GB, Size on disk 1.35GB, Contains: 21,413 Files in 922 Folders.

I strongly suggest you put the charts under the C: drive and not the D: drive. Seems to make things faster for me and I run MaxSea and OpenCPN at the same time with very quick loading.

[Ptizef]

Hi Dave
As I said , grib are displayed well . Nevertheless , It's not very practical to use it during navigation (the dialog box is very large )
I don't know if it is in your project to modify the environment around this tool ,but I would like to suggest a way to better integrate it in navigation :
The process could be
Click on grib icon --> open grib dialog box
If not done , choose grib directory
Select a file
click 'close' --> close the grib dialog and display data of the first forecast line
move to the different forecast lines by clicking on a double arrow (previous/next)
Click on grib icon --> close grib tool
While grib tool is open and grib barbs are displayed , calculation date/time , forecast date/time and data related to the cursor position could be displayed in a bottom line
also could it be added some others informations as rain fall and clouds coverage if available
here is an example of what it could looks like: