OpenCPN Version 1.3.5 Beta Technical

[janp391]

Originally Posted by 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.

Hi Terry
I have changed from D: to C: but there is not much of improvements. It takes up to 15 sec. to zoom in when there is a chart change. MS do this for under a sec.
I have another computer running XP SP3, CPU 3,2 RAM 1,5GB and the performance is similar.
So there is something in my setup that has to be changed?!
BR
Jan

[Psyches]

Originally Posted by janp391

Hi Terry
I have changed from D: to C: but there is not much of improvements. It takes up to 15 sec. to zoom in when there is a chart change. MS do this for under a sec.
I have another computer running XP SP3, CPU 3,2 RAM 1,5GB and the performance is similar.
So there is something in my setup that has to be changed?!
BR
Jan

Hi Jan, you're setting up OpenCPN right, although it was possible that what Terry suggested could have helped.

I'm an old software developer but a fairly new sailor, and I'm still coming up to speed on s-57, cm93, etc. As I mentioned, I have the NOAA distribution which I take as a good reference point for ENC. From looking at the code I see that some styles of cm93 are very different in structure than the NOAA dist. I don't have very good examples of cm93, but from you and then Terry, I see that there are even larger numbers of files than NOAA has. So I suspect you have the same problem that I do, but I can't tell for sure yet. If I had a textual list of the structure as I mentioned before, I could tell for sure. And then I might be able to give you a trial of OpenCPN that would fix your problem quickly.

I expect Dave could do it faster, but he's away. Also if there are folks on the forum that know or can point me to s-57 and cm93 file naming standards (more than the extensions, which I've found are well-documented) that would be appreciated.

Anyone willing to post a list of a huge cm93 directory structure, or pointers to standards for the naming of s-57 and cm93 vector charts?

Mark

[dacust]

Go here for lists of the files and directories in my charts folder. There are two listings, one is just the cm93 directory (819kb) and the other is a list of all my charts, cm93, enc and raster (1,402kb)

Just for fun:
cm93s - 922 folders, 21,413 files, 1.3GB (same as posted above)
All of my charts - 2,779 folders, 35,374 files, 22.5GB

-dan

[Psyches]

Originally Posted by dacust

Go here for lists of the files and directories in my charts folder. There are two listings, one is just the cm93 directory (819kb) and the other is a list of all my charts, cm93, enc and raster (1,402kb)

Just for fun:
cm93s - 922 folders, 21,413 files, 1.3GB (same as posted above)
All of my charts - 2,779 folders, 35,374 files, 22.5GB

-dan

Excellent, thanks Dan! (and Thomas, via PM); exactly what I need.

Mark

[bdbcat]

Hi folks...

Several things to talk about here, I guess.

1. Psyches....
Mark, I believe that the "standard" NOAA ENC structure has each cell and its dependent files in a separate directory, like

ENC_ROOT--->US1AK90M--->US1AK90M.000, US1AK90E.TXT, .....

opencpn assumes this structure. So, the GetFiles loop in GetUpdateFileArray() fetches usually only a few (~6-8) files.

Are you using a more flat structure for ENC_ROOT? If so, I see your point.

Similar observation is made for "nice name". In the "normal" ENC_ROOT structure, few text files are read in the search for "nice name".

I guess there is no reason not to incorporate the cell base name in the file search mask. I'll look into it....

2. janp391....
Psyches' potential issue in (1) above does not affect cm93 chart reading at all. cm93 structure is entirely different, and handled separately.
SENC files are not created for cm93, as the cm93 database is already essentially a SENC file. There is, however, a good amount of processing necessary to create the renderable polygons for the area objects.

So, to your performance issue:

For me, cm93 is acceptably snappy on a 1 Ghz, 1GB machine with XP SP3.
I agree, 15 seconds for a single chart load is unusable. Something funny here, I think.

Are you receiving NMEA GPS data during this chart load? If so, please try with GPS disconnected as a test case.

Also, in the Windows Task Manager, please report the memory usage before, during, and after a long chart load. Maybe this will give us some ideas.

Finally, in Toolbox->VectorCharts, select MarinersStandard, then select all object types except LIGHTS, LNDARE and DEPARE. Then try some chart loads. This will tell us if it is a file access problem, or a drawing speed problem.

How is panning and chart dragging speed?


Quick poll: Others running cm93 on XP:
Is it snappy or sluggish in your opinion?

3. Cagney...
How do you create multiple SENCs at once, and create a crash? Or is it one after the other?

4. gjorgensen...
Can you post or email me the large pacific GRIB which loses wind barbs? Thanks

Thats enough for now, I think
Dave

[Viking Sailor]

Dave, CM93 is great on my 3GHz XP box. Paul

[Psyches]

Originally Posted by bdbcat

1. Psyches....
Mark, I believe that the "standard" NOAA ENC structure has each cell and its dependent files in a separate directory, like

ENC_ROOT--->US1AK90M--->US1AK90M.000, US1AK90E.TXT, .....

opencpn assumes this structure. So, the GetFiles loop in GetUpdateFileArray() fetches usually only a few (~6-8) files.

Are you using a more flat structure for ENC_ROOT? If so, I see your point.

Similar observation is made for "nice name". In the "normal" ENC_ROOT structure, few text files are read in the search for "nice name".

I guess there is no reason not to incorporate the cell base name in the file search mask. I'll look into it....
Dave

