Gatehouse wrapper messages feature

[SiggyF]

Some AIS messages have so-called Gatehouse wrappers. These encapsulating messages contain extra information, such as time and checksums. Some readers also process these. See some more documentation here.

We have created a small mixin that allows for storing this extra information. We also added an extra message type to parse the metadata lines. Could you have a look to see if this is an approach you would be willing to adopt?

As an example, see the following, which is followed by a regular !AIVDM message

$PGHP,1,2020,12,31,23,59,58,239,0,0,0,1,2C*5B

I will submit the code as a PR referring to this issue.

[M0r13n]

@SiggyF

Thank you!

I saw such messages already, but I never found the time to actually look at them in detail. So I am glad that you did. I will take a look at your PR this weekend. 😄

[M0r13n]

@SiggyF

I took a look at your PR. Overall, I liked your suggested changes. But there are some details, that I would have done differently:

• tests are missing or the existing tests even fail
• you added a PGHPMessage class as a mixin to every AIS message
• assertions are not a very good practice, because these are removed if optimizations are requested from Python

So, I played a bit around with your code and came up with a slightly different approach. I decided to make the parsing/decoding of NMEA messages a bit more generic. PHGP, AIVDM, and AIVDO messages are all NMEA messages - among many others. All these NMEA messages have in common, that they have a start delimiter, followed by a comma-separated sequence of fields, followed by the character '*', the checksum and an end-of-line marker. Therefore, I added a new class NMEASentence. This class encapsulates a single NMEA sentence and handles the basic stuff. This allows other classes to build upon this class.

Then there are two new classes:

• GatehouseSentence: encapsulates PGHP messages
• AISSentence: encapsulates AIS messages

I researched GH messages and came to the conclusion that:

GH internal messages type 1 are used for "encapsulating" NMEA messages.

The important part is that GH messages can be used to encapsulate every NMEA message - not just AIS messages. Thus, I decided to add a .meta attribute to all NMEASentences. This differs from your approach of adding the .meta attribute to every AIS message individually.

I am curious about your feedback. Can you live with my suggestions?

@Inrixia: Would you take a look at my changes? Your feedback has proven invaluable in the past. 😁

[Inrixia]

Will take a look when I get the time 👍

[Inrixia]

Changes in #93 look good.

Might be worth considering a better name than meta and it's associated functions for easier readability.

[M0r13n]

@Inrixia

Thanks for looking at my changes.

Might be worth considering a better name than meta

Do you have any good suggestion? I thought about this also and did not came up with a nice naming scheme. I ultimately decided to use meta, because:

• it's kind of meta data about the message
• it's somewhat generic: this allows to store other kinds of "meta data"

[M0r13n]

@Inrixia

I renamed the newly introduced .meta attribute to wrapper_msg. I think this makes the intention clear.

@SiggyF I closed your original PR. But I used much of your prior work to implement support for gatehouse wrappers. Thank you!

With Version 2.3.0 gatehouse messages are parsed by every stream class. See examples

[Inrixia]

@M0r13n Perfect, that is much more understandable

[SiggyF]

Thanks for implementing this feature and for the suggestions. We will test it with our datastreams.