360 imagery on Mapillary is growing! This is great news - we love being able to look in all directions, however, you may have noticed that sometimes the default view for 360 images is a bit confusing (looking to the side or behind).
We’ve released an update to automatically re-orient the 360 image view to the “front” (direction of travel). For example, when you view a 360 image like this, you’ll see a little animation turning the image to look straight ahead.
This update has been made on mapillary.com only for now and will be coming to the mobile apps and 3P users as well as an update to the mapillary-js library.
This means when you shoot 360 imagery you no longer need to point the camera lens to the front in order for your imagery to appear “front facing” on Mapillary. In fact, we generally recommend pointing cameras like GoPro MAX2 to the side to reduce wind resistance and increase clarity on the businesses and addresses to the left and right of streets.
Yes, correct, I meant re-orienting the view (updated in the text).
Do you have any examples you can link to where you’re seeing unexpected behavior? It should maintain your sideways perspective if you explicitly rotate the view there. Generally this is based on the direction of travel so there are some heuristics to account for imperfect GPS making this imperfect as well (but should be significantly better in the overall).
The main problem this is solving is helping users have a clearer understanding of what they’re looking at more expected behavior when using the navigation arrows as well. Generally I think for most users the most intuitive thing is for image views to start pointing in the direction of capture rather than off to the side or behind the capture direction, etc.
This also means that you should drive directly to your POI.
I regret that no osm wikipedian nor osm developer has ever done any serious work around the mapillary key. The OSMers have only been vandalising my work.
@GITNE - yes, reorientations can happen on both (when you initially load an image, and also later when the road turns for example). If as the user you manually rotate the view, that offset is preserved for the sequence (and also captured in the url).
I can’t seem to replicate what you mean by “there is something weird happening when you set a non‑forward viewing angle and then jump to some other image in the sequence using the media bar.” - do you mind maybe recording a small video?
@Lowiekse - the orange cone in the map rotates as you rotate the view, and the map is positioned to be north up, so in your screenshot you are looking north-east. Good idea that this could be made more explicit though!
As i like to shoot lenses left/right i was using “Equirectangular_rotate” before upload and rotated all images by 90°. Some discipline to always mount the camera the same way is needed though
@GITNE - thanks for the feedback - the animation helps give the user context that this is a 360 image view that is being rotated. Without it, its a hard jump which feels like jank and as a user you might get confused about what just happened to what you were looking at.
That being said, I’d also love to see a video screencapture of any issues you or others encounter. Thank you also for the suggestion on disabling, its something we could likely add in a future release (particularly if we see issues for some captures or users).
@flohoff - thank you for sharing. Yes, the new functionality I’m describing basically does the same thing for videos/images that were not previously rotated. Those that were already rotated should remain (correctly) as they are.
Perfect, yes, thank you for these examples @GITNE ! Looks like we need some better handling of these types of transitions. We will get this resolved in an upcoming release. I am heading on a bit of an extended summer holiday - and will be back in the second half of August to resolve.
Thank you for your patience and thank you again for these examples!
I’ve noticed that now, when viewing 360-degree images—for instance, looking to the right—the system tends to reorient the camera toward the front view as you move along. This bothers me because I want to scroll down the street while keeping my view fixed on the shops or building numbers. In short, I preferred the way it worked before. Thanks anyway for the work you do.
Hi @protezionecivilefvgr - thank you for the feedback, we are working on the bugs noted in this thread, however I can’t reproduce the issue you’re referring to. Specifically on a 360 image if I rotate the camera view to the right of a car for example and then press “play” or “next” buttons in the top, the view is kept on the right side of the car, even as the car makes turns. Are you seeing different behavior or still having this problem? If so, could you share the steps you are taking?
Thanks as always for the feedback @GITNE - we are working on it. For clarity, are you asking to fx the arrow/browsing issues you highlighted earlier, or are you saying you don’t like the animation when views rotate to the front (and you would prefer a hard jump), or you don’t want to have your views ever rotate to the front?
Hello, this change has been frustrating for me. I often use Mapillary to share specific framings of places so I can share a before-and-after comparison, and now when the page loads, they all snap to different angles. I cannot think of a reason why this change would be desired. If something is shared via a link with a suffix that shares a specific angle, that angle should be respected.
Everything is broken. Both things lead to even more unstable behavior in an already unstable UI. Overall, the viewer locks up much more often with NaN values than before. Usually, the viewer flashes and the view jumps around before it then locks up.
The web app has become more and more unpolished and unstable. For example, the image carousel still lacks mouse gestures, overlays other clickable UI elements like the “…” button when open and becomes disabled/uncloseable when empty (though pressing N continues to work). Some sub‑menus require separate clicks for them to disappear others do not. Highlighting toggles break with every update in different permutations and are still broken to this day. The “3D” button always opens the small window. The “Image details” sub‑menu no longer disappears when entering the blur editor or opening the “Report image” dialog (you have to explicitly change focus with a separate click). The “Delete entire sequence” button is red but the “Delete image” button is not. I could go on like this but I am tired of it.
@une_abeille - that is a bug - we are able to replicate it and will have a fix out in an upcoming release. Sorry about that. I will update here when the fix is out.
@GITNE - maybe “everything is broken” is overstating it a bit? The upcoming fix will address the issues you found with the re-orient feature (thank you!) We will also fix it so that the “Image details” disappears when opening the “Report image” dialog. In terms of "The “Delete entire sequence” button is red but the “Delete image” button is not." - that is by design I believe because deleting the entire sequence is a much more destructive action. The other points you mentioned I couldn’t quite understand. If possible, a little video would help (maybe in it’s own thread, or the web app bugs thread?)
So, it looks like the view now only reorients at the next image position when clicking a node on the map, a sequence in the feed, searching a location, or when the URL has no x, y, zoom queries. A manually offset view from forward view is retained during playback (which is okay, I guess, though I would have preferred no forward relative reorientation here either but maybe this is intended). The view orientation is now retained when switching between 360° sequences using UI arrows or cursor keys, which is what aligns with my intuition (others may have a different intuition). This view orientation is also then retained when pressing the space bar or clicking the button. Things have improved, although I would generally rather prefer to have a toggle to switch between modes.
The “Image details” sub‑menu disappears after clicking “Report image”. However, it does not disappear after clicking “Add blurs”.
The “Time travel” sub‑menu continues not to disappear after clicking “Compare selected image”. The image carousel strap continues to be visible in the time travel viewer and can also be opened and closed either by clicking the strap or pressing the N key. I am not sure whether this is intended.
The “3D” button continues to always unminimize the small window, regardless of its content (map or photo).
I have not tested an empty image carousel or how it behaves after switching to a sequence without images. Furthermore, the image carousel continues to lack support for mouse gestures and the scroll wheel. However, it does support auto‑scrolling with the middle (third) mouse button.
Super, thank you so much for re-testing @GITNE! Glad to hear the main functionality is working better.
Yes, this is intentional so that if you are interested in looking at the left side of the road (for example) we will retain that even as the capture turns.
Got it, I can replicate this now, and we’ll fix in an upcoming release
Got it, I can replicate this now, and we’ll fix in an upcoming release
The “N” key was intended as a shortcut, but having the panel visible in time travel view was not, will fix in an upcoming release.
Got it, I can replicate this now, and we’ll fix in an upcoming release
Which image carousel do you mean? The “captures nearby” carousel?
The upcoming fix will address the issues you found with the re-orient feature (thank you!) We will also fix it so that the “Image details” disappears when opening the “Report image” dialog. In terms of "The “Delete entire sequence” button is red but the “Delete image” button is not." - that is by design I believe because deleting the entire sequence is a much more destructive action. The other points you mentioned I couldn’t quite understand. If possible, a little video would help (maybe in it’s own thread, or the web app bugs thread?)
This view orientation is also then retained when pressing the space bar or clicking the 
button. Things have improved, although I would generally rather prefer to have a toggle to switch between modes.