Clarify that longitude/latitude precision is reduced with this library

[reportingsjr]

I just spent a couple of hours trying to figure out why I was only getting 4 decimals from my gps wing with this library only to realize it is because the calculations used in _parse_degrees cut off a serious amount of precision.

This library will output decimal degrees to four places which, according to this wikipedia page, gives a precision of ~10m which isn't great.

It would be nice if a way to get higher precision decimal degrees was added to this library, even if only for logging rather than doing calculations.

[ladyada]

hiya - we dont see where it cuts off the precision - it looks like we just parse it as a float?

[reportingsjr]

It is parsed as a float, but since floats in circuitpython are single precision and not double precision you lose data when it is cast as the float.

The data comes in as a string like "8451.4091" and the 51.4091 (the gps minutes data) is getting reduced to 51.41.

[ladyada]

i dont think that's a floating point issue? on a feather M0, 51.4091 is stored & printed the right way

x = 51.4091
print(x)
51.4091

[reportingsjr]

@ladyada It happens when the data, which is a string, is cast to a float.

I'm using an adalogger M0 feather. When I open the REPL (via Mu) and run the following snippet (which is what the gps library does) I see the precision loss:

float("8051.4091")
Which returns 8051.41

I ended up replacing the _parse_degrees function with something jank-tastic so I could get 6 decimals of data out of the gps module.
https://gist.github.com/reportingsjr/65195f67e43f47d8a5200f3b6742d875

6 decimals is about .1m of precision (see the table on this page: https://en.wikipedia.org/wiki/Decimal_degrees) which isn't super useful, but since I was already trying to get more decimals out I figured why not throw in an extra digit of precision!

[reportingsjr]

Just to provide an example of the difference here..
In this first image by firmware was just using the format function with the lat/lon from the latest release of this library a la '{} {}'.format(gps.latitude, gps.longitude)

Here is my firmware after I switched to my janky way of getting higher precision:

(pink line is gps data, brown lines are hiking trails)

[ladyada]

interesting...

>>> float("8051.4091")
8051.41
>>> float("51.4091")
51.4091

so yeah its a precision thing. thats annoying. ok so we need another solution. i'll think!

[ladyada]

OK it seems like you could have 2.4 floatingpoint just fine, its the 4.4 thats :(
so do you want to try parsing both sides and then storing as int degrees and float minutes?
or could do int degrees and 'fixed point' minutes, then return a tuple?

[reportingsjr]

When you say 'fixed point' do you mean storing the minutes as 10000*mm.mmmm so it is no longer floating point?

I think this is kind of ugly and the right way to this is probably as such:
Return a tuple of int degrees and float minutes, but include have a function in the library that does the nasty 'fixed point' hacks to create a string that is decimal degrees.

There is no other way to get the full precision as far as I can tell.

[ladyada]

kk
@dastels you just did some GPS stuff, any thoughts?

[dastels]

It worked fine for my purposes, which was getting a rough distance no finer than 1/10 of a mile.

[ladyada]

k well, @reportingsjr i think the tuple may be the best way to do it then!

[reportingsjr]

Ok, I can create a pull request this weekend!

…

On Wed, Nov 7, 2018, 13:23 ladyada ***@***.***> wrote: k well, @reportingsjr <https://github.com/reportingsjr> i think the tuple may be the best way to do it then! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAO8sFNd9D85ZIsCE5i2-btGBh3MZqL2ks5usyUFgaJpZM4YNFrY> .

[ladyada]

ok thanks!