Dave, you're back! Wasn't expecting you so soon. I found the S-57 spec for file naming, but couldn't find anything about mandated directory structure. NOAA has a full ENC .zip download with everything just below ENC_ROOT, and that's what I grabbed and unzipped. I take that to mean that there is no required directory structure. Did you read somewhere that says otherwise? (for my education) It's possible this will change, I dunno. It's definitely a problem today, and as you say it looks like an easy OCPN fix. Here is where I got the NOAA download from: Chart Downloader for NOAA ENCs®. (the All option).

I also now see that cm93 structure is significantly different...

Thanks,

Mark

[janp391]

DaveThank you for looking in to this

Are you receiving NMEA GPS data during this chart load? If so, please try with GPS disconnected as a test case.

No, I am "armchair navigating"

Also, in the Windows Task Manager, please report the memory usage before, during, and after a long chart load. Maybe this will give us some ideas.

The memory usage start at 850 MB when OCPN is running, goes up to 950 MB when loading a "difficult" chart.

Finally, in Toolbox->VectorCharts, select MarinersStandard, then select all object types except LIGHTS, LNDARE and DEPARE. Then try some chart loads. This will tell us if it is a file access problem, or a drawing speed problem.

Yes it speeded up a little bit.
What I noticed that after the upload of a "difficult" chart then using + and - directly after the upload the zooming goes much faster. The system has "learned" something? If I take another part of the world after that and start with a big scale and start zooming in. Then the result the first time is a big time delay but next time it goes faster

How is panning and chart dragging speed?

it is ok

//Jan

[bdbcat]

Psyches....

Mark....
Not to quibble too much, but could you please describe your ENC_ROOT structure again.?

When I look at NOAA site, and download some small zips, I see for example

ENC_ROOT/US3MI01M/{files}.

As far as I can tell, each chart (cell) has its own subdirectory under ENC_ROOT.
A simple unzip will preserve this structure.

I did not download the "All" selection, since I'm on marginal wifi connection. Maybe it is different...

Here is why this is important:
1. Your prior issue with SENC validation is real and should be fixed.
2. I am working on an update to the chart database, allowing "update in place" without complete reload. This will save a lot of time with ENC's. It will also support the NOAA update process, again without requiring a full re-scan of the entire ENC_ROOT tree.


Thanks
Dave

[dacust]

Originally Posted by bdbcat

I did not download the "All" selection, since I'm on marginal wifi connection. Maybe it is different...

I did the ALL download. It has 727 individual folders.

[bdbcat]

Thanks, Dan

Happy T-Day.

Dave

[WhiteStar]

Hi,

I'm still having problem to build OpenCpn for Ubuntu 9.10.

g++ -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" -DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"opencpn\" -DVERSION=\"0.1\" -DINSTALL_PREFIX=\"/usr/local\" -I. -I././include -I././src/nmea0183 -I/usr/X11R6/include -I././src/mygdal -I././src/grib -I././src/grib/bzip2  -I/usr/lib/wx/include/gtk2-unicode-release-2.8 -I/usr/include/wx-2.8 -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -D__WXGTK__ -Wall -g -DocpnUSE_GTK_OPTIMIZE -DUSE_S57 -DUSE_GLU_TESS  -Wall -g -fexceptions -fno-stack-protector -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include   -MT chart1.o -MD -MP -MF .deps/chart1.Tpo -c -o chart1.o `test -f 'src/chart1.cpp' || echo './'`src/chart1.cpp
In file included from /usr/include/wx-2.8/wx/sckaddr.h:20,
                 from /usr/include/wx-2.8/wx/socket.h:24,
                 from ././include/nmea.h:113,
                 from src/chart1.cpp:230:
/usr/include/wx-2.8/wx/gsocket.h:40: error: using typedef-name 'GSocket' after 'class'
/usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here
In file included from /usr/include/wx-2.8/wx/gsocket.h:179,
                 from /usr/include/wx-2.8/wx/sckaddr.h:20,
                 from /usr/include/wx-2.8/wx/socket.h:24,
                 from ././include/nmea.h:113,
                 from src/chart1.cpp:230:
/usr/include/wx-2.8/wx/unix/gsockunx.h:40: error: using typedef-name 'GSocket' after 'class'
/usr/include/glib-2.0/gio/giotypes.h:120: error: 'GSocket' has a previous declaration here
In file included from ././include/nmea.h:113,
                 from src/chart1.cpp:230:
/usr/include/wx-2.8/wx/socket.h: In member function 'wxSocketError wxSocketBase::LastError() const':
/usr/include/wx-2.8/wx/socket.h:118: error: 'struct _GSocket' has no member named 'GetError'
In file included from src/chart1.cpp:240:
././include/grib.h: At global scope:
././include/grib.h:76: warning: 'typedef' was ignored in this declaration
make: *** [chart1.o] Error 1

Build by

./configure --enable-unicode
make

Please advise what to change.

/Fredrik

[cagney]

3. Cagney...
How do you create multiple SENCs at once, and create a crash? Or is it one after the other?

Dave
I actually started the creation of more than one SENC, even though it seems impossible normally. By mistake I stumbled upon a way to do it.
First start the creation of one SENC, then click "Max Detail Here" somewhere without a SENC .... this gives you a new creation dialog and, ... before long, a crash.

Thomas

[cagney]

WhiteStar

That output looks familiar. Provided you have the latest CVS and follow the instructions in post #44 in this thread, you ought to be alright. The normal " ./configure, make , sudo make install" will do.

Thomas

[jerrymc]

duh..downloaded build 1122 & installed..in the Tools menu, pointed to the grib's directory (from grib.us--files named xxxx.grb) but gribs do not display? What have I overlooked? I'm sure it's something simple (& stupid on my part) but I'm temporarily stumped.

jerrymc