Closed DavidIngraham closed 7 years ago
You're right. It's an oversight and faulty assumption when I migrated the code over to all attributes.
I'm away presently and will wrap my head around this when I return shortly.
As you know, the conflicting namespace needs a workaround. As agps.py was intended to be a simple, thin gpsd client, (cf. lines 23-25) this was won't be happening, on my part, anytime soon. The hack/fix is to comment out line 144 to sidestep the problem until a fix could be implemented.
The standard deviations of latitude and longitude presented by the class "GST" will present as 'sdlat' and 'sdlon', if either is available.
Please excuse me if I'm misunderstanding how to use the library.
I'm experiencing a problem where the lat and lon values from the GST message (which indicate the standard deviation in meters of the latitude and longitude estimates) are being unpacked as if they are the actual lat/lon. This is because their keys in the GST message are simply 'lat' and 'lon', the same as the actual lat/lon reported in the TPV message.
Is there an intended workaround for this?