Has anybody thought of using The DJI OSMO with Mapillary? I’d like to but can’t see, to figure out how.
I guess you should use the uploader on the website or an upload script @tryl knows all about upload scripts.
I don’t know if the osmo has gps, otherwise you could use a free app on your phone to record a gpx-track
1 Like
If you have the images you needs to geotag them. Either with your favorite GUI program or with the python scripts in https://github.com/mapillary/mapillary_tools/tree/master/python . Then you need to upload them, as @Harry described.
Basically it is the standard action cam workflow. Just ask any question here 
Hello! I made a tutorial but I can’t post it since I’m too new of a user.
I made a post on the OpenStreetMap community forum: Tutorial: How to make geotagged image sequences with a GPX track and a timelapse video - General talk - OpenStreetMap Community Forum
1 Like
I’m currently working on a pipeline to process video recordings from the DJI OSMO 360 for use with Mapillary. Here’s a draft:
Previous experiences and misconceptions: Unfortunately, a DJI OSMO 360 (firmware version November 2025) doesn’t record GPS information in time-shift mode. Therefore, for recordings suitable for Mapillary, you have to use video mode, which generates enormous amounts of data.
Operating a DJI Osmo 360 in video mode consumes a lot of power. Who wants to climb onto the car roof every 100 minutes during a long trip to change the battery? And since you’re usually not traveling alone, the constant worry about the camera’s battery level, as well as whether a sudden downpour might damage the USB-C port, can be nerve-wracking for fellow passengers. Fortunately, the Osmo 360 has hidden charging contacts on its underside. Third-party clamp mounts with these contacts are already available online. This allows for a waterproof, continuous power supply and uninterrupted recording. And now for the particularly welcome news: unlike the Insta360, DJI doesn’t impose an 8-second pause after 30 minutes. Uninterrupted long-distance recording – that’s a statement from DJI.
The UL2GSV tool OSV2GPX, extracts a GPX file from the OSMO raw data. The exported GPX file length doesn’t take into account whether the video being loaded is edited; it only extracts the time information from the video. The GPX file must therefore be externally trimmed to the video segment’s route.
But hey, at least we have a GPX track; it won’t be easy, but we can work with it.
The UL2GSV team certainly deserves our support in the form of a donation for their excellent preliminary work in making DJI GPS recordings accessible to us.
| Step | Description | Result / Purpose |
|---|---|---|
| 1. Recording | Record a route with the DJI OSMO 360 camera. To obtain a usable GPX track, I recommend using a universal Bluetooth GPX remote controller from STARTRC. | Raw video + GPS data embedded in camera files |
| 2. GPX Generation | Use OSV2GPX to extract the GPS track from DJI raw data | Complete GPX file with all trackpoints |
| 3. Error Correction in JOSM | Open the GPX file in JOSM. Manually correct faulty sections (e.g., tunnels with no signal). Curves can be redrawn by hand. | Clean GPX file without signal loss |
| 4. Macro 1 – Reduce Node Density | Excel VBA reduces the point density by a factor of 20 | Prevents oversampling when importing GPX into Mapillary |
| 5. Macro 2 – Time Interpolation | Missing timestamps on manually drawn nodes are interpolated | Continuous timeline, essential for video synchronization |
| 6. Final Result | Combine each video segment with its corresponding GPX file | StreetView‑ready video/GPX pairs with clean synchronization and no GPS dropouts |
This is a rough draft. However, I can use my existing workflow for the Insta360, which uses Excel macros, as a basis for a pipeline suitable for DJI Osmo footage. What do you think?
The concept is good, but why using a Macro? It’s more easy to use a powershell script with Exiftool (and ffprobe/ffmpeg). With Gemini or ChatGPT is a script easy to produce. You’re also more flexible when you’re using menu choices. But that’s my opion 
My experience with AI so far is that it promises a lot but delivers little. I prefer to develop a workflow step by step, ignoring all the grandiose promises of AI solving everything at once. With Excel, every step is understandable. For Insta360, I’ve already created my own working batch processing workflow—a workflow for which I’ve applied AI, but whose code I can trace step by step and therefore doesn’t slip out of my control.
I’m very open to parallel suggestions for implementing these steps with other tools, which is precisely why I’m publishing this project here at a very early stage. May the best solution win.
1 Like
DJI Osmo 360 + Mapillary – First upload experiences & current GPX issue
I’ve started testing the DJI Osmo 360 (8K/24 fps) on Mapillary.
Upload itself works perfectly – even large sequences up to 25 GB -Note: In practice, Mapillary accepts uploads of up to 50 GB.- (~14 minutes at 8K/24p) are accepted without problems.
The current issue
The automatic image sequencing stops exactly at the halfway point of the route.
Reason: The OSV2GPX tool (which extracts the GPX track from the raw DJI videos) currently writes every single track point twice into the GPX file. As a result, the timeline runs “twice as fast” as the video, Mapillary thinks the sequence is finished after half the images and ignores the rest.
Workaround
Clean the GPX file before upload: remove the duplicate points (and optionally thin out the track density). The simplest way for now is probably to use an external GPX tracker and keep an eye out for DJI updates that bring improvements.
Image quality
Even in poor lighting (overcast, dusk), resolution and especially the readability of signs, house numbers, etc. are excellent for a camera of this size and price.
GPX options compared
- DJI Remote Monitor Controller
It delivers a GPX track with precise recording start/stop times. Unfortunately, this GPX receiver produces such a poor GPX track that it’s likely the manufacturer is currently missing crucial keys for reliable satellite reception due to potential sanctions.
Huge convenience advantage: start/stop recording with a single button, no extra device needed.
Downside: the GPX is not updated if you later trim the video in DJI Mimo or any other editor. - External GPS logger (Garmin, OSMAnd, phone app, etc.)
Works just as well and is completely independent of later video edits → currently the simplest and most reliable solution for Mapillary. - Third-party Bluetooth remote controls
That advertise themselves as DJI compatible. The disadvantage is that these rely on updates from external manufacturers. GPX track with precise recording start/stop time, A GPX track that meets current technological standards
Important difference to Google Street View:
Mapillary happily accepts Osmo 360° videos without embedded timestamps. For GSV you still have to embed the timing with OSV2GPX.
Conclusion & recommendation for Mapillary users
If you want maximum simplicity right now → just use any external GPS logger or your phone. The Osmo 360 delivers outstanding 360° imagery for Mapillary even without the internal track.
If you already have (or plan to buy) the DJI Remote Controller, you get the most convenient one-button recording workflow and an instantly usable GPX track – just clean the duplicate points once (a short script or manual cleanup in JOSM/QGIS is enough).
As soon as the duplicate-point bug in OSV2GPX is fixed, the Osmo 360 + Remote will probably become one of the most convenient and affordable 8K 360° solutions for Mapillary.Hope this helps others who are testing the same setup! Update: DJI OSMO, anybody tried or knows how to make work with Mapillary - #26 by osmplus_org
(Examples of my first uploads are visible here: [Test Upload])
@osmplus_org - thank you for sharing your experience! Do you think you might be able to share an example of a raw video file you get from the DJI Osmo 360 and an example of a raw GPX trace you get from the DJI Remote (for the same video file).
We’d appreciate having a copy for our testing at Mapillary - again these are the raw unprocessed versions (before sending through any tool). Thank you so much in advance!
A DJI Osmo 360, when used with a DJI remote, generates attached raw files (my license to test these files is CC0). Currently, third-party tools like OSV2GPX are required to create a GPX file from these files.
To give users maximum flexibility, the desktop uploader could offer the option of pre-selecting camera profiles. With such profiles, uploading unedited raw camera data up to 50 GB per sequence should be possible. The desktop uploader should then output a GPX file, which the cameraman or camerawoman can edit. After re-uploading, Mapillary would handle the final processing. Only the route of the edited GPX file would be published. Editing or GPX enhancement could be done with the OSM editor JOSM or any other GPX editing software.
Thanks so much @osmplus_org !
Looks like exiftool also supports extracting .gpx from the .osv file.
Thank you, that’s very interesting information for me. I’m currently noticing that the GPX track extracted with the OSV2GPX tool shows extremely different speeds compared to the video. https://www.mapillary.com/app/user/osmplus_org?lat=47.457603236764015&lng=12.363177758953952&z=17&panos=true&username[]=osmplus_org&pKey=1551988939181586&x=0.30513986230430395&y=0.6091746677677109&zoom=0.42990654205607476&focus=photo Even a test reduction of the GPX points showed no improvement. I’m currently a bit stumped, and would next try changing the GPX times by recalculating them.
OSV2GPX consists of two separate functions: one for extracting the GPX track, and the second function adds the video time, which GSV requires, to the video file. Since Mapillary can easily process the video file exported by DJI Studio even without timestamps, we can focus solely on the GPX track for Mapillary with the DJI Osmo 360. Your information that exiftool can also extract a GPX track from the camera’s raw file .osv is therefore very helpful. The question is whether the GPX track generated in this way remains synchronized with the video.
I have original .OSV files from the DJI Osmo 360 camera (example filename: E:\Sonntag\DCIM\CAM_001\CAM_20251116120149_0002_D.OSV).
Could you please tell me the exact exiftool command you use to successfully extract a working .gpx file from these?
I would really appreciate the precise command. Thank you!
Sure thing, I used:
exiftool -p /usr/local/bin/gpx.fmt -ee3 -api largefilesupport=1 "FILENAMEHERE.OSV" > out.gpx
Note that this does require you to have the gpx.fmt file saved to /usr/local/bin/gpx.fmt
However, after uploading the capture to Mapillary I think I see the same issue you’re describing (gpx out of sync with video). I don’t have the time to troubleshoot at the moment, would be worth looking at the the fps of the video perhaps?
2 Likes
Apparently, the DJI OSMO features really nice 360° image quality. 
I bet the original image quality is even better than what we can see on Mapillary. And, although at closer look the imagery suffers from blurry edges due to that wide fixed aperture, the quality overall may be even a bit better than what MAX2 is able to deliver.
Could you please also share some 16 MP planar images that the OSMO, according to the specs, should be capable of?
I created a time comparison between GPX and video, and asked an AI what caused this offset. The AI’s answer:
Subject: DJI Osmo Action 4/5 (360 mode) – severe time distortion due to GPX timestamp rounding to whole secondsMany users of the DJI Osmo Action 4 and 5 in 360° video mode (especially 5.7K/24 fps or 8K/24 fps) experience massive time distortion after upload: a real ~40-second ride is shown in Mapillary as 1:40–2:00 minutes.Root cause
- The camera records video at exactly 24 (or 25/30) fps → one frame every ~41.666 ms
- The embedded/sidecar GPX track contains only ~1 GPS point per second and all tags are truncated/rounded to whole seconds (no milliseconds)
- Mapillary distributes the extracted frames evenly over the GPX timestamps → because the GPX duration is only ~28 s for a real 41 s video, the sequence is stretched by a factor of ~3.6× → displayed duration becomes ~1:41 instead of the real ~41 s
This is not a Mapillary bug per se, but the combination of
- very sparse GPX (1 Hz)
- complete loss of sub-second precision in the timestamps
creates a worst-case scenario that Mapillary currently cannot handle gracefully.
Other 360° cameras (Insta360 X3/X4, GoPro MAX, Garmin VIRB 360, Ricoh Theta Z1 etc.) either
- write GPS points at video framerate (or close to it), or
- keep millisecond precision in the GPX, or
- offer a “high-precision track” mode
→ therefore they do not show this extreme distortion.
Request / Suggestion
It would greatly help DJI Osmo 360 users if Mapillary could implement a small heuristic for this very specific case:
“When the camera model is detected as DJI Osmo Action 4/5 + 360 mode and the GPX has no sub-second timestamps and ≈1 Hz density, assume the real timing is based on the video framerate and interpolate accordingly (or at least offer an upload flag --use_video_duration_for_timing).”Alternatively, a simple user-side workaround flag (e.g. --force_video_framerate_timing) would already solve the problem for everyone who pre-processes their GPX.This issue affects a growing number of Osmo 360 users and currently makes the camera almost unusable for high-quality Mapillary uploads without heavy manual post-processing.Thanks for considering!
I had something similar on my mind for what the root cause may be. Try recording at 25 fps because at this recording speed the frame time is a finite fraction of a second, not an infinite fraction. Perhaps this may help?
Thank you for the very valuable tip; 25 frames per second solve this problem.
Here’s my first successful Mapillary release of a DJI Osmo 360 recording, including a manually added tunnel passage.
In the tunnel, I manually drew a node spacing of 30 meters and then interpolated the missing times using my previously published Excel macro. As you can see, a lower GPX density in the tunnel results in a higher frame rate. This means the next step will be to reduce the node density of the DJI remote until the resolution desired by Mapillary—approximately one 360-degree image per 5 meters of travel distance—is achieved.
1 Like
I’m a bit confused at the moment. My attempt to render images at 25 frames per second solved the problem of the DJI OSMO 360 GPX track running away from me. However, a previously uploaded recording at “24 frames per second” is now also working. In this recording, I reduced the GPX track (OSV2GPX) supplied by the DJI Camera Remote by a factor of 20. Mapillary then upscaled the number of 360-degree images to 2115. Now, the images are no longer running away. Either I accidentally exported this sequence at 25 frames per second, or Mapillary has now resolved this issue in the background.
A new problem on the horizon for the productive use of the DJI Remote:
During my testing of the DJI Osmo 360 with the DJI GPS Remote (for the 360° setup), a new issue has appeared. Having been spoiled by the excellent reception of the Insta360 GPS Remote, I mounted the DJI remote in the same place inside the car – on the left side of the steering wheel, above the driver-side air vent.On mountain drives this mounting position now causes a clear problem: as soon as the GPS signal gets weaker, the GPX track suddenly jumps up to 20 meters off the actual road. Even after driving further and regaining better reception, the track often doesn’t recover for many kilometers and stays offset. I have never seen this behavior with the Insta360 remote. As soon as it picks up the signal again, it very quickly snaps back to the correct road with almost no deviation.Has anyone else noticed similar GPS tracking issues with the DJI remote when it’s placed inside the car (especially in the A-pillar/dashboard area)?
To determine the performance of the DJI GPX Remote with regard to its GPS reception, I will conduct tests and install the GPX Remote on the roof of my vehicle. The DJI Mimo smartphone app will then be responsible for controlling the camera.
Does anyone have experience with 3D-printed housings for GPX receivers on the vehicle roof? Such a dome would certainly look very professional and also provide optimal GPS reception.
Thanks!
@osmplus_org - we did not do any backend changes - so I think setting the camera to record 25 FPS did the trick.
2 Likes