I’ve written Python code that takes individual drone images and using the telemetry data:
- Creates an Image Footprint
- Creates an individual Georectified image (GeoTIFF) without the need for stitching.
Would this capability be useful to anyone? ![]()
I’ve written Python code that takes individual drone images and using the telemetry data:
Would this capability be useful to anyone? ![]()
That’s a big “Roger That!”
Right now it works really well with my Mavic 2 Pro… Which is something as it’s not RTK and the Hasselblad L1D-20c is reportedly “not really designed for mapping”.
Inconsistencies in Drone metadata tags have been an issue (a large headache) when experimenting with posted datasets.
@spifftek70!
I think this could be very useful!
I’d be interested in testing with some of my data.
I am also thinking about using it to double check the coverage of planned photos for highly sloping terrain mapping.
I am not very good with python. Is it fairly straight forward to run on a folder’s contents?
Cheers,
Jeff
Actually, I spoke too soon. That one worked as the orientation was almost north as was the flight path. I have the footprints mostly figured out, but calculation the proper polygon/image orientation is currently alluding me. Does anyone wish to help and collaborate?
Very interested in collaborating. I wrote something similar that ran in PostGIS 11 years ago. Always wanted to port to python.
Added you
Perfect. Do you have a license you’re targeting for this?
Probably a Duel licensing type.
I usually won’t/don’t work on dual licensed projects.
I don’t expect you’ll magically become MongoDB or MySQL tomorrow, but dual licensed code also suffers from copyright assignment issues which make lightweight collaboration around a license difficult.
Are you open to doing a pure AGPL or GPL? Alternatively, a liberal license compatible with AGPL is fine.
Regardless, this this cool and much needed work.
I suppose so, yeah
Now you’re making me research…
AGPL
Perfect.
I always love seeing folks choose a license that makes Google sweat ![]()
So I didn’t realize how much my gimbal’s calibration was off. I had to recalibrate the compass, the gimbal, and the IMU. NOW the script is working better.
These things are not as important when stitching, but individual FOV and Polygon calculation… VERY important.
Yes indeed! Pre-feeding the pose graph even with reasonably incorrect data is usually better than truly random initialization. FOV calculations, not so resilient. ![]()
I believe I’ve got it figured out this time.
Tested on multiple datasets using photos from 3 different drone platforms and it works very good.
When you look at this sample output below, remember these were NOT RTK drones and the center point can often be up to 3 meters off. Also, Capture Mode was Capture at Equal Disc. Interval rather than Hover&Capture at Point
it won’t work on something that oblique… the trapezoid would be never-ending…