Questions about captures for map data creation (signs and points)

Imagery, data, and integrations
1

I am really impressed at the ability of Mapillary to create signs and other point features. I have a bunch of questions and hope you all on the forum can help.

Is it normal for map data (signs and points) to be generated randomly and very slowly? I have some captures a couple of weeks old with no points produced (example). Then I have more recent captures with a patchwork of points.

I have also noticed that the GPS tracks from my X5 are wider than some others that have already published. It looks like they are stored with 10 points per second. When they come into Mapillary, though, they show up as 1 point per second. This is with 30 fps video. I wonder if this wider spacing is compromising creation of map data (signs and points)? In the photo below the blue line is my track, the black dots are the .gpx provided with the video upload, and the green line is someone else’s track.

image
image697Ă—552 44.8 KB

In the .gpx file from Insta360, there seems are no units of time less than a second. Does this mean it is a feature request to Insta360? Is there a way Mapillary could just guess at the times to enable more points to come in? Do other GPS loggers output files with more resolution? It just seems like a waste to capture at 30fps but end up with 1fps!

Here is what the .gpx looks like:

image
image1675Ă—751 41.5 KB

2

Yes, there is a delay between the images visibility on the GUI and when objects are detected. I don’t know what the average is, but I don’t expect my new captures to have them till some weeks after. There was also a forum thread in the last year about new object delays and omissions that might be worth a look.

The Mapillary processing interpolates position between GPS points to match the time the photo was taken, so it is more about the processing frame rate used. The CLI Mapillary tools for example allows frames to be dropped, in fact the desired is usually between and 2 and 5 FPS and has many adjustment parameters. It is often worth using the lowest frame rate the (video) camera will support as the resolution can be higher, less compression artefacts occur and a smaller video filesize ensues.

The image direction in most cases is also determined by the calculated track, rather than the GPS output. Also an adjustable parameter.

My Ublox GPS sender can be adjusted down to 1/10 sec per fix and the “type” modified for marine, mobile or minimal movement. I use 1/5 sec, but doubt that with the tools position/datetime interpolation it would be overly significant.

3

Thanks for sharing your experiences. Do I understand that you use an external GPS for your capture? Would you mind sharing what the timestamps look like?

I am wondering if the Insta360 .gpx is what is limiting it to having one photo per second. Going to test with Max later today to see how it compares. I mean why capture with video at all if the result is 1 photo per second?

By the way, here is a photo of a “patchy” map data area that is 2-3 weeks old. It seems like they fill in eventually? But more recent captures have filled in faster.

image
image844Ă—849 81.2 KB

4

Ah interesting. My first time using GoPro but I can see their .gpx files do store time values in increments less than one second - unlike Insta360 gps remote. It seems to it make it so Mapillary puts down more points. And I assume better/more placement of map data?

image
image1231Ă—381 11.8 KB

5

I actually have 3 cameras. One is a BlackVue dashcam with Mapillary firmware that produces mp4 videos with an encoded NMEA (1 sec) GPS stream in the file. The others are ex mobile phones running as dumb image capture devices to a nearby laptop. I don’t use their inbuilt GPS in the process as it slows the capture rate, instead I use a (1/5 sec) GPS unit connected to the laptop with a better sky view.

I dont know the full story of decimal time values existing in the various GPS output standards, although I believe that the first implementations did not do subseconds at all. I do remember having past problems with a GPX file with the mapillary_tools that were resolved by using NMEA.

My NMEA stream from the 1/5 sec unit simply has a suffixed decimal point and two decimal place;

$GPGGA,003710.80,2338.8820534,S,14717.3548999,E,1,13,0.70,344.48,M,44.449,M,72
$GPRMC,003710.80,A,2338.8820534,S,14717.3548999,E,0.3088,310.834,210625,8.4,E75

I also convert it to GPX (with gpsbabel) for other uses which looks similar;

  <trkpt lat="-23.648034597" lon="147.289249043">
    <ele>344.460</ele>
    <time>2025-06-21T00:37:10.600Z</time>
    <course>283.993011</course>
    <speed>0.045837</speed>
    <geoidheight>44.4</geoidheight>
    <fix>3d</fix>
    <sat>13</sat>
    <hdop>0.700000</hdop>
    <vdop>1.000000</vdop>
    <pdop>1.200000</pdop>

ie the importance here is that any conversion or indeed the base hardware has to be checked for subsecond handling. Most (earlier?) still digicams for example only have 1 sec increments saved into EXIF.

I dont know the Insta360 in any form of detail, but am aware it has both a photo and video mode. The photo mode has far more output pixels involved and a separate file write per image, so it may in fact take nearly a second to do all the processing. In that case there is no point even being concerned about the timestamp subseconds at all, but the position needs accuracy. I’d suggest that for Mapillary use the photo mode is far more useful as it allows zoomed detail viewing and better sign/object detect reliability. It would be best to ask other Insta360 users what they do though.

And as I previously stated the GPS/position is interpolated (by mapillary tools) in line with the actual image capture time, whether the input is a video or photo. On a track without sharp bends or violent speed changes then the accuracy is not going to be affected much, or at least will be well below the HDOP/VDOP accuracy limits.

Sorry, but I dont try to use object data (on the OSM GUI) anywhere close to my capture date/time, so am not across its limitations. Most of my OSM edits are done same day on my own locally processed stream.

1 Like