Closed drewtu2 closed 2 months ago
For Anyone finding this issue, a temporary fix until this is patched, use this regex on your SRT file to replace the [rel_alt: xxx abs_alt: xxx] values with just a regular [altitude: xxx] value: "(rel_alt:.* abs_alt:)" replace with: "altitude:"
Is there a fix in the works ?
Thanks for reporting this / sharing a dataset. This should have been fixed with https://github.com/OpenDroneMap/ODM/commit/9fd3bf3eddbc856511eb931613b6157606c99f6c some time ago. Update, try again, if the issue persists feel free to re-open? :pray:
How did you install ODM? (Docker, installer, natively, ...)?
Docker running on MacOS
What is the problem?
Currently the video processing code makes the assumption that all srt files will contain exactly the latitude/longitude/altitude keys. https://github.com/OpenDroneMap/ODM/blob/master/opendm/video/srtparser.py#L56 Whenever there is an invalid altitude key, we end up erroring out in the underlying call to
self.ll_to_utm.TransformPoint(lat, lon,alt)
and all further dataset processing stops. In some versions of the srt files produced by newer dji drones, we have[rel_alt: xxx abs_alt: xxx]
fields as opposed to a fixedaltitude
key. See attached for an example.What should be the expected behavior? If this is a feature request, please describe in detail the changes you think should be made to the code, citing files and lines where changes should be made, if possible.
There are a few ways this should be addressed.
get_gps
in a try-catch to prevent erroring out causing a cascading failure which prevents other datasets from being processed.How can we reproduce this? What steps did you do to trigger the problem? If this is an issue with processing a dataset, YOU MUST include a copy of your dataset AND task output log, uploaded on Google Drive or Dropbox (otherwise we cannot reproduce this).
I've included a srt file attached here which contains the non
altitude
srt altitude keys. DJI_0664.SRT.zip I've also uploaded a video and corresponding srt to google drive.Otherwise, this should be easily reproducible from any SRT data that does not contain altitude information.
If I get the time I'll try submitting a fix for this myself since it's pretty small. Opening the issue for visibility and discussion if there's a different way this should be handled.