OpenCPN Version 1.3.5 Beta Technical

[Psyches]

Originally Posted by bdbcat

Thanks, Dan

Happy T-Day.

Dave

Dave, last time I did the ALL download was in late July, and it was flat - thousands of files just below ENC_ROOT. Really I'll try it again, as Dan did - maybe they've changed things again...I think the ALL option is pretty new.

Mark

[Psyches]

Originally Posted by bdbcat

Psyches....
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.

Great, Dave. I just did a big iteration on the update-in-place process, as well as a few other things. I used your mod-time checksum code and tweaked it, and also isolated the chart header full path (+ checksum) for Update to work as it looks like you intended. Also with that abstraction, the chart table doesn't need to keep all full paths, just deltas - so my complaint in this forum about lots of repeated strings, is solved; all of that is to allow a Windows Mobile version of OpenCPN.

Any chance I could hand you the code for some reuse? Otherwise it'll be about impossible for me to keep syncing with the code base...I'd have to basically start over.

The other major thing I did, that I'm hoping to not start over, was begin separating Chart structure from UI, so folks could write a chart manager or other chart tools (scan and georef anyone?) for OpenCPN, outside of OpenCPN. In my running OpenCPN, there is a chart class that has zero UI so doesn't need chart1.h. I pulled the core enums into that chart class and out of chart1.h. This is to allow header_only opening of the charts from another app.

We can take this offline or whatever...

Mark

[Psyches]

yeah as Dan said...the NOAA all encs distribution is in directories. I dunno, maybe I originally unzipped w/o structure.

[dacust]

I'm not really following all the implications of this, so I'll just throw this out there.

Not all the ENCs do that, though. Especially, the Netherlands ENCs have multiple files in some directories. And some of them have no directories at all.

It'd be nice if OpenCPN could continue to handle cases where people have rearranged their charts. The Netherlands charts come in sets and there are duplications. And those duplicates don't match. So I checked them all aout and them merged them all into one directory. So, they aren't on disk the way they were downloaded.

Like I said, I'm not really following, so maybe I'm pointing out a non-issue.

-dan

[bdbcat]

Psyches...Mark....

I'd love to see your code.
Maybe you could create some diffs against the current CVS, and I'll try to merge them.

If this makes sense, please email the diffs to me directly. email address in help->Authors tab.

Two areas of discussion:
1. I have been considering changing the binary chart database file format into an XML human readable/editable format. Of course, it will get larger on disk....
Internal representation may grow, too. I need to add some more fields to database entries.

What is the issue here with Mobile?

2. Also been meaning to "purify" the chart classes, for just the reasons you enumerate. Probably have to define some kind of global_UI_config class, and pass a reference of this to the chart class by method or ctor, so that global statics are not needed, and it will do the "right thing" without a UI... More thought here...Now I have some motivation
Lets see your code...

Dave

[bdbcat]

Dan....

Good points all.

If it is practical, I want opencpn to not make any assumptions about directory structure. This could mean that with oddball structures, some operations may take longer to perform than might be optimal.

We'll have some new code shortly which addresses some of this issue, and tries to run more efficiently without structural assumptions.

Thanks
Dave

[bdbcat]

janp391...

One more question:
What is the condition of the cm93 detail slider bar?

This may be accessed by right-click on cm93 chart, select the cm93 Detail slider.

This should be set to 0 (zero) for normal performance. Performance will be significantly slower if the slider is set to +3 or more. The reason is that opencpn must load many more cm93 cells to provide increased chart detail. And so it will be slower to load.

Still thinking
Dave

[gjorgensen]

Dave, I just emailed you the GRIB. It's almost 1.9 MB, so let me know if that's too big or if you don't receive it.

FYI, I have not seen any of the CM93 behavior janp391 is reporting, even on my old Pentium M box with the slider set to max, so there must be something very specific about his configuration.

[janp391]

Originally Posted by bdbcat

janp391...

One more question:
What is the condition of the cm93 detail slider bar?

This may be accessed by right-click on cm93 chart, select the cm93 Detail slider.

This should be set to 0 (zero) for normal performance. Performance will be significantly slower if the slider is set to +3 or more. The reason is that opencpn must load many more cm93 cells to provide increased chart detail. And so it will be slower to load.

Still thinking
Dave

Dave....
The slider was in pos.4, I changed to 0 and yes there was improvements, it was faster app 50% but still it take up to 10 sec to load some charts.
//Jan

[Ptizef]

Hi Dave
Some grib files a not correctly sorted by date . In the shot-screen here , the first is dated 11/27 , the second 11/25 , the third 11/27 ...
They seam to be sorted by name

[jerrymc]

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

can someone help with this? I'm sure among all you hard-codin' geniuses, you can tell me what I'm overlooking..planning on taking the boat out today & wanted to test under 'real world' conditions.

[cagney]

jerrymc

Look at Ptizef's screen dump in post #115 above.
Do you have the same grib dialog on your screen when trying?
Please describe in detail what you are doing, when trying.
Have you followed the instructions in post #1 in this thread?

Thomas

[jerrymc]

Thomas:

I thought it was something simple..

1. Didn't realize one had to select individual grib files on the GRIB Display Control.
2. I expected a more detailed display, more in line with the display in the GRIB Viewer (GRIB-US)..as soon as I switched to a smaller-scale chart in OPENcpn, the barbs & isobars became evident. (duh)

thanks for the help!

[bdbcat]

Howdy...

Two points:

1. ptizef: GRIB files are initially sorted on the list by file modification time. It is too slow to read the entire directory of files to extract the GRIB record valid time for sorting.
Can you confirm that the GRIB files are sorted by file time?

2. French SHOM chart:
Tracking another issue from a French forum:

Forums


My French is poor to non-existent, but the issue is with SHOM charts of scale 1:250,000. opencpn does not do a great job with the georef on these charts. They use 4 REF points only, but that is only one problem. They are also scanned poorly (skewed slightly), and to top it off they use Euro 1950 datum. Maxsea seems to do a slightly better job than opencpn, although their error goes in the other direction....

The one chart I am looking at is
De Fos-sur-Mer Capo Mele (6951.kap) 1:250,000

Is anyone using this SHOM chart series? Any observations from other ECS's? Any comments on the French forum?

Thanks
Dave

[cagney]

My French isn't good either, so I get some help with translation
here. Scroll down the list to find the OpenCPN thread.