You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi. I'm working through our shim between AisParser and our database and have noticed some inconsistency.
I'd got the impression (probably from looking at one particular parameter yesterday) that you weren't intercepting the "not available" values when parsing the bits. However I've just spotted that you do set null values in (for example) ReadRateOfTurn and ReadTrueHeading. Whereas you don't in (for example) ReadSpeedOverGround and ReadCourseOverGround.
It's debatable whether the 'not available' value (e.g. 511) should be passed back as-is, or intercepted-and-nulled - we had a long conversation ourselves this morning about which is best in later processing.
Our reasoning (in the context of our particular project): we have a wrapper around AisParser to convert a message into a 'dynamic data record' and/or a 'static/voyage data record'. The calling code doesn't know about the individual message types, it just gets the record(s) back.
So if the 'not available' values are nulled by AisParser, then that calling code can't differentiate between "the parameter has a 'not available' value in the message" compared with "the message [type] doesn't include that parameter". e.g. Rate Of Turn in a Position Report (1) vs. a StandardClassB (18).
It's not a killer for us at present, but if our customer needs us to process stuff differently in the future then it could be - so just thought I'd raise it with you for possible consideration/discussion! Cheers.
The text was updated successfully, but these errors were encountered:
Hi. I'm working through our shim between AisParser and our database and have noticed some inconsistency.
I'd got the impression (probably from looking at one particular parameter yesterday) that you weren't intercepting the "not available" values when parsing the bits. However I've just spotted that you do set null values in (for example) ReadRateOfTurn and ReadTrueHeading. Whereas you don't in (for example) ReadSpeedOverGround and ReadCourseOverGround.
It's debatable whether the 'not available' value (e.g. 511) should be passed back as-is, or intercepted-and-nulled - we had a long conversation ourselves this morning about which is best in later processing.
Our reasoning (in the context of our particular project): we have a wrapper around AisParser to convert a message into a 'dynamic data record' and/or a 'static/voyage data record'. The calling code doesn't know about the individual message types, it just gets the record(s) back.
So if the 'not available' values are nulled by AisParser, then that calling code can't differentiate between "the parameter has a 'not available' value in the message" compared with "the message [type] doesn't include that parameter". e.g. Rate Of Turn in a Position Report (1) vs. a StandardClassB (18).
It's not a killer for us at present, but if our customer needs us to process stuff differently in the future then it could be - so just thought I'd raise it with you for possible consideration/discussion! Cheers.
The text was updated successfully, but these errors were encountered: