Skip to content
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

Correct handling of navigational status in RMC and GNS #108

Merged
merged 2 commits into from
Jul 2, 2023

Conversation

calmh
Copy link
Contributor

@calmh calmh commented Jun 24, 2023

There was a misunderstanding on what the "navigation status" field should include. The enum values were for the "positioning system mode indicator" (variously "FAA mode" / "FFA mode" in this code) which is the preceding field. This changes the enum values to correspond to actual ones.

I realize that in principle this is a breaking change, however there's no such thing (as far as I can tell) as the previous navigational status values (as those are in fact mode values, which we don't keep an enum for), so I doubt anyone should depend on them... If they do, that will be a bug by itself and breaking it to highlight the error may be desirable.

Fixes #107

There was a misunderstanding on what the "navigation status" field
should include. The enum values were for the "positioning system mode
indicator" which is the preceding field. This changes the enum values to
correspond to actual ones.

I realize that in principle this is a breaking change, however there's
no such thing (as far as I can tell) as the previous navigational status
values (as those are in fact mode values, which we don't keep an enum
for), so I doubt anyone should depend on them... If they do, that will
be a bug by itself and breaking it to highlight the error may be
desirable.

Fixes adrianmo#107
@aldas
Copy link
Collaborator

aldas commented Jun 29, 2023

I think this change is OK (being author for this problem). In some sense current API is/was (completely) broken - rendering these sentences useless in some situations.

@icholy what you think, you have stronger opinions.

@icholy
Copy link
Collaborator

icholy commented Jun 29, 2023

@aldas if you're ok with it then I'm ok with it.

@aldas
Copy link
Collaborator

aldas commented Jun 29, 2023

maybe we could add some ability to switch Parser.EnumString/EnumChars to be more lenient with unknown values in another PR. In case %$%^ hits the fan. NMEA0183 spec being closed and we actually can not guarantee 100% that we have correct enums or some manufacturer do not have their "idea" of correct values.

Copy link
Collaborator

@aldas aldas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so far this seemed to work because "S" (old NavStatusSimulated and new NavStatusSafe) and "V" (old NavStatusDataValid and new NavStatusNotValid) from old and new enum collide and these are most used values. Probably this was the reason this was not found before. RMC is very common sentence.

If anyone depend on these enums and this change breaks their build - this is probably better than silently fail in production parsing uncommon values.

types.go Show resolved Hide resolved
@calmh
Copy link
Contributor Author

calmh commented Jun 30, 2023

Thanks, I added back the relevant constants with some commentary.

Copy link
Collaborator

@aldas aldas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@aldas aldas merged commit a60cdb4 into adrianmo:master Jul 2, 2023
4 checks passed
@gytisgreitai
Copy link

This was not released for some reason? v1.8.0 is latest with Feb 4, 2023 ?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Fails to parse correct RMC sentence
4 participants