so things work perfect if I don’t need to adjust my vertical. Now that I do, I think my normal workflow is out the door, since my elevations don’t match others I reference nor my GCP’s.
So since the M3E is all recorded in WGS84 and ellipsoid height. So to fix that I read I have couple of options.
put in offset on my vertical. ( trying to find best way to get this)
Adjust my WGS84 data that my drone captured and adjust it then import the image etc.
So just trying to find out what others do that are using drone that captures in WGS84…Do you adjust your elevation and if so with what ?
Do you just adjust your offset in the advanced coordinate system settings ?
Do you do anything with you GCP’s ? I assume those are ok…
Just wondering what others do, since I know I cant be alone.
Hi Kevin,
Here is a handy tool to figure out what your offset should be. Go to this website: https://cdn.proj.org/
Once there, zoom into your project area and click on the map. In the screenshot below, I clicked on an area near Denver, CO. It will then list the offsets for the different geoids. The highlighted one below is for Geoid 18.
(I know its pretty late, but a tip to share as i expect this is a problem for many)
As you had mentioned, the images are tagged in WGS/El Height. For a time my local survey equip reseller was providing a downloadable software that would take a folder of images, and perform an adjustment from el height to NAVD88, copying and tagging a new set of photos. This worked well enough. Only downfall is i liked to retain my original coords so i would constantly carry two sets of images (orig, adjusted). This burns way to much storage, especially if you introduce a 3rd set with pre-processing on the images.
Since then, i have figured out how to export the image locations tags (.csv) from PIX4D, import them into Trimble Business Center in their native datum, and export back out in correct datum/orthometric height (.csv). Then i can just import that info at the start of processing and I’m good to go. You will need some type of GIS/Survey/Cad Software to do the adjustment, but once you figure out the routine i think it works pretty well and you don’t need to rely on a single adjustment, as images get an actual adjustment based on each unique position.
I think the largest misunderstanding in drone mapping is not knowing the datum/coordinate systems of your images, your control points and your output.
With that being said, your images datum/coordinate system can be summed up as this:
If you are receving corrections (RTK/PPK), then your images will be tagged in whatever datum/coordinate system the base sends them in. If your base sends corrections in NAD83(2011), then your images are now tagged in NAD83(2011).
If you are not receving corrections, then your datum/coordinate system is WGS 84. But when not receiving corrections the accuracy/precision of your coordinates will be large enough that it does not matter since the difference between NAD83(2011) and WGS84 is smaller than the error of your non-corrected GPS module on the drone.
A simple workflow for USA users that need NAD83(2011) and a orthometric elevation using Geoid 18 or 12. This is when you are receiving corrections (RTK/PPK) and the base is sending them in NAD83(2011) with ellipsoid elevations. I try to use RTK and also have Control Points used both as GCPs and Check Points. But sometimes, for various reasons I will just use RTK only with just Check Points and still am able to obtain low centimeter RMSE on the Check Points.
Images: Import in and then change the datum to NAD83(2011) geographic. Use the height above the GRS80 ellipsoid and keep the field at 0 to indicate ellipsoid elevations.
Control Points - I always collect my control points in NAD83(2011) with ellipsoid elevations. Import the control points file, and define them the same as above.
Ouput - Go to the Output Setting and then choose your desired output which is usually a NAD83(2011) State Plane Projection. Now to correct your elevation from an ellipsoid height to an orthometric height you must use a geoid shift. This is not the correct way to do this, but Pix4Dmapper does not use a geoid undulation grid. Find the center of your mapped area and get the coordinates. Place these coordinates into the NGS Geoid 18 computational tool. You will now recieve the undulation for those coordinates. In the Vertical part when selecting you coordinate system, Height Above the GRS 80 ellipsoid, place the undulation figure you just got from the NGS tool. Convert it to US Ft before doing so. You have now shifted your data to orthometric.
The problem with this is that even in small areas, the geoid undulation varies and is not constant. As the mapped area gets larger, I have seen the geoid undulation vary and get close to a centimeter in difference across the mapped area.
This workflow works well enough, but if Pix4Dmapper used a true undulation grid, it would be that much better.
These cookies are necessary for the website to function and cannot be switched off in our systems.
They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences,
logging in, or filling in forms. These cookies do not store any personally identifiable information.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site.
They help us to know which pages are the most and least popular and see how visitors move around the site.
All information these cookies collect is aggregated and therefore anonymous.
If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partner (Google).
They may be used by Google to build a profile of your interests and show you relevant adverts on other sites.
They do not directly store personal information but are based on uniquely identifying your browser and internet device.
If you do not allow these cookies, you will experience less targeted advertising.