How does Mapillary correct GPS location

GPS correction of images uploaded to Mapillary

I recently uploaded a sequence to Mapillary, but the GPS signal from my GoPro Max was very subpar. This was probably due to a lot of tall buildings disturbing the GPS-signal. After the images was processed I noticed that the images are located correctly relative to each other when enabling 3D mode, but they are incorrectly placed on the map. Navigating by the arrows therefor works poorly, but clicking on the next 3D sphere works great. Does Mapillary correct the green dots on the map after some further processing?

Yes, Mapillary will attempt to do some correction of GPS signal noise using OpenSfM (https://opensfm.org/) - Structure from Motion. However we don’t yet display these corrected green dots on the map - that is something we would like to do in the future.

3 Likes

I’m also seeing this:

Is the orange/yellow marker the corrected GPS position?

Considering that I’m using RTK GNSS receiver with nearly centimeter accuracy, GPS position modification would mostly be a degradation of my data.

1 Like

Yes, I overall understand the process. You determined relative orientation between two images that have common features and, then, you do a global optimisation combining relative orientations and absolute (although approximative) positions from GPS.

Still, what are the yellow/orange dots?

I see a very bad case, where image view overlapping is also poor:

Thank you for the feedback on this! This is an area we’d like to look at more (and make our computation more accurate in general). Stay turned.

1 Like

Agreed - we have improvements we can make in this area - both with the position and the camera direction

2 Likes

I can understand trying to calculate the “correct location” for some internal processing. But it’s wrong for almost all the locations I’ve checked in the past month. If you want to show that indicator before it’s accurate while you develop the algorithms, that’s fine I guess. But the actual indicator is now gone - I have no idea which point I have selected, because the estimated point is almost never there. This has turned from an experimental feature into a usability issue. The first time I saw it I was convinced it was some sort of rendering bug offsetting the indicator.
actual point

@HellPhoto - Agreed that we have work to do here - though I don’t believe this functionality has changed recently? The original position is visible before you click on a point, and the computed one is shown after you click on a point.

Yes, this has been an issue for a while. Once I move the mouse cursor away from the point that is clicked - it is no longer visible. Only the orange one remains. It only shows up if you mouseover sequence navigation buttons (and those are technically next/previous points):
mo

Got it, thanks for the confirmation. We’ll put working on improving this on our backlog, thanks so much!

A sample of strange computed position on a linear road:

Dear @boris,

Please do not ruthlessly ‘improve’ the location of for example Mapillary : viewed against the background of either OpenStreetMap, or -logged-in at OSM- against the Digitaal Vlaanderen GRB (= official couple of centimeter or so accuracy map) the GoPro Hero9’s position is - in a difficult location, given tall buildings on two sides - much better than Mapillary’s ‘computed’ then fiddled -but actually fumbled- location;

just looking at the picture you’d see it was taken somewhere in line with the underpass (which is clearly shown on the GRB layer in OSM), whereas the ‘corrected’ position places it - my guess, as a scale stick is missing on Mapillary - some 20m to the left, as if I were cycling straight at the middle of that apartment block - quod non.

= = = another example :

Looking at Mapillary you’ll see it was taken at the ‘jump’ in the building line, GoPro shows it perhaps 2m ahead of where I was, and perhaps 1 - 1½m to the right; Mapillary has correctly corrected that forward bias, but placed me in the raised planter, which you can see wasn’t the case, thus shows a worse sideways accuracy.

So by all means keep trying, but for now you’d likely benefit from betting on both some 3D-model builder and actually analysing the photo for clues.

Spotted other examples, where a photo taken on a path was ‘corrected’ to be way beside the path; think correcting in urban surroundings will be of most benefit?

Met als immer vriendelijke groet,

Absolutely, we will always make the “raw” location available, so that should be something users can always consult. As you mentioned there are lots of issues with the current “computed” location - which is precisely what we either need to fix (or perhaps stop showing in cases where we know its unreliable).

You can see in the following sequence recorded on a motorway in open field area with RTK GNSS that “computed position” is just stuck at a point for more than 20 pictures. Later, you can see it jumping left or right from the track.