60 Mph/97 Kph

[llayden]

Not when they're pretty much irrelevant, have no real impact on the function of the app and would require a rewrite of the code.

via Tapatalk

"Irrelevant" is subjective. It's a bug, probably not a big one, and should be fixed. Opting to do things half-assed is not the way to code.

Its not even a 'bug'. All measurement instruments have limitations - especially digital ones. Analog instruments, which in theory at least have an infinite range of values are often connected to computers by an analog-to-digital converter which slots ranges of values into discrete digital quanta. This immediately introduces an imprecision or 'bug' if you like. For example, I have a measuring device (it actually measures resistance but that is irrelevant) that outputs a current between 4 and 20 mA - a very typical scenario. This is connected to another device which contains an a/d converter that outputs a number between 0 and 127. I configured this device to output a number from 0 to 100 and thought no more about it. I was interested in the shape of the distribution and was mildly irritated some months later to get a typical bell shaped curve but with spikes at approximately every fourth value. The reason was simple 128 values were being squeezed into 101 values so 27 of them were getting doubled up. There was no way I could give the end user a properly shaped curve and the intuitive 0-100 scale they expected. I changed the output to 0-127 and simply told the users that 0-100 was impossible! The point is that ALL instrumentation has limitations and my example above is exactly inversely analagous to what is happening with the 60MPH problem. Here a smaller number of values (in knots) is being distributed into a larger number of buckets (mph) so some of the buckets have no value to throw into them. Its not half-assed - just a different number of asses on each side of the problem! Its not a bug. You are simply asking for the impossible! There is no definitively right scale in which to measure speed. Why not get modern and forget your archaic miles anyway. Switch to kms where the number of empty buckets will be even greater!

[harling]

Its not even a 'bug'. All measurement instruments have limitations - especially digital ones...

My research at the time suggested that the speed reported by typical handheld GPS hardware is accurate to within about 0.1mph. Since the speed received from the hardware is a float, it could be converted to tenths of a Knot (or some other unit 1/10 the current size) and then converted to an integer speed in mph or kph without false precision.

IMO it is a bug, but low priority compared to other efforts. Conversion constants are used both when the value is received from the GPS hardware and stored, and when that stored value is read to be displayed in the GUI. I would estimate a day or two to make the changes and test thoroughly, but since I don't have access to the 3.x code base, I'll have to wait until their staff developers get a Round Tuit.

[leocylau]

but low priority compared to other efforts

Yes, it is low priority but it shouldn't take a year and a half. The first post of this thread from seaside is dated-back to 23 of Jan, 2011

[harling]

but low priority compared to other efforts

Yes, it is low priority but it shouldn't take a year and a half. The first post of this thread from seaside is dated-back to 23 of Jan, 2011

Yes--and I practically wrote them a design spec on how to fix it. I don't know how many developers they have working on the client, or their project schedule, but I'd be glad to sign an NDA and work on it on a contract basis--and I'm sure I'm not the only one.

[invented]

but low priority compared to other efforts

Yes, it is low priority but it shouldn't take a year and a half. The first post of this thread from seaside is dated-back to 23 of Jan, 2011

Yes--and I practically wrote them a design spec on how to fix it. I don't know how many developers they have working on the client, or their project schedule, but I'd be glad to sign an NDA and work on it on a contract basis--and I'm sure I'm not the only one.

Is there a thing on uservoice about this bug?

[gettingthere]

Uservoice is for feature requests, not bugs. There is a section in the Wiki for known issues. But who knows of Waze checks it. Surely Waze has some type of bug database or at minimum a list of bugs and priorities. Surely this is at the very bottom of the list.

[invented]

Uservoice is for feature requests, not bugs. There is a section in the Wiki for known issues. But who knows of Waze checks it. Surely Waze has some type of bug database or at minimum a list of bugs and priorities. Surely this is at the very bottom of the list.

the Uservoice is for:

This is the place to post current problems, enhancements and general suggestions for any aspect of our website – the cartouche, dashboard, community page, homepage, etc.

So let them prioritize it accordingly.

[ituajr]

Earlier someone said:

Remember that GPS receivers don't really "measure" your actual speed, they just compute an average speed over a short interval, i.e. it calculates your geographical position (latitude/longitude) through a sort of cross bearing with "visible" satellites. Then it waits for a specified time (mostly 1 second) and does the same thing again. Now it can calculate the difference between the two positions...

This is completely wrong. See for example section 3.3 of http://www.navcen.uscg.gov/pubs/gps/gpsuser/gpsuser.pdf

GPS receivers typically calculate velocity by measuring the frequency shift (Doppler shift) of the GPS D-band carriers(s). ... Velocity accuracy can be scenario dependent, but 0.2m/s per axis (95%) is achievable

The earlier statement that the speed can't be accurate because the positions aren't accurate is wrong, and shouldn't be used as a justification for not fixing the speed display bug. Of course, there may be other reasons, such as limitations of Apple's GPS implementation.

[bgodette]

GPS receivers typically calculate velocity by measuring the frequency shift (Doppler shift) of the GPS D-band carriers(s). ... Velocity accuracy can be scenario dependent, but 0.2m/s per axis (95%) is achievable

The earlier statement that the speed can't be accurate because the positions aren't accurate is wrong, and shouldn't be used as a justification for not fixing the speed display bug. Of course, there may be other reasons, such as limitations of Apple's GPS implementation.

The location APIs for both iOS and Android both give you the instantaneous speed in m/s via the method above, simply because that's what comes out of all off the shelf GPS chips.

Given that what comes out of the location APIs for speed is in meters per second, I don't see why they're doing any conversion to knots to begin with. Just store it as meters per second and convert on display.

[harling]

Given that what comes out of the location APIs for speed is in meters per second, I don't see why they're doing any conversion to knots to begin with. Just store it as meters per second and convert on display.

Since 1m/s ~= 2.25mph, storing m/s directly (as an integer) would actually make the problem worse. (Tenths of a m/s would be fine.)