OpenCPN General

[phiggins]

I have discovered a problem using OPenCPN V4.2.0 with OpenGL turned on. If you load a chart of a given name then reload another chart with the same name, if OpeNGL is on the 2nd chart location will show the first charts contents. With OpenGL off it shows the correct chart.

Attached is an example. I first scanned in a chart called "Unknown_Harbour" at one location. Then I scanned in another chart with the same name "Unknown_Harbour" from another location. If OPENGL is on I see the contents of the first at the 2nd's location. If I turn off OpenGL I see the correct chart.

If this not an known problem I will open a flyspray.

[wdkester]

Options>Charts>Chart Groups>"Group name">Remove Chart

Removes the selected chart; but, there seems to be no way to undo the "Remove".

Maybe the Remove could be a toggle button or a right-click undo would be nice.

[wdkester]

A year (or so) ago, I contacted the Salty Southeast Cruisers Net about a plugin that would use their data (anchorages, trouble spots, marinas...See Cruisers' Net | Cruisers Helping Cruisers) in OpenCPN. Their founder was agreeable; but, unfortunately he died in accident. They are still interested. See the following email from Curtis.

My question is : Would any of the developers like to assist?

Curtis Hoff <curtis.hoff@cruisersnet.net> Apr 3 at 6:33 PM
To
David Kester
Message body
Dave:

OpenCPN integration would still be beneficial to us. I would have to talk with my other partners, but I believe we would be receptive to OpenCPN integration.

However, I doubt we have the available resources for a while due to our upcoming Android release and maybe not the technical expertise. Do you know anyone in the OpenCPN world who we could work with?

Regards,
Curtis

Curtis Hoff, Ph.D.
Web Site & Mobile Development
Salty Southeast Cruisers' Net - Cruisers Helping CruisersCurtis Hoff <curtis.hoff@cruisersnet.net> Apr 3 at 6:33 PM

[nohal]

David...
I remember some time when you talked to them, they were not yet able to provide an interface or export the data. If that already changed (and all the partners agree that they want to proceed), I would be glad to help them make the integration happen.

Pavel

[wdkester]

Pavel,

Thank you. I forwarded your response.

[bdbcat]

@phiggins...

Re:
I have discovered a problem using OPenCPN V4.2.0 with OpenGL turned on.

Paul, I have not been able to reproduce this behaviour, but I'm not exactly sure of the sequence of events.

Do you have more information, or maybe a logfile snippit to show the two charts being added sequentially?

Thanks
Dave

[nohal]

Originally Posted by bdbcat

@phiggins...

Re:
I have discovered a problem using OPenCPN V4.2.0 with OpenGL turned on.

Paul, I have not been able to reproduce this behaviour, but I'm not exactly sure of the sequence of events.

Do you have more information, or maybe a logfile snippit to show the two charts being added sequentially?

Thanks
Dave

Dave...
The problem seems to be something different, not related to OpenGL at all - This is the closest I got to the problem Paul describes:

When there are equally named KAP charts in different folders, we get confused.
Testcase:
* Take NOAA RNC 11303 and place the 2 KAPs into the following directory structure

CHARTDIR
  |->A->11303_1.KAP
  |->B->11303_2.KAP

* Rebuild the chart DB
* Look at 26 20.90 N / 097 25.41 W at reasonable zoom. Everything ok, we can see both the charts quilted.

* Rename B/11303_2.KAP charts to B/11303_1.KAP

CHARTDIR
  |->A->11303_1.KAP
  |->B->11303_1.KAP

* Rebuild chart database.
* There is no way to get both the charts into the quilt.

It seems that Paul's problem, which he also wasn't able to reproduce on his other system, is caused by this.
I vaguely remember we touched this, or very similar, topic some time ago somewhere, but don't recall any detail.

Pavel

[bdbcat]

Pavel...

OK, I will look at your test case. I also vaguely remember discussing this once.

However....

On OpenGL, using the raster cache, I have discovered a problem.

Q: What happens to the raster cache when a new updated chart is downloaded, as by dldr?

A: The old cache for this chart should be purged, and a new one built as chart rectangles are displayed.

Problem: In some cases we can get a cache incoherency.

Why:
The cache methods try to detect a change in chart edition date as published in the .KAP header in order to purge any old raster cache. I am finding that NOAA (at least) does not bump the edition date very often. Only the NTM field seems to get updated on every new publication. Its not clear that a NTM update would affect the raster tiles, but best to be conservative here.

So, we can get a new chart installed with an old, apparently valid, cache.
Not good.

Solution:
We need to use something else to identify changed .KAP files in order to trigger a cache purge. We could calculate and record a hash of the .KAP file, but that seems expensive to me. Alternatively, I have a patch which uses also the local KAP file modification time to qualify the cache validity. Seems to work OK so far in testing, I'll push it tonight.

This could be Paul's problem. Two charts, same name, same edition date, same cache. Oops.

My patch would fix Paul's problem, I think, since I record the full time_t value of the file mod time, precise to the second.

Get it?
Dave

[bdbcat]

Pavel...

OK, I looked into your scenario.

And I see the issue, but not the solution. Initially, and when rebuilding the database, both charts end up in the database OK, despite their identical names.

However, when the database is traversed to build a chartstack at a certain lat/lon, duplicate charts with the same name are removed intentionally. Here is the comment in the code:

chartdb.cpp:553

//    Remove exact duplicates, i.e. charts that have exactly the same file name and nearly the same mod time
//    These charts can be in the database due to having the exact same chart in different directories,
//    as may be desired for some grouping schemes

If I recall my thinking here, some users wanted to create a group structure that had the same chart in different locations of their chart file tree. Then groups were created by judicious upper directory selection.

Not sure what to do here that would not break that earlier idea, but I'm open to suggestions/thoughts. I'll sleep on it.

Dave

[.Paul.]

Dave,

My Windows build of the OpenCPN (master branch) using commits from yesterday (April 15) broke the Auto Follow task bar button and F2 key. With this build, Auto Follow can be turned off with the button or F2 key, but it cannot be turned on again. A left click on the button centers the screen on the own ship position as usual, but the button does not change color, and the ship moves away from the center of the screen (the chart does not pan).

Auto Follow task bar button (and F2 key) work correctly with the source from April 3.

Paul

[wdkester]

Paul Higgins was probably talking about charts created by GE2Kap whose header looks like:
"! Created by GE2KAP.REX V20.0.0.9 on 2016/04/07 18:39:46 - Use at your own risk!
VER/3.0
BSB/NA=AH_Z18_00001
NU=1,RA=1366,665,DU=0
KNP/SC=4285,GD=WGS84,PR=MERCATOR,PP=24.763
PI=UNKNOWN,SP=UNKNOWN,SK=0.0,TA=90.0
UN=Meters,SD=
DX=1.19,DY=1.08
OST/1"

No edition date(ED=) or NTM.

[nohal]

Originally Posted by bdbcat

Pavel...

OK, I looked into your scenario.

And I see the issue, but not the solution. Initially, and when rebuilding the database, both charts end up in the database OK, despite their identical names.

However, when the database is traversed to build a chartstack at a certain lat/lon, duplicate charts with the same name are removed intentionally. Here is the comment in the code:

chartdb.cpp:553

//    Remove exact duplicates, i.e. charts that have exactly the same file name and nearly the same mod time
//    These charts can be in the database due to having the exact same chart in different directories,
//    as may be desired for some grouping schemes

If I recall my thinking here, some users wanted to create a group structure that had the same chart in different locations of their chart file tree. Then groups were created by judicious upper directory selection.

Not sure what to do here that would not break that earlier idea, but I'm open to suggestions/thoughts. I'll sleep on it.

Dave

Dave...
Perhaps we should look at the size of the file? Faster than checksum/fingerprint and IMO much more reliable than name+date...
Do you see some cons?

Pavel

[transmitterdan]

Pavel,

This issue can up with chart downloader too as I recall. I was thinking a hash made from the full path name would be unique. It would not take much time to compute.

[nohal]

Dan...
Yes, of course, but it will break the other use case Dave described where we actually want to identify the "duplicate" charts present in several different locations on the filesystem...

Pavel

[transmitterdan]

I'm ok with requiring all unique chart files to have unique file names. I haven't found any government supplied chart datasets that violate this rule.

I would not like to have to read entirely every chart file to build the database. The process is slow enough already.