Ensure we use GDAL 3.11.1 in Python bindings after 24.04 upgrade#1958
Ensure we use GDAL 3.11.1 in Python bindings after 24.04 upgrade#1958spwoodcock merged 12 commits intomasterfrom
Conversation
* Changes to support building on Ubuntu 24.04 and windows-2022 Github runner.
* Update Python to 3.12
* Install dependencies in virtual environment
* Run python scripts from the virtual environment)
* Update dependencies
* Ubuntu dependencies in snap/snapcraft24.yaml
* Python dependencies in requirements.txt
* Windows dependencies built in OpenDroneMap/windows-deps repo
* Update CUDA
* 12.8.1 on Windows
* 13.0.0 on Ubuntu)
* Run tests as part of docker build
* Use exact commits to specify dependencies that are built from source, instead of branch names
* Use upstream versions of Libraries:
* PDAL
* PDAL-Python
* untwine
* ExifRead
* draco
* Build windows builds with -j2
* Use Micasense's latest version of dls.py
* Update failing unit tests to match current behavior
|
@smathermather @NathanMOlson sorry to ping you - if you get a chance to test on any other dataset please do 🙏 But everything seemed to function pretty nicely on my end, so hopefully this fixes the recent issues 🤞 Once merged, I will delete tag |
| ENV DEBIAN_FRONTEND=noninteractive \ | ||
| PYTHONPATH="$PYTHONPATH:/code/SuperBuild/install/lib/python3.12/dist-packages:/code/SuperBuild/install/bin/opensfm" \ | ||
| LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/code/SuperBuild/install/lib" | ||
| PYTHONPATH="/code/SuperBuild/install/lib/python3.12/dist-packages:/code/SuperBuild/install/bin/opensfm" \ |
There was a problem hiding this comment.
I removed the env var as its empty and redundant during the build
| https://github.com/OpenDroneMap/windows-deps/releases/download/2.6.0/rasterio-1.4.3-cp312-cp312-win_amd64.whl ; sys_platform == 'win32' | ||
| gdal[numpy]==3.8.4 ; sys_platform == 'linux' | ||
| gdal[numpy]==3.8.4 ; sys_platform == 'darwin' | ||
| gdal[numpy]==3.11.1 ; sys_platform == 'linux' |
There was a problem hiding this comment.
Ensure GDAL version matches on Mac / Linux / Windows
| elif [[ "$UBUNTU_VERSION" == *"24.04"* ]]; then | ||
| echo "Enabling ubuntugis-unstable PPA for Ubuntu 24.04" | ||
| sudo $APT_GET install -y -qq --no-install-recommends software-properties-common | ||
| sudo add-apt-repository -y ppa:ubuntugis/ubuntugis-unstable |
There was a problem hiding this comment.
The main thing here - we need to use the current unstable version of 3.11.1 for the underlying GDAL libs
|
Initial tests complete and successful, now just running oats defaults against it as it has some tests I wouldn't think to run. |
Oats testing complete. Will review and report back shortly. |
|
Did ortho generation for some of the test datasets fail? |
|
Looks like on split merge stages alone it's having a problem with dateutil:
|
|
|
|
Python dateutil is unmaintained and I dont think compatible with Python 3.12. Simple replacement in log.py using stdlib from datetime import datetime
start_time = datetime.fromisoformat(last_stage['startTime'].replace("Z", "+00:00")) |
|
Makes sense. Now the build isn't working for other reasons for me, but probably it's just Friday evening stuff. |
|
I can update on Monday morning - afk for the weekend 👍 What server specs do you use to run OATS, if I want to do some additional testing? I'm assuming it wouldn't run on my framework 32GB RAM, right? |
|
I found a minute to update - fixed the dateutil issue 👍 Will run tests again on Monday! |
|
Thanks Sam! Definitely stay away from that keyboard for the weekend. I'll be endeavoring to do the same after capturing these notes before I do. New error: If I look for repoze.lru through the codebase, I get: and Unsure the exact functionality of repoze.lru, but looking at the repo, the youngest commits are 8 years old, and the website linked at pypi looks unmaintained. If, for sake of testing we remove lru in opendm/log.py, we get a failure to import vmem, which is a bit strange: |
I haven't tested for minimum specs, but your framework should be more than enough. Biggest issue if you run all of the tests is time. I would like to refactor it such that it allows for a mode that doesn't allow more than 4 cores per test and runs as many jobs in parallel as possible. Parallel processing and remote / cloud processing is on the roadmap, so it would align with the project vision. Running everything sequentially on my 20-core, 14th gen desktop, it takes roughly 5.5 hours, and barely touches the 64GB RAM. |
|
I like debugging these sorts of things! I'm sure it can all be worked out on Monday =) Looks like the splitmerge workflow is the only issue now, with outdated Python dependencies. repose.lru is definitely obsolete. Its a variable caching mechanism that is built directly into python stdlib now, in the functools package.
|
|
Had 2 mins in an airport - made a quick update to remove these deprecated libs. Haven't tested though - there may be others - will continue and try to replace as much as possible with stdlib, modern libs, or perhaps just copied code if the library usage is really small (on Monday). I think we can strip out some deps, for example beautifulsoup4 |
|
|
Yeah, I was surprised to see that too. Nice compatibility library. Still needs import line removed for lru, but otherwise gets us on to the next step: git diff
diff --git a/opendm/log.py b/opendm/log.py
index 66891500..07469418 100644
--- a/opendm/log.py
+++ b/opendm/log.py
@@ -7,8 +7,6 @@ import shutil
import multiprocessing
from functools import lru_cache
-from repoze.lru import lru_cache
-
from opendm.arghelpers import double_quote, args_to_dict
from vmem import virtual_memoryStill having issues with vmem, and too late tonight to look further, so I will put this here and take a look tomorrow evening: I haven't checked yet to see if there's a problem with vmem caught in the build / install process, which seems likely. |
ea510da to
f249280
Compare
|
I had a hunch the issue above was because the Likely caused the the shebang on |
| @@ -1 +1 @@ | |||
| 3.5.6 | |||
There was a problem hiding this comment.
I updated this so that running ODM display the correct message:
[INFO] Initializing ODM 3.6.0 - Mon Nov 24 18:43:31 2025
| parser = SettingsParser(description='ODM is a command line toolkit to generate maps, point clouds, 3D models and DEMs from drone, balloon or kite images.', | ||
| usage='%s [options] <dataset name>' % usage_bin, | ||
| yaml_file=open(context.settings_path)) | ||
| parser = argparse.ArgumentParser( |
There was a problem hiding this comment.
appsettings is ancient and is basically a thin wrapper around argparse.ArgumentParser, with the ability to load YAML settings.
I replaced this with a simple YAML reader to maintain support for it.
| self.utc_time = (timezone.localize(utc_time) - epoch).total_seconds() * 1000.0 | ||
| # Ensure utc_time is timezone-aware | ||
| if utc_time.tzinfo is None: | ||
| utc_time = utc_time.replace(tzinfo=timezone.utc) |
There was a problem hiding this comment.
Uses stdlib instead of outdated pytz pkg
edit: Currently testing just changing line 168 in opendm/cutline to be issued as a MultiPolygon. |
smathermather
left a comment
There was a problem hiding this comment.
Change line 168 in opendm/cutline to be issued as a MultiPolygon and we should be good to go.
|
I just successfully ran the splitmerge brighton beach dataset 🎉 I'll give running But otherwise, seems pretty good to me! |
|
A bit confused that I had a failure on As long as everything for |
|
Full Brighton output: Looks like GeoTIFF alignment fails for 3.5.6, but passes for 3.6.0. |
|
I got about half way through, mostly looks good apart from the LAZ failure for brighton (in both 3.5.6 and 3.6.0). Had to stop as I was running out of memory on my small machine and needed to use the processor for something else! |
I saw this too, so good to get that fix validated. I'm rerunning all now. Should be done in 6 hours or so, at which point we'll approve and merge this if I see nothing, which I expect. |
|
This reminds me I need to fixup how I added mem/swap reporting and printing pretty linebreaks 😭 |
| usage='%s [options] <dataset name>' % usage_bin) | ||
|
|
||
| # Load defaults from settings.yaml | ||
| if context.settings_path and os.path.exists(context.settings_path): |
There was a problem hiding this comment.
Do we know any examples of people that use a settings.yaml instead if command line args?
Wondering if we need to keep this functionality
smathermather
left a comment
There was a problem hiding this comment.
We are good to go.
|
I was hoping these changes would be the end of it, but I neglected the portable / GPU builds! (and forgot that they are the actual prod images). They all fail: https://github.com/OpenDroneMap/ODM/actions Related to #1960 |

Follow on from #1956 and #1904
Closes #1953
Fix to ensure 24.04 upgrade is fully functional.
After building latest, I tested on the brighton beach dataset:
Output:
Also replaced some dependencies with Python stdlib implementation: