-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding UnixTimestamp + Parse message type 27 #149
base: main
Are you sure you want to change the base?
Conversation
|
||
public interface ITimestamp | ||
{ | ||
public long? UnixTimestamp { get; } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unix timestamps come in two different units: seconds and milliseconds. I don't know which this is. Please could you rename it to make the units clear?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was simply using the field name that you had used to maintain continuity but can rename if desired?
@@ -87,7 +93,7 @@ public void OnCompleted() | |||
throw new NotImplementedException(); | |||
} | |||
|
|||
private void ParseMessageTypes1Through3(ReadOnlySpan<byte> asciiPayload, uint padding, int messageType) | |||
private void ParseMessageTypes1Through3(NmeaLineParser nmeaLineParser, ReadOnlySpan<byte> asciiPayload, uint padding, int messageType) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The fact that we're now passing in a line parser and the ASCII payload seemed like a code smell to me, and now has me wondering: is there a layering issue here?
The timestamp isn't really part of the AIS message, it's actually from the surrounding NMEA layer, isn't it?
Before this change, these various message types represent the information that was broadcast by the vessels' AIS systems. The timestamp is not part of that. The provenance of the timestamp is not necessarily clear. It might tell us when the ground station that picked up the radio transmission received it. But in cases where messages are relayed as part of a large-scale network that collects AIS data from numerous stations, it might just tell you when the particular equipment you're plugged into received the message.
So for that reason I'm not sure if it is really correct to attach this to the types that represent AIS messages.
If you need access to information from the NMEA layer, might it be better to design in something where we make that available, and make it clear which pieces of information came from where?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Again my scope to refactor and improve general code quality is limited as I have many other commitments but would welcome PRs on my repository if you dont want to undertake this work in yours.
@joshdadswellijyi - I've split out Ais.Net.Models to their own project, and implemented That's now referenced in I haven't implemented any of your Unix timestamp behaviour, because I don't believe we'd reached a conclusion as how best to implement the desired outcome. |
I have come accross the need to have the UnixTimestamp from the Nmea message so I implemented the following in order to accomplish that.
Library already read and extracted the timestamp I just needed to add it to the message records so it could be used outside the library.
This pull request also contains the parsing of message type 27 which you already had a decoder for in Ais.Net