OpenCPN Beta Version 4.5.307

[Hakan]

Dave.

Re: "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."
Yes, tested and you're correct, as usual. I don't yet understand why but will try to figure out how the code does it.
I made some tests with the old code e.g. your new #if = 0 set to #if = 1 around the "Mismatch else"
If I rename one target in the MMSINAME file from "Name" to "NameOld" the ships name will first be "NameOld" until message 5 is received.
Then there is a new entry in the MMSINAME file with name "Name" and the "Mismatch".
And on next OCPN start the "Name" is actually used instead of "NameOld". (This is the part I don't yet understand, but never mind so far) And the text "Mismatch" was misleading me. It would have been "Updated" or similar. Earlier I thought the "Mismatch" entry was the old not valid.

But now, when #if = 0, there will never be any new entry in the MMSINAME file so every renamed target will for ever use "NameOld" until message 5/24/19 occurs.

So it would be most correct to revert to the code before the change. But what about the flooding caused by your assumption that that two AIS are sending the same MMSI but different names as in cagney's case.
The correct solution would be to detect this case but that would be more tricky work as you said. I do understand your willingness to not delay 4.6 but if you've some idea how to avoid flooding in this special case I can easily make a simulation test.

Håkan

[Viking Sailor]

Håkan

Instead, why not assume that multiple names may be associated with a single MMSI. Place each unique MMSI/name combination in the list as a valid entry. As from the senders point of view this is exactly what he wants you to see.

[Hakan]

Viking...
I'm not sure I understand what you mean. In OCPN we can only show one name for a single MMSI and the last received would be the most valid?
Håkan

[Hakan]

Dave.
I can assume another scenario than two AIS for cagney's strange received messages.
Now it doesn't really matter how the messages was sent more than it may happen again.

I've seen a number of installations where both C-Map and a AIS command box was connected to the AIS unit. Both C-map and the box can update static values like "Moored" and destination etc. Every time these statics are sent are also other static values like ship's name transferred. If the command box and C-Map has different name, as in cagney's example where one had a preceding "M/Y" and the other not, the ships name in the AIS will be changed every time the crew alter between the two tools to update for example the destination.

As said it isn't important for us how the diverse name are transformed but this scenario may increase our prioritization when it should be taken care of.
Håkan

[transmitterdan]

AIS, by its very nature, is a "stream of consciousness" type of data source. If I understand the standard it is intended that messages be processed in the order received. If no ship name has been received then the ship name is "Unknown" until such time as a static data message for that MMSI arrives. If a new static data message arrives with different name or other vessel details then that becomes the new name or data. If two AIS are on the vessel with different names then the names should alternate.

If we want to preserve the state of AIS between restarts of O then we need a database that contains the entire AIS state. In this scenario the AIS receive system could populate the database and O could display only from at database. By separating the two functions it would probably prevent the issue at hand. Making the database persistent would allow restarts with no loss of continuity.

[bdbcat]

Hakan/Dan/etc...

All very interesting discussion.

But let us recall the purpose of the AIS MMS name cache. It is simply to populate the name field in the internal AIS data structures before the first message containing a valid name is actually received. And this is done so that the user may recognize or call the target before the normal message stream would provide that name information. It is a convenience function, and that's all it it used for.

We symbolize the target in "light green" if the name field is coming from the cache. Changes to "normal green" once a name is received.

So, the present code with changes will get the initial "convenience" name wrong if the name has been changed, or is dynamically changing. But the name field will be corrected for this session as soon as the first valid name is actually received.

If indeed the name is dynamically changing, then that too will be captured by the message logic. So, what a user sees will be the last name actually received, or the cached value (if present) if a name has not actually been received

Or, to say yet another way, once a valid name is received, the cached value is ignored.

So, to me, a true universal solution is low priority.

Thanks
Dave

[Hakan]

Dave.
Yes this issue is of little importance i total but at least one more "interesting?" post.

Since yesterday's change no updated ship names will never more be printed to the MMSINAME file and it's not about OCPN restart. From now on we will always show the old name until a static message, 5/24/19, has been received.

For info I'd 932 updated mmsi number in my MMSINAME file. That equals ~3% of the table's total entries.

If we have to make a choice before the issue of 4.6 I'd prefer to revert this commit. In my view it's more important to continue updating the MMSINAME file when a name is changed than to avoid the mess of cagney's example which I judge a more rare occurrence then a regular name change.
Afterwords we can think of how to solve also frequent name changes as of cagney's example. But Dan's post that the last received name should always be used in one OCPN session is of course relevant. But maybe not more than one MMSINAME change to a single mmsi in one OCPN session??

Håkan

[bdbcat]

Hakan...

re:
But Dan's post that the last received name should always be used in one OCPN session is of course relevant.

That is what the code does, with or without the patch. Any name field in the internal target record is replaced with the most recently received name, whether the existing name is from the cache, or from a previous reception.

Pretty busy today, but I will think about your idea. Please stand by.

Dave

[bdbcat]

Hakan...

OK, your idea implemented. Seems pretty low risk.

Check out github, branch "AIS_cache".

See if you can break it.

I want to freeze code by 0000 GMT tonight.

Thanks for the idea
Dave

[Hakan]

Dave.
A deadline like in the "good" old working days - OK

I'll test. I haven't got it to update the file with the first changed name yet. Let's see if I can debug.
Håkan

[Hakan]

Dave.
Sorry - works in debug. My bad with release.
Håkan

[Gilletarom]

It was already 18 UTC. Otherwise, at 24 ... the carriage will again become a pumpkin .....

[bdbcat]

Hakan...

What's wrong with Release mode?

Dave

[Hakan]

Dave.
No, no - Sorry - Nothing wrong but my sometimes impulsive actions.

I've successfully tested branch AIS_catch.
Thanks to transmitterdan's "AISconverter" the test environment was an easy fix.

I've tested several OCPN sessions where the ship name for one mmsi was updated frequently. For each session one, and only one, update to MMSINAME file occurred. Very good!.
I've also tested to flood the "m_MMSI_MismatchVec" with more than 60 changes to one mmsi during one OCPN session. No problem!

So I do recommend to merge branch AIS_catch to master.

This OCPN team where you are the master is fantastic. It's a pleasure and a honor to be a small part of it.

Thanks
Håkan

[Hakan]

Dave.
Now also tested to frequently change names for three different mmsi during one OCPN session. Also no problem.
Håkan