pyais: Incorrect decoding field types

After the changes made in https://github.com/M0r13n/pyais/issues/54 I decided to check the field types for every message type in the decoder against the docs.

I have found a number of fields which have incorrect or inconsistent types, I have detailed them all below to be fixed.

All Types

The naming is inconsistent for spare and regional, MessageType18 has reserved and reserved_2 rather than reserved_1 and reserved_2 and both fields change this up on a per message basis. _1, _2 etc should be used for all fields which have multiple instances such as reserved and spare.

Single bit fields accuracy, raim, dte, retransmit, assigned, cs, display, dsc, band, msg22, virtual_aid, power, addressed, band_a, band_b, structured and gnss are boolean according to the docs for some message types and int for others. As these are single bit fields they should all be boolean for all message types.

Currently accuracy and gnss are not boolean for all message types in the library.

Types 1, 2 & 3

turn according to the docs is a Signed integer with scale - renders as float, suffix is decimal places but its type is int in the library. As the docs say renders as float, I believe this is actually meant to be a float.

Type 6 & Type 8 & Type 17 & Type 25

data should be a string representation of the binary and not a int as you cannot have leading 0’s in python integers.

Type 19

reserved/regional naming is completely inconsistent here. Naming for the Regional reserved fields previously has followed reserved, reserved_2… but here it is reserved, regional. The naming of the reserved & spare fields should be consistent across all message types and use _1 as previously stated.

Type 24 & Type 25 & Type 26

The dict of types you provided in https://github.com/M0r13n/pyais/issues/54 appears to be missing vendorid, model and serial from from Type 24 and addressed, structured, app_id from Type 25 & Type 26

I don’t know how you generated them but I presume these missing fields are due to the increased complexity with these types.

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 17 (16 by maintainers)

Most upvoted comments

Done 👍

Just ran a bunch of tests and using the new types, so far looking great! Thanks again

I haven’t been able to check everything yet but I have looked over the changes and they look good. If you want to merge then feel free to. I’ll double check all the types etc sometime soon.

@M0r13n is turn actually a useful value without performing the conversion? I haven’t needed to use (yet) it so didn’t mind leaving it be, but if it’s useless without the conversion may as well just convert it.

Hi @M0r13n and @Inrixia, regarding your discussion on turn vs rate_of_turn. I dont understand how this conversion differs in any way from for example speed, lat and lon? Why is the raw value kept for the turn field and not for the other fields?

For consistency, and better usability, I suggest to also make this conversion during decoding/encoding in pyais.