Updates:

• 2025-09-03 – Added details on how I got the python tool running on macOS.

Recently I posted a list of Google Street View upload errors I have received. I found a way to deal with one of them.

GPS data jumps around a lot

After some “research” (which you can assume means “googling” and “asking A.I.”) I learned that there can be gaps in GPS data that make the movement appear to spike. I found a Mac Store program called GPX Editor which I purchased for the wonderful price of $4.99 so I could look at the data closer:

This program allowed me to look at my data in a much finer (i.e. zoomed in) way than Google Maps does. I could see spikes in the data that looked as if I suddenly popped to another location, as if I went from walking to zooming at 17 mph. This may have been caused by a GPS glitch as I walked under a bridge or some other obstacle that affected the GPS reading.

While you are looking at that screen shot, notice on the right side you can see how much time there is between GPS entries. Google Street View wants 5 seconds or less, I believe, so when gaps appear at 8 seconds, that will also cause an error and the GPX file will be rejected.

What to do, what to do…

Google wants real GPS data, but it seems fixing an obvious glitch like this should be acceptable. Basically, just moving a point back to where it was. I am sure there are tools like GPX Editor that would allow moving one point and fixing it.

But I am lazy, and wondered if there was an easier way.

I ended up looking for a tool to interpolate the GPS data. Here is the one I found:

https://github.com/remisalmon/gpx-interpolate

It will read a GPX file and then smooth out the points. Here is the example screen shot from that Github repository:

The black dots are actually GPS entries, and the red is where it can create new entries. For slow data, such as walking, this should work really well. And, I notice it has the ability to limit how often the data ends up in the file:

usage: gpx_interpolate.py [-h] [-r RES] [-n NUM] [-s] FILE [FILE ...]

interpolate GPX files using piecewise cubic Hermite splines

positional arguments:
  FILE               GPX file

optional arguments:
  -h, --help         show this help message and exit
  -r RES, --res RES  interpolation resolution in meters (default: 1)
  -n NUM, --num NUM  force point count in output (default: disabled)
  -s, --speed        save interpolated speed

Running gpx_interpolate on macOS

Side note: To get this running, I had to install a few other things. In order to install them, I had to use some a “virtual environment” for Python so the stuff I installed was isolated from the Python that came with macOS (or so I think). Here were the commands I ran:

cd Movies ***OR WHEREVER YOU WANT TO INSTALL THIS***
python3 -m venv venv
source venv/bin/activate
pip install gpxpy
pip3 install numpy
pip3 install scipy

After that, I could “python3 gpx_interpolate.py -r 1 my_gpx_file.gpx” and get the interpolated file.

The instructions I used (from Google’s A.I.) said I would need to “source venv/bin/activate” each time I started a Terminal and wanted to use this. I will update this as I learn more and understand what this is all about.

The results…

Perhaps I could use the “-r” option so it drops a marker every 1 meter or so. As long as I was walking at a regular pace, that should make new data that is much smoother without the jumps and gaps.

This file now seems to have much more consistent entries, and still follows the walking path closely.

I was able to upload the video file and this new interpolated GPX file and it is now live on Google.

But I am sure we can do better. To be continued…

Updates:

• 2025-08-03 – added new error “GPS timestamps do not overlap with Video timestamps.”
• 2025-09-03 – added “GPS data contains gaps greater than 5 seconds in between GPS points.”
• 2025-06-15 – added “Inaccurate GPS.”

---

This is another research article which I am posting so others may find it in the search engines.

Uploading to Google Street View involves uploading a video file with embedded GPS, or a non-GPS enabled video file and a separate .gpx file containing the GPS data.

Here are some of the errors I have been getting:

GPS data contains gaps greater than 5 seconds in between GPS points. 32 sec gap found after 0 seconds

This was from two separate recording where the Insta360 GPS Remote did not embed GPS data. Instead, I used a .KML file generated by an iPhone app (Geotag Photos 2) I was using for my digital camera photos. I tried to use the KML file as a backup, but apparently there are data problems in it that Google will not accept.

Video does not contain more than 10 GPS points. Only 0 GPS points found

This one is problematic because the GPX file contains hundreds of GPS points. I had converted my video file down to 1 frame per second, per Google recommendations. One theory was that the points in the GPX file did not line up enough times with a specific frame in the video, and thus the file gets rejected. Google Gemini says this should not matter, but a different file I uploaded at 1 fps did not have any issue, and resubmitting the same erroring file converted to 5 fps did not receive this error.

GPS time range (9/12/24, 8:35 AM to 9/12/24, 8:39 AM) does not overlap with Video time range (7/20/25, 6:49 PM to 7/20/25, 6:53 PM)

This was caused when I converted a video file to 1 fps using Apple Compressor. The resulting file had a different creation date, and thus did not match the GPX file. It looks like Apple Compressor cannot be used by itself to get the requested 1 fps, 5fps or other frame rates to Street View.

GPS data jumps around a lot

This one puzzles me the most. If I convert the GPX file to a KML file for uploading to Google Maps…

https://gpx2kml.com

…that file displays on the map and looks quite accurate to the trail on the map:

GPS timestamps do not overlap with Video timestamps. GPS time range: (6:00:00 PM UTC-6 to 6:00:00 PM UTC-6). Video time range: (6:00:00 PM UTC-6 to 6:00:00 PM UTC-6).

This one happened after I used Apple Compressor to reduce the video file down to 5 fps. There are some settings I was told about on Reddit that should allow the metadata to pass through to the converted file. That helped get past an earlier error, but now this one shows up.

Inaccurate GPS

This one surprised me since I recorded using a dedicated hardware GPS logger (Columbus P-1 Mark II). This unit appears significantly more accurate than using my phone or a GPS remote. After over a week of processing, I simply was told “Inaccurate GPS.”

Can you help?

Please leave a comment with any solutions to these errors, and I will update this page.

Until then…