FOSS4G NA 2024

Harmonizing datums and tectonic epochs in drone data using PROJ
09-11, 10:30–11:00 (America/Chicago), Grand C

A case study about how DroneDeploy implemented "Datum Harmonization" with PROJ and GDAL to reconcile RTK, PPK, and survey data in varying datums and epochs. This required using the ITRF tectonic motion model in PROJ to achieve sub-centimeter accuracy.


DroneDeploy is a cloud-based reality capture platform that allows processing still images from drones into orthomosaics, elevation models, point clouds, and 3D meshes. When captured with standard GNSS, these outputs have absolute accuracy of a few meters, at best. Using high-accuracy methods such as surveyed ground control points (GCPs), Real-Time Kinematic (RTK), and Post-Processed Kinematic (PPK), a spatial accuracy of 1 centimeter can be achieved. But at this scale, the subtle differences between datums and the millimeter-per-year drifting of the tectonic plates will degrade accuracy if not properly handled.

In this talk, I will present a case study for how DroneDeploy leveraged PROJ's kinematic transformations to harmonize GCPs, RTK, and PPK data across different datums and epochs. This effort was termed "Datum Harmonization" since it involves reconciling disparate coordinate systems into cohesive whole. This was done without any special input from users, whose background in construction, mining, agriculture, and energy means they often lack esoteric understanding of surveying and geodesy. Among other things, I will discuss:
- Why we decided to transform all data to a standard datum and epoch: ITRF2014@2010.
- How we performed a kinematic transformation on RTK and PPK imagery, simulating continental drift backwards in time from image capture date to the standard ITRF2014 datum and 2010 epoch.
- Why we retained the exact PROJ transformation pipeline to ensure long-term consistency through PROJ updates.
- How we inserted the source epoch inside the PROJ pipeline so that it does not need to be provided in calls to gdalwarp or PyProj transformers.
- How we handled representing Web Mercator rasters when the only EPSG code for Web Mercator is in the WGS84 datum, not ITRF2014.

All slides and materials from this talk will be uploaded to https://github.com/dmahr1/talks/tree/main/2024_FOSS4GNA