Here, you can see the blue dot (GoPro’s GPS) is way ahead of Mapillary’s estimated location, but GoPro is actually right about the location, Mapillary isn’t, which makes the signs’ placement completely off
1 Like
Occasionally one starts to write a reply to concur with the original poster, only to find that actually the issue which last summer made orange dots crop up all over te map - bit like measles has now - at least for the series looked at - been greatly improved;
That issue with the computer orange dot placed in a clearly wrong position cropped up regularly,
take this photo taken summer 2023 on a motorway bridge, on the west side; the orange ‘computer’ dot shows the camera well to the east of the bridge: https://www.mapillary.com/app/?pKey=287248174009016, perhaps ¼ minute later the cyclist with camera is still moving along the righthand side of the road yet the orange dot has now ‘flown’ into adjacent woodland: Mapillary;
in both instances the blue dot was by-and-large correctly placed - if you allow for the Hero10 first processing the image, thereafter determining the GPS location, then writing the file to SD-card.
Recently - summer 2024 - in https://www.mapillary.com/app/?pKey=1529271404693562 , it turns out that the blue dot was actually further off than the orange one; ditto Mapillary .
Similar Mapillary where the orange dot is correctly placed just ‘before’ the give way sign, the blue dot incorrectly placed past the sign.
The orange dot in Mapillary is also better placed - at the point where the cyclist took a sharp right hand turn.
In summary looks like the orange dot technology has greatly improved in the past year, to the point where the orange dot can now turn out to be more accurately placed than the blue GPS dot. Looks like the orange dot is now based not just on motion and camera direction, but also taking into account information in the photo, like traffic signs and side-of-way markers. Bravo!!
= = =
This, incidentally, differs from an error in extracting location information from a Time lapse > video or outright video (do not know which mode the contributor used) in Mechelen : please compare the blue and orange dots for Mapillary and https://www.mapillary.com/app/?pKey=1431697040833328: the camera still takes photos at a traffic signal, but the dots have steadily moved on, with the orange dot ‘somewhere’.
And then there was the (time lapse?) video instance where the distance seems to increase at some sharp turn: where the blue dot was about right, followed by Mapillary where the dots are at the wrong intersection, and Mapillary, at the church, but at the same offset; then around Mapillary you have the same dot moving / photo stationary issue we saw in Mechelen.
Also be aware that the Mapillary GUI background is derived from OSM data and that the actual (street) ways may not be accurately placed. I have seen many situations where roads have been overlaid on error offset overhead imagery, others on very widely spaced nodes over non straight roads and of course insufficiently accurate GPS data. In the OSM world some seem to assume that a road way is always correct and place objects referenced to that.
In short many of my Mapillary tracks are often offset on the map GUI for the reasons mentioned.
Yes, it is not uncommon for my the GPS receiver get confused, and think the location is somewhere else then the true location. I think it’s mainly a problem with the interpolation intermediate position, and any bumps and/or movement can case hawok with the GPS-receivers estimates. The position-time image-in-video correlation seems to be a bit of a challenge to get right, (not just in mapillary), short of specialized tools.
IMHO, most GPS receivers are simply not accurate enough, to safely do a map-update based on the raw GPS positions with just single track.
There is a fairly obvious example of that in the following track DashCam track of Tant Gröns Väg, eslicaily if you copre it to the other captured at the same time 360 track of Tant Görns Väg.
The Dashcam track way off from where is supposed to be - for a significant part of the track; and the mapillary’s “estimates” was much closer to the true location for much of it, than I was expecting. Thou at that specific point, I think the estimate might actually be over-compensating for the error. Yes, it’s bad enough that I which I could request that the estimated is published as the track to be drawn in the GUI, rather then original GPS-data.
BTW, I really appreciate the response to the earlier GUI usability issue with “disappearing” blue dots, that was recently corretted, making in these discussions/comparisons much easier.
Wile oh so tempting to just assume the positions are correct, in my experience we should never put too much trust in either the GPS data or Map, as both are likely to be incorrect at some point, especially near near tall objects (e.g. in urban areas near buildings).
I do see value in presenting the raw data, as this builds trust, and holds people accountable for the quality of the uploads. OTHO, it tends to result in a lot of unnecessary/unwanted clutter in w.r.t the tracks in the the MAP - and lots of duplicated detected objects; and that i turn that makes it require more effort to use, so I also see a use-case for only presenting more curated/consistent view with only the “corrected” positions… (and thus a potential future feature, to make that configurable somehow.)
Also worth a mention that some GPS units also have some interpolation and speed/acceleration/cornering “adjustment”. My UBLOX USB unit for example is default coded for stationary rather than mobile use, so it assumes position changes at higher speeds are not always valid. I change the mode every time I start a Mapillary track as it doesn’t have an EEPROM.
If I want to alter a road routing in OSM I use 2 GPS devices, sometimes in both directions to reduce errors. The four tracks can then be used to calibrate the overhead imagery before use.