facebook/Rapid

Mapillary image positions -> Corrected or original

eneerhut opened this issue · 5 comments

eneerhut commented

Description

There is some user feedback here that we might want to use the original GPS positions rather than Mapillary's computed positions. It seems we are using the latter now. Just filing this for consideration. We need a better sense of which positions are more accurate on average and use that as the image location.

image
Original

image
Corrected

tsmock commented

What I do in the JOSM Mapillary plugin is look at the delta between the computed and reported location; if the delta is too big (>6m), I just use the reported location. This only happens after I download the sequence though -- AFAIK, the computed location vector tiles don't have the non-computed location.

This fixes issues like this: https://rapideditor.org/edit#map=19.04/39.10021/-108.34914&background=Bing&datasets=fbRoads,msBuildings&disable_features=boundaries , but only after the user clicks on the sequence.

gchapbbhn commented

Hello,
I'm not sure I understand how you do it?
I loaded images into Mapillary (with an RTK position), but after the recalculated position is totally wrong and it's a problem for me...
Here is the description of my problem:
https://forum.mapillary.com/t/wrong-position-of-images-after-mapillary-calculation/8417

tsmock commented

Exif has a GPSHPositioningError field. I don't know if Mapillary uses it (or trusts it). I also don't know if your images had that field set.

I do know that the editors (JOSM/iD/Rapid) will only be able to read that field when we download the image, assuming Mapillary doesn't strip exif information for storage reasons (IIRC, they don't do this, but I'd want to double check). We could then show the image at the "correct" location, but it wouldn't correct the track.

Anyway, one reason to use the computed information tiles is that fixes issues where an image had a bad orientation set on upload, while the computed orientation has it pointed in the "correct" direction.

  • 👍1
eneerhut commented

I have seen a few examples recently where the computed positions saved the day for both the compass angle and the image location. I'm don't think a switch to original positions would be a net benefit. Here are two examples:

  1. Example 1.
  2. Example 2.

@gchapbbhn it sounds like the best course of action here is to figure out why Mapillary is struggling to compute positions from the imagery, despite or perhaps because of RTK positioning.

bhousel commented

Hey all, sorry I forgot to comment on this issue before.
I switched from the original positions to the computed positions in 224ed83 because I was doing a lot of testing with the Mapillary detections (objects and signs) and the computed positions and camera angles seemed to better match up with the detections. My thinking is that, while all the viewcone camera angles are approximate, we want to avoid showing the user viewcones that are really pointing in the wrong direction.

I don't have an opinion about which is better, but I see these as the options for us:

  • use original positions
  • use computed positions
  • some mix of the two approaches (original positions + computed camera angles?)
  • do nothing and hope the computed positions improve

In any case 224ed83 is pretty simple and contains the code pointers for what we would need to change.