Decoding MMSI as int loses leading zeroes

[ajakz]

All of the messages in pyais/decode.py are decoding the MMSI value as an integer. However, if there are leading zeroes (which is possible and valid -- see navcen documentation) they are going to be lost. In order to preserve the full original MMSI value, shouldn't these be parsed into strings?

[M0r13n]

Hey,

thank you for the tip.

I think that you are right and these ints should rather be strings. But I am concerned that changing this would break backwards compatibility. Maybe we should add an option to decide whether one wants a string or an integer?

I am open for discussion.

Greetings

[ajakz]

Adding decoding to a string as an option sounds like a good idea to me.

[M0r13n]

I implemented this feature. From version 1.3.0 on MMSI's are not stored as integers, but as strings with leading zeros. See also #9

[sethwellsNZ]

It looks to me like this issue (or something similar) is still present in the latest release (v2.7.0). I noticed it and came here to see if it had been reported before.

I wrote a simple script to verify:

import pyais
from pyais.messages import MessageType1

print(f"pyais version: {pyais.__version__}")

# Create message with dummy data and mmsi w/ leading zero as string
msg = MessageType1(msg_type=1, repeat=0, mmsi='012345678', status=0, turn=0.0, speed=0.0, accuracy=False, lon=100, lat=200, course=0, heading=15, second=10, maneuver=0, spare_1=b'\x00', raim=False, radio=18980)
print(f"Message created: {msg}\n")
payload = msg.encode()

# Form AIVDM sentence from encoded payload with dummy data for remaining fields
aivdmStr = "!AIVDM,1,1,,A," + payload[0] + ',' + str(payload[1]) + '*XX'
print(f"Sentence to decode: {aivdmStr}\n")

decoded = pyais.decode(aivdmStr)
print(f"Decoded message: {decoded}\n\nDecoded MMSI: {decoded.mmsi}, Type: {type(decoded.mmsi)}")

When I run this, I get the following output:

pyais version: 2.7.0
Message created: MessageType1(msg_type=1, repeat=0, mmsi='012345678', status=<NavigationStatus.UnderWayUsingEngine: 0>, turn=0.0, speed=0.0, accuracy=False, lon=100, lat=200, course=0, heading=15, second=10, maneuver=0, spare_1=b'\x00', raim=False, radio=18980)

Sentence to decode: !AIVDM,1,1,,A,10;iQCP00079hp1jL>0000ND04`T,0*XX

Decoded message: MessageType1(msg_type=1, repeat=0, mmsi=12345678, status=<NavigationStatus.UnderWayUsingEngine: 0>, turn=0.0, speed=0.0, accuracy=False, lon=100.0, lat=-23.696213, course=0.0, heading=15, second=10, maneuver=<ManeuverIndicator.NotAvailable: 0>, spare_1=b'\x00', raim=False, radio=18980)

Decoded MMSI: 12345678, Type: <class 'int'>

As can be seen in the output, when I originally create the MessageType1 object, the mmsi is stored as a string, but then when I decode it later, as seen in the last line of the output, the MMSI gets decoded as an int and loses its leading zero.

[M0r13n]

Hey @sethwellsNZ,

This is intentional. We had some back-and-forth regarding the treatment of leading zeros, and ultimately, I decided to store the MMSI as an integer rather than a string. I made this decision because, according to gpsd.gitlab.io — the de facto reference for this implementation — its data type is an unsigned integer. Additionally, this behavior is consistent with many popular applications. For example, MarineTraffic, which is likely one of the largest platforms in this regard, also doesn't show leading zeros. The same goes for Aggsoft, another high-quality AIS decoder.

If you require leading zeros, I recommend using zfill().

[sethwellsNZ]

Thanks for the info, good to know!