Closed calmh closed 1 year ago
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.
@aldas if you're ok with it then I'm ok with it.
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.
Thanks, I added back the relevant constants with some commentary.
This was not released for some reason? v1.8.0 is latest with Feb 4, 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