Obscure Position Ambiguity Bug

[shackrat]

There's a bug in how position ambiguity is processed. It's likely due to a quirk in the spec..
The bug is when the parser throws a "latitude and longitude ambiguity mismatch" exception because the number of spaces in the latitude is not equal to the number of spaces in longitude. However, the spec does not require any spaces in longitude for position ambiguity.

From the spec (aprs101.pdf)

The level of ambiguity specified in the latitude will automatically apply to the longitude as well — it is not necessary to include any (space) characters in the longitude.

There are a couple ways to solve this, but I feel the cleanest is to simply ensure that longitude minutes (lon_min) has an equal number of spaces before processing the bounding box coordinates. Its two lines of code and the rest of the execution flow remains unchanged. (Technically, following the change, the exception could be removed as I don't see an occasion when it could ever be thrown)

I altered parsing/position.py as follows..

        # position ambiguity
        posambiguity = lat_min.count(' ')

        # From the spec (aprs101.pdf)
        #   The level of ambiguity specified in the latitude will automatically apply to the longitude as well
        #   — it is not necessary to include any (space) characters in the longitude.
        # We will assure that lon_min reflects this at all times
        if (posambiguity > 0):
            lon_min = lon_min[:len(lon_min)-posambiguity] + (posambiguity * ' ');

        if posambiguity != lon_min.count(' '):
            raise ParseError("latitude and longitude ambiguity mismatch")

I apologize for not doing a PR.. I have made other changes to the file as well.

Steve White
aprs.to