Several issues found in SRT parsing and GPS altitude handling

ODM
1

Hello,

While working with video + SRT workflows in ODM (especially for RTK / ground-based video use cases), I identified several issues that can lead to loss of precision or incorrect metadata parsing. I’m sharing them briefly with suggested fixes.

Issue 1 – GPS altitude is rounded when written to EXIF

File: opendm/video/video2dataset.py

Altitude values are correctly parsed from the SRT file, but they are rounded to an integer when written to EXIF:

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(round(altitude))
# 192.048 -> 192

This causes loss of vertical accuracy, which is critical for RTK and precise ground surveys.

Suggested fix:

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(altitude)

or (to preserve millimeter precision with a stable denominator):

gps_ifd[piexif.GPSIFD.GPSAltitude] = float_to_rational(round(altitude * 1000) / 1000)

Issue 2 – Missing comma in shutter regex list

File: opendm/video/srtparser.py

Due to a missing comma, two regex patterns are unintentionally concatenated into a single string:

shutter = match_single([
    "shutter : \d+/(\d+\.?\d*)"
    "SS (\d+\.?\d*)"
], line)

Suggested fix:

shutter = match_single([
    "shutter : \d+/(\d+\.?\d*)",
    "SS (\d+\.?\d*)"
], line)

Issue 3 – Incorrect zero check when parsing latitude/longitude/altitude

File: opendm/video/srtparser.py

The following condition compares a string to an integer and therefore always evaluates to True:

lambda v: float(v) if v != 0 else None

Suggested fix:

fv = float(v)
return fv if fv != 0 else None

Issue 4 – RTK altitude regex only matches integers

File: opendm/video/srtparser.py

The current regex does not capture floating-point RTK altitude values:

("RTK ... (-?\d+)\)", ...)

Suggested fix:

(-?\d+\.?\d*)

These issues mainly affect GPS/Z accuracy and metadata consistency, particularly in high-precision RTK and ground-based video workflows.

I’d be happy to help with testing or preparing a PR if needed.
Thanks for the great work on ODM.

2

Hi there.. i’ve recently experienced what you say.. i’ve had to do a job in 2 separate times because of the rain (i use a mavic3E+RTK)..

  • The first run has been done with classic setup, taking photo delayed by time 0,X sec each
    For an area of around 28.000sqm and 200m points

  • The second run has been done with (always RTK on) video (video +SRT file ofc)
    Area of 54sqm :sob: and 47m points

Obviously i can’t overlap the two models and probably will need to redo the whole work :-/
(i use webODM 2.8.1)

3

@Kemal, I think you can open a pull request - information here: Pull requests · OpenDroneMap/ODM · GitHub

4

Yes, a pull request would be most appreciated. I created the relevant issues on repo:

5

I’ve submitted a pull request to address the SRT parsing and GPS altitude issues discussed here.
Thanks for the guidance!

6

Excellent! Thank you. Do you have a good test dataset I could use?

7

Disregard. I’ll test with this: https://github.com/pierotofy/drone_dataset_dji_video/archive/main.zip

8

Understood. In my workflow, the video and SRT files are generated using position data from an RTK GNSS receiver. After the update, I will also test it with my own dataset. I can share a sample dataset if needed.

9

An additional sample dataset would be great. It will be interesting to see the impact with that precision and accuracy of data.