Over the last months I’ve been troubleshooting an issue that appears in many consumer GNSS setups: the GPX track starts far off the road and only “finds” the correct position after some distance. I’ve seen this with different cameras and remotes, and recently learned that the same thing happens with GoPro Max 2 raw uploads.
The short explanation is this:
Most consumer GNSS devices use a Kalman filter. If the GNSS unit stays completely still for several minutes before recording starts, the filter goes into a kind of “static mode”. When the user finally begins moving, the filter needs time to re‑stabilize. During this period, the GPX track can drift sideways, sometimes tens of meters, before it locks back onto the road.
This effect is easy to trigger in car setups, because the GNSS unit often sits motionless on the roof while the driver prepares the vehicle. In contrast, bike recordings rarely show the problem, because the GNSS device is always in motion before the actual ride begins.
The practical takeaway:
If the GNSS unit moves a little before the recording starts, the track is usually perfect. If it stays completely static, drift at the beginning is very likely.
I’m sharing this because it explains several GPX issues that contributors and platforms have observed, and it might help others understand why some sequences start “in the fields” before correcting themselves.
Possibly worth a mention. Ublox GPS units have a “Dynamic Platform Model” where it alters the assumptions about acceleration, altitude, and movement. My default was I think “Portable” which was not so good for automotive as it assumes low speed, multi-directional movement. I changed mine to automotive, but I believe there is a high G drone/helicopter mode as well.
Might be worth seeing if whatever GPS source that is being used has some method to disable (software) the filtering entirely during init. I note that there are GPS unit toolkits for mobile phones for example, but I haven’t looked into them.
It is like with everything; it is a matter of correct implementation or using the right tool for a specific purpose. The Kalman filter can be used for either smoothing motion or clearing noise for a static position but not both at same time. GoPro firmware engineers have yet to do some homework on this. GoPros should distinguish between being in motion and at a stand still. Dedicated navigation devices and apps like OsmAnd have figured out and implemented this long time ago. Again, it is the GoPro way of doing things.
To work around this issue with GoPros
Turn off GPS before recording.
This clears the Kalman filter’s history of previous positions.
Your circumstances may differ, I’m in pancake-flat country with generally good view of horizon.
Preferred way (don’t need/ want photo-trail to start at front door) is to switch on units, but do not start recording, some five minutes’ before where plan to start capture;
turns out satellite positions have by then been updated & photo trail starts in the correct spot;
To have a visual check that in correct spot, start recording just before passing a clear landmark with good view of the horizon, e.g. on bridge crossing motorway/ canal/ railway tracks (although any intersection w/o many obstacles will suffice): if pic coincides with map and aerials, position was obviously sufficiently updated;
this is of course historical performance, learned over time that where I live five minutes is sufficient.
met als immer vriendelijke groet (Dutch for ‘with as always friendly greetings’)
By the way: waiting for GPS lock on a GoPro unit doesn’t always guarantee the unit really knows where on earth it is, running the unit for like five minutes w/o capture works around that limitation.
You are not doing anything wrong if your GPS traces match pretty closely the route you have taken. This thread is about a special case.
In simple words, this can happen because the Kalman filter improves positioning over time by looking at a certain amount of past/previous position samples. When the camera is static for an extended period of time and then starts moving, the Kalman filter is saturated with more or less static positions. But, when the camera starts moving, these past static position samples sort of weigh more than the first few fresh motion samples. Hence, you can get a banding like effect in the GPS trace for the first few positions in motion. You can work around this issue by either resetting the Kalman filter at your starting position (toggling GPS off→on) or continuously moving and thus let your starting position seamlessly flow into the GPS trace (apparently like @koninklijke does).
GPS signal loss or GPS lock on time do not (or should not if implemented correctly) affect the Kalman filter because no position samples are fed to the filter in these situations. Broken implementations sometimes falsely feed 0,0 (the null island) or the last sampled position over and over to the Kalman filter when the GPS signal is lost. So, when the GPS receiver locks on you can or rather should start moving to avoid potential trace banding.
Any suggestions for how to deal with this issue once it’s already happened? We’ve recorded all of our footage and just begun to notice an issue that might have been caused by this. Struggling to find a good system for editing the flawed GPX
However, you can use JOSM to edit GPX tracks. It may have a bit steep learning curve initially but it is a complete out‑of‑the‑box (no need for additional plug‑ins to edit GPX tracks) solution. Imho learning JOSM is absolutely worth the personal time investment if you are into OSM and mapping captures.
A practical approach for editing a GPX track in JOSM is to simplify it first, reducing the density to roughly one track point every 3 to 30 meters, depending on the travel speed. This makes it much easier to manually align the remaining points with the actual route and visible reference features.
Mapillary helps compensate for the reduced GPX density by interpolating additional positions during processing. As a result, the published sequence often contains significantly more image locations than the original GPX track points would suggest. Therefore, a well-aligned and simplified GPX track is usually more beneficial than a highly detailed but misaligned one.
For this flow, do you first use JOSM to edit your images/videos or whatever, then point mapillary_tools at the files? Or use process, then work on the output of that, and then upload the result?
For mapillary_tools you need a GPX file or image files with Exif metadata, which you can also modify with JOSM but Exif modification requires plug‑ins though.
You can also upload GPMF stream video files with mapillary_tools directly, though you cannot modify the GPMF stream in JOSM. For that, you have to take a detour via a GPX file.
Thanks — this is useful for the “already recorded” case people were asking about earlier.
I’ve mostly been trying to avoid the drift up front (short move before record, or GPS off→on at the start point), but once a sequence is already filmed, spike cleanup without inventing new track points is exactly what you want. Good to hear your workflow sticks to the original GPS samples and only drops bad ones when the remaining data still looks solid.
One thing I’m curious about: for the classic start-of-sequence sideways drift (not a single spike, but a short stretch that slowly comes back to the road), does the correction usually trim that segment cleanly, or do you still end up doing a light manual align afterward (e.g. in JOSM) before upload?
Either way, appreciate you sharing a practical option for video-mode uploads.
Again, it is the GoPro way of doing things. 
→ 
/
→ JOSM → GPX → 
