mapd node distance in ft when set to m

[jprous]

Describe the bug

It seems like the distance to the next node in mapd is shown in feet even when the units are set to meters.

Provide a route where the issue occurs

cannot upload route as loggerd is disabled on beta2

openpilot version

beta2

Additional info

The distance displayed in the UI is correctly denoted "m", but the value is 3 times larger than the actualy distance, assuming the integer shown has not been converted from feet to meters. I checked this today by taking note of the place the next node showed (800m), and then aggresively ticks down. The distance to the intersection as measured on google earth is in actual fact just over 200m.

[Stupefacient]

Sound like mapping error your part. Remember gps is off by 15m+/- at all times. Often on OSM your mapping imaging is always off that much if not more. Sounds like your nodes is way off.

[Stupefacient]

https://youtu.be/o-RbnLVNHBM

video proof

[Stupefacient]

Google maps/earth is incredibly an accurate way to measure things. Considering they do a lot of postprocessing and manipulation to get everything to fit properly. They only claim accuracy of 20m+/- themselves

[jprous]

Hi Dragonpilot-Community/Dp-Devel (Stupefacient), Thanks for all your replies, much appreciated. Also, especially thanks for the video, this helps the argument. Please hear me out: I assume the video recording is displayed on youtube in 1:1 time (1 video second equals 1 second traveled by the car). So, you can test this for yourself: I noted down the distance shown in the white speed limit block in the left top corner from video second 18 to video second 23 (5 seconds). I also note the speed shown in each second frame and convert km/h to m/s. Over 5 seconds, the average speed is 74km/h, or 20.6m/s. 20.6m times 5 seconds equals 103m. However, the distance to the speed limit node of "0" is 1010m at frame 18 and 690m at frame 23, a difference of 320m. For the car to travel 320m in 5 seconds, it would have to be going at an average speed of 64m/s, or 230km/h. The difference in distance is roughly 3.2 times more than the car could have traveled in the 5 seconds of the video (as observed). The ratio between feet and meters is 3.28, which is why I believe the value being displayed is the distance in feet and not meters (although it shows the value marked with a "m".). So somewhere, a conversion is done incorrectly, or not at all. Although this is crude, the error is too big to be due to GPS in-accuracy. BTW, I have implemented this factor in my speed reduction distance decision, and I am now getting perfect stopping distances. For reference, here is my tabled calculation: video seconds s dist km/h m/s 18 1010 m 79 21.94444 19 970 m 79 21.94444 20 910 m 77 21.38889 21 790 m 73 20.27778 22 740 m 70 19.44444 23 690 m 67 18.61111 Avg Avg Average distance traveled 5 320 m 74.16667 20.60185 103.0093 m I trust that you would re-consider and have a closer look. Thanks again for the video! I cannot record such currently since I am running beta2. Regards, Jean-Pierre On Fri, 10 Mar 2023 at 12:31, Stupefacient ***@***.***> wrote: Sound like mapping error your part remember gps is off by 15m+/- at all times. Often on OSM your mapping imaging is always off that much if not more. Sounds like your noses is way off. https://youtu.be/o-RbnLVNHBM video proof

…

Google maps/earth is incredibly an accurate way to measure things. Considering they do a lot of postprocessing and manipulation to get everything to fit properly. They only claim accuracy of 20m+/- themselves — Reply to this email directly, view it on GitHub <#46 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AZ3EXAKGYCYZEK3PWZ3NBTLW3L7JLANCNFSM6AAAAAAVTY5R44> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- Jean-Pierre

[Stupefacient]

This isnt a bug it's it mapD bug aka the move fast team

[eFiniLan]

@jprous would you be able to use dashcam feature in beta2 to record the video?

I checked the UI source code and the display does the conversion to mph so the first thing I can iron out is the UI error.

It could be something related to OpenStreetMap data if you can take a look at the path you drove and see any suspicion.

Perhaps we can invite move-fast team to take a look why it's doing that if we have more details from above? @rav4kumar is it possible?