All of my images are in Lat Lon WGS 84. My coordinate system is NAD83(2011) / Texas South Central (ftUS) - EPSG:6588. I have set my vertical system to NAVD88 height (ftUS) - EPSG:6360 and the Geoid to Geoid18. After I process, I am still getting ellipsoid height. Since the survey was set up based on an OPUS survey, I know this is correct. Not sure of how Matic works, but in our survey equipment, if we set up a horizontal coordinate system with a geoid applied, orthometric heights are returned when measurements are taken. In Mapper, I would apply the geoid offset and orthometric height where returned.
I could not find any obvious reasons why you are getting the ellipsoidal height even after you specify that you project should be in orthometric heights.
You mentioned that your images in are in WGS 84 (EPSG:4326), but what about the vertical coordinate system? Are the images based on the ellipsoid or the geoid?
Would it be possible to share 3 images from the project and the quality report?
The images came from a DJI M300 with the P1 Camera. The data processed correctly in Pix other than some known problems with the camera orientation. I also tried the project in MSL with a geoid offset and still get a wrong answer on the elevation. I have sent a complete set of images to Ryan Sweeney (US Pix4D Rep) and here is a link to some images: https://we.tl/t-I7MOwgjFph
Hello Blaz,
The images are ellipsoidal height and come directly from the EXIF data from the P1 camera. The images will process correctly in Pix4DMapper, except for the problem of a camera model in Mapper. The issue is not the data. The issue the problem of the geoid offset or geoid model not being applied properly. I have processed another project in Matic with the same problem being evident.
I had a look and the vertical coordinate system is set to EGM96 when importing the DJI Zemnuse P1 images into Pix4Dmatic, and not ellipsoidal height.
In other words, Pix4Dmatic treats images as if they are in EGM96 and then transform them into Geoid18 that you selected in coordinate system dialog. Do you think this could explain the offset that you get?
I will talk about this with the product team in order to change the automatically detected vertical coordinate system for DJI Zemnuse P1 to ellipsoidal heights.
I have to take your word for this since I have no control over the camera coordinate system as in Mapper. Matic is much more of a “Black Box Solution” than Mapper, and I am not sure that I like that as a Land Surveyor.
Since this is the behavior for other DJI drones in the past, this could definitely be the problem. I did check the elevation of one of the cameras in Matic vs. the same in Mapper and there was a 4.62-foot difference. I then computed the EGM96 and the Geoid 18 values and subtracted and came up with a distance of 4.61 feet. This would indicate that the EGM 96 value is being erroneously applied. I have never understood why you would apply a geoid value to the image. This was the first thing I advised clients to change in Mapper.
We understand that and are working on exposing an option to select the coordinate system of the cameras, as well as viewing the external camera parameters (geolocation, orientation) and their accuracy. There should be more by this summer.
Note that it is already possible to import a .csv/.txt file for the image geolocations and orientations and to define the coordinate system that applies to these: https://support.pix4d.com/hc/en-us/articles/360056389172-Image-geolocation-and-orientation-import-format. Would you have a way of getting these values in a .csv or .txt file and import it? This could be a workaround until the coordinate system of the camera can be selected directly for data in the EXIF.
Thanks for the reply, but the only way I have to get that information is by exporting from Mapper. If I am going to load in Mapper, I might as well process in Mapper.
am going to create a camera calibration for use in mapper and will continue with this solution for the time being.
Experiencing the same issue. Geoid not being applied to the image metadata. Switched to DJI terra because of this. Works perfectly. Hope this gets resolved soon.
We are a surveying firm that conducts flights with a Mavic 3 Enterprise fitted with an RTK unit.
Many of our flights are conducted with the benefit of GCPs, and many of them not.
Sometimes our firm will fly sites just for reference or to verify features surveyed conventionally or provided from other sources. In this scenario we will elect not to set GCPs and it is our experience that the RTK flight results without GCPs hit conventional survey control for less than 0.15 feet horizontally and from 0.1 to .25 vertically. When processing with Terra the geoid is automatically applied to the image which is great. When processing with matic, no geoid is applied and the elevations are off approximately 100 feet (depending on the location). I would love to participate in the P4Dcloud features to share with clients but explaining that the elevations presented in the cloud are different than elevations on our survey is not acceptable. So ya, DJI terra for now.
I am seeing the same issue as this, I am using Mavic 3 Ent RTK gathered images but rather than setting the Z value to the set ‘ODN height’ it seems that the Z value being read and used in the Calibrate process is the WGS84 value, approx. 50m higher than the OSGN level.
It is unbelievable that this is even an issue and to say that it will be dealt with in Q4 is just baffling, this is a fundamental part of the job companies buy this product for. There must at least be a work around until the issue can be resolved (other than using a product that Pix4d are trying to migrate people off, i.e. Mapper)
@gdarigis You can get the correct elevations in Cloud, but you must use CGPs. I have not tried it with a single GCP. Not a desirable solution, but it will work if you need it on Cloud. I pretty much use Matic most of the time. I also use Terra, but not because of the geoid (Matic does this), but because of the localization option in Terra. Supposedly you can use Catch, but it is hard to explain to a contractor why they need to use another app to get a localization when they already have the information from their survey-grade equipment. Not a desirable solution.
@richard_sparks If you are using Matic, the geoid is working for me. I am in Texas and use geoid 18 without any problems. I haven’t tried it, but the geoid offset option also exists.
The biggest perk to flying with the benefit of an RTK system is not needing GCPs at all to coordinate or elevate the data on the native datum of the RTK network that is being utilized.
What is even the point of setting the geoid, or even a coordinate system when using GCPs that are coordinated on NAD83(2011) and NAVD 88 (18) and processed with a Geoid, as land surveyors do? Seems set up to mostly accommodate consumer level users flying with single gps solution rigs spitting out WGS coordinates and that’s cool too.
For RTK flyers the extra steps are not necessary. The geoid shift to the image metadata should be integrated into the software pre-processing. Reading the comments above, it appears that the p4d team has acknowledged the issue and is an improvement that will be implemented in a future release. There are a lot of rtk mavic 3e’s out there now and I’m surprised that p4d isn’t getting a lot more heat about this. Looking forward to an update. Thank you.
I’m not sure I understand what you are concerned about. All GPS equipment I have ever used stores positions in WGS84 ellipsoid height using the GRS80 reference ellipsoid. The data collector has built-in projections and ellipsoid that the WGS84 is converted into the grid coordinate system. In my career, I have used seven different geoids unique to the USA over the last forty-plus years. I fail to follow your logic on why you think P4D should automatically apply a geoid. Which one? How would they know? As far as GCPs, you only need them if you want to know your data is correct. I have not had any problem getting the correct elevations with the latest Matic release. Also, you must set the geoid in Terra if you want the correct elevations.
We are a surveying firm and own the Mavic 3 enterpise with RTK module.
Using a Custom Network NTRIP RTK on the drone should bring the data in at 93m in Pix4d matic after calibrations without the need for GCPs.
But this comes out almost 50m off. We are using the pix4d coordinate system of OSGB36 - ODN Height - geoid OSGM15 .
Did you sort this ?
Hi Ben77,
Full support for the Mavic 3 Enterprise came in version 4.8.3. Please make sure you have this or a later version installed on your computer. Otherwise, you will see this discrepancy.
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.
