Inaccurate placement of marker

[tordans]

I try to use the new feature to "Sync viewer and map markers" to tag a playground on OSM.

Image key: jYNjmv7P567FSw92Z1_DEw
User: tordans

Testing application: https://bl.ocks.org/tordans/339312be319c977a4485a6f56c9800bc

The issue:

I placed map marker on the foot path that is on the playground. I did this on several images. The Markers all show up somewhere else on the map.
In the last case, the image alignment seems to be completely off (see red arrow).

Expected behaviour:

• only images are available that actually align with the surroundings
• the map marker that I place on the same street actually show up at a very similar position when placed on multiple images
• maybe the problem is, that I only have yellow GPS accuracy (color of the icon in the app when taking pictures) … but this is the default-quality inside Berlin and also something the app should handle internally

Screenshot

[oscarlorentzon]

Thanks for reporting @tordans.

We are aware of the issue, I will refer to the following blog post for an explanation:

https://blog.mapillary.com/product/2017/03/29/mjs-mouse-marker.html

"There are currently some limitations to the behavior of the marker and mouse APIs. In general, it will work well in areas that align well with:

• Fairly flat areas with no hills or large altitude differences.
• Photo sequences with a lot of overlap between the photos (photos taken with small distance between them, generally less than 5 meters) where the camera was held upright.
• Photos with good GPS latitude and longitude positions as well as correct compass angles.

If the area is not flat enough, our ground approximation may not correspond to the real ground very well. If the GPS positions are not correct, the markers will be shifted between the map and photo. If the camera was not held upright, the 3D alignment in the photo may be incorrect. We will work on support for and improved handling of some of those cases in the future."

I will add to this that there is a larger chance of getting good image data for placing markers if using a 360 camera instead of a mobile phone or similar because of the larger field of view and therefor higher probability of finding good correspondences between the images.

We will look at ways to improve this behavior in the future both with respect to the underlying data and to how/when you are able to interact in the viewer.

[tordans]

@oscarlorentzon thanks for explaining.
The thing is, those limitations seem to be pretty severe and not well explained in the UI ATM.
Until this is better, I don't think the tool is very helpful in openstreetmap/iD#4426.

A few ideas how to address this
a. Make sure people understand the inaccuracy

• show a warning in the placement tool whenever the data is not good enough
• change the UI in the placement tool to show a area whenever the information is too rough to know more than "this is in this general area" (the same way that apple/google make the current-location-map-pin a big circle area when GPS is bad)
• disallow the tool for cities

b. Provide feature for those who take the picture to fix the inaccuracy

• allow picture lat/long to be move
• allow picture-angle to be change
  This way, I could move the images that are interpreted falsly by the software and manually fix the point-map(?)

Viele Grüße, Tobias

[tordans]

@oscarlorentzon I came across this article that discusses the same problem of bad GPS placement in cities. Maybe this could help in this case as well? https://eng.uber.com/rethinking-gps/

[oscarlorentzon]

@tordans Sorry for getting back late.

Thanks for all the suggestions in a). We will consider them in future releases.

Regarding b). It is already possible to move pictures and change the bearing on mapillary.com. It is more related to the map an not something that will be part of MapillaryJS.

The GPS placement problem needs to be solved at capture time. Using ideas like the one you shared in our apps would be interesting.

[mrAceT]

It is important to realize that an image has more that one latitude/longitude pair!

My experience is that the SfM lat/lon (SfM = Structure from Motion) that is calculated is (most of the time) superior.

I wrote about this one the Mapillary forum also:
https://forum.mapillary.com/t/sfm-lat-lon-not-in-api-lat-lon-question/2881/18
(there's a cool link there which shows the difference in an animation!)

AD: I am seriously hoping that Mapillary will make it possible so that I can more easily get the SfM coords.. (I now sort of needed to "hack the system"..)

[ptpt]

Hi @mrAceT we are planning to expose SfM coordinates and camera angles in https://www.mapillary.com/developer/api-documentation/#images

[mrAceT]

Drop a line when I can test!

PS: it works now, but is slow and I fear that the way I solved it now is OK in a test environment, but is way to much of a load on the Mapillary API when used on a public site.. (which I eventually plan to do...)