OpenCPN Beta Version 4.5.307

[cagney]

Regarding the latest additions in github from Mar 9, 2017 ...........

How do I get rid of highlighting of track points. The blue square works well in marking the track points, but how to get rid of it once you are finished?

Shouldn't it just disappear once you close the properties dialog?

Thomas

[bdbcat]

Thomas...

Yes, it should.

Fixed in github now.

Thanks
Dave

[Hakan]

Dave.
Today's Git
Win10
With the new patches I've to use a value of -3 for "Charts Zoom/Scale weighting - Raster" to get same effect as my earlier value of -1. If that was the intention I can live with it but this message for your info.
Håkan

[bdbcat]

Hakan....

Thinking of new users, without experience in zoom factors.

What happens if you use "0" for raster zoom factor? Too much detail? Too slow?

Dave

[Hakan]

Win10, OpenGL= on and quilt is of course on.
If I'm on slider = 0 and a 50 000 scale raster, OCPN view scale = 33 500 (1.5x) and zoom in one step a 10 00 scale chart is coming up already at view scale 16 800 (0.6x) and that's to early for that chart, to small details. First shot.

At slider -3 I get one zoom step more before the 10 000 scaled chart is viewed.
Viewed scales: step 0: 33 500(1.5x), step 1 16 800(1.5x) and still the 50 000 scale chart, step 2: viewed scale 8400(1.2x) and the 10 00 scaled chart. Second shot.
The pictures wasn't the best when uploaded but you may get what I what I'm trying to express.
But, this may be a special place where I've a mix of different charts sources. On another location where charts from only one deliverer is present the differences between slider 0 or -3 is not that distinct. I'm not sure anything would be adjusted to fit my special location. I could also be my glasses need to be renewed?
As said, it was more of an info.

Håkan

[cagney]

There is a problem with the AIS data file mmsitoname.csv.
Have look at this excerpt from my local file.

367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch
367373000,TRUE NORTH,Mismatch
367373000,M/Y TRUE NORTH,Mismatch

Whatever is the cause of the mismatch, these repetitive lines should not be allowed to expand the size of the file.

Thomas

[bdbcat]

Hakan...

I did change the math for determining quilt composition based on screen scale. This was prompted by some work in the Euro Inland ENC sets joining to standard ENCs at places like Hamburg.

But, I agree with you that zoom factor "0" is too much detail for raster charts. Hard to read the soundings and other text. So I have tweaked the algorithm for RNCs, so that zoom scale "0" looks reasonable for average chart density.

Let me know what you think.

Dave

[bdbcat]

Thomas...

You are correct. Looks like someone reprogrammed their transponder, changing the vessel name field. Probably a pretty rare event.

Anyway, I will fix this tonight.

Thanks for the catch.
Dave

[Hakan]

Dave.

Quilt composition.
Yes, this change fits me perfect. I can now use slider = 0 and on all positions I've tried next chart is viewed in a due zoom step. Thanks.

AIS ship name. "Probably a pretty rare event"
Well, I've reprogrammed the ships name on about five AIS the last two years. So even rare it's done. Both ships and AIS are changing owners. And I have a lot of "Mismatch" in my hash table as well.
With yesterdays patch we will instead get double, or more, names for one MMSI i suppose? A new name is printed in the end of the table and I suppose we're reading "bottom up" to catch the last name when searching for a MMSI match? Otherwise we will have the old name until message 5/24/19 is received?

Håkan

[bdbcat]

Hakan...

On the AIS MMSI->name match:

You are correct:
We will have the old name until message 5/24/19 is received.

Internally, we use a hash-map to store the names against the MMSI. So there can be only one active name at any one time.
I suppose we could keep both names in the file, and periodically scrub the file to remove duplicates. But this seems a bit like make-work. Maybe should be added to the TODO list for later.

Dave

[Hakan]

Dave
About wxWidgets iterator. Can we learn it to read bottom up instead of top down as now. Then we would catch the last added name first when searching in the name file? (Or save new items at first row instead of the usual "app" appending to the end.)
Then no bothering for cleaning the file. As you said it not so often so we can let the file grow a little?
Håkan

[cagney]

There is a subdivision of the longitude grid at the top of the screen.
At certain scales this looks ugly and mess up the longitude numbers.
I don't know when this was introduced.





Thomas

[bdbcat]

Thomas...

The newer grid spacing came about in O4.2. I agree that it is a little dense at times. I adjusted the constants to improve the rendering rules. In github now.

Thanks again
Dave

[transmitterdan]

Dave,

In function:

bool Quilt::BuildExtendedChartStackAndCandidateArray

The variable reference_family can be referenced before initialization at line 1103.

[bdbcat]

Hakan...

Thinking about MMSI-<Name map:

Solution is not so clear.
I think this is a pathological case.

Looking at cagney's file extract, it seems to me that on this ship there must be two transponders, both with the same MMSI, but different programmed names. Either that, or one defective transponder sending duplicate messages with alternating names. The OCPN "mismatch detect" code is activated on each reception of a message with valid name field. That is the only way we could get repeated mismatches in the cache file.

Think of the more "normal" case where the name is changed once on vessel transfer. In the old code, before my latest patch, we would get one "mismatch" message, the new name would be loaded into the incore hashmap, and the last entry in the cache file (i.e. the new one) would take precedence on the next program load. No file flood would result.

But in the case here, OCPN is experiencing cache file flooding as we try to continuously figure out which is the correct name from alternating transmissions of the same MMSI. A possible solution would be to detect this strange case by counting mismatches per MMSI, set some flag, and do the right thing as his messages are received going forward. Could work, but not something I want to try this close to release. Needs careful testing.

Dave