Utilizing the trail Pix4Dcloud advanced to determine if this platform is ideal for digital construction site management. The following details are present:
- UAS : eBee X (RTK)
- GCP : AeroPoints
- Required Output: NAD83 (2011) / Illinois West (ftUS) + NAVD88 Height
After uploading the sample project with the images (RTK corrected) to Pix4Dcloud advanced with the output CRS mentioned above, the following questions exist:
Pix4Dcloud advanced does not allow the option to select NAVD88 height as an output for vertical height (this is odd as this is the standard surveying requirement within the U.S). That being the case, the only way to properly scale the model to this height is to add the GCP data with the accompanying CRS data, which in turn allows the proper output on Pix4Dcloud advanced. That being said, the Aeropoint data is to be used as checkpoints to validate RTK data, not scale the model (utilizing the Aeropoint data as GCP’s to scale the model essentially renders the RTK data useless as the model is scaled only to the GCP inputs). What would be the proper workflow utilizing an RTK UAS, Aeropoints as checkpoints, and requiring local state plane + NAVD88 height?
The sample dataset that was uploaded designating NAD83 / Illinois West (ftUS) EPSG 3436.
The corresponding model that was produced displays coordinates in miles (this is odd as the CRS is in ftUS). If you convert from miles to ft (an added process in which customers will not prefer) the offset is nearly 6-14 ft. Why does this phenomenon exist?
GCP 1: NAD83 (2011) / IL West (ftUS) + NAVD88 Height
Easting: 2593963.614 ft (US)
Northing: 2032055.982 ft (US)
Appreciate your help on the questions listed above. Please advise if the workflow utilizing an RTK UAS + Checkpoints + requiring local state plane & NAVD88 height is not optimized for this platform.