geoid sign seems to be wrongly applied

[Isaac H. E.]

Dear sir / madam,

I started a PS project where I imported 800 JPGs all with WGS84 coordinates and ellipsoidal eights in the EXIF

I have downloaded the EGM2008 1' geoid model (EPSG::1027) from http://download.agisoft.com/geoids/egm2008-1.tif then I placed the file within PS geoids folder and then I created a new "Coordinate System" as follows:
Projected Coordinate System: WGS 84 / UTM zone 31N (EPSG::32631)
Projection Method: Transverse Mercator
    Latitude of natural origin: 0
    Longitude of natural origin: 3
    Scale factor at natural origin: 0.9996
    False Easting: 500000
    False Northing: 0
Geographic Coordinate System: WGS 84 (EPSG::4326)
Geodetic Datum: World Geodetic System 1984 (EPSG::6326)
Ellipsoid: WGS 84 (EPSG::7030)
Prime Meridian: Greenwich (EPSG::8901)
Linear Units: metre (EPSG::9001)
Vertical Datum: EGM2008 geoid (EPSG::1027)

When I output a DEM from PS and I compare that PS DEM heights against a DEM published by the official local cartographic institution the heights of the PS DEM are wrong by 2 times the geoid undulation in other words it seems that the geoid is being applied in the wrong direction.

Thanks

Isaac

[Alexey Pasumansky]

Hello Isaac,

Can you please specify, how the conversion from WGS84 to compound coordinate system has been performed (you have processed in WGS84 and have chosen different output coordinate system)?

And also from which source the coordinates of the cameras were received - are you sure that the altitude values are above the ellipsoid, or they are above the take off points, for example?

[Isaac H. E.]

Hello Alexey,

Please accept my most sincere apologise for this forum post, I'm flying a DJI Mavic Pro and indeed it outputs what me may call "GPS altitude" but today I discovered that the height of the take off point I was using (in clear view of the sky with virtually no multipath) has "errors" of more ( ) than 100m between two flights separated 4 days, that is obviously unacceptable for photogrammetric processing.

Sumarizing I assumed that the EXIF reproted height was elliposidal when in fact, due to errors, it is impossible to tell if it is ellipsoidal, ortometric or some other reference level.

This case can be closed, many thanks for your help.

Isaac

[Yoann Courtois]

HI Isaac,

Have you then found a solution to manage those altitudes given by the UAV ?

Regards

[rossnixon]

I'm flying a DJI Mavic Pro and indeed it outputs what me may call "GPS altitude" but today I discovered that the height of the take off point I was using (in clear view of the sky with virtually no multipath) has "errors" of more ( ) than 100m between two flights separated 4 days, that is obviously unacceptable for photogrammetric processing.

I wonder if the bigger than expected altitude variation was caused by the recent CMEs and/or high level proton storm from the sun (but that was only in the past couple of days)?

[Isaac H. E.]

Hi Yoann,

No, unfortunately no, the only way I can imagine to "solve" the height variations would be to manually apply an offset to every EXIF height tag, this can be automated by taking a picture right at the beginning of the flight or right at the end with the drone landed, then search the correct ellipsoidal or ortometric height for that point and apply the difference to all the pictures, in fact there is a web site that does exactly that https://www.mapsmadeeasy.com/tag_fixer unfortunately they charge money for the processing... I'm not aware of any free solution.

Maybe would be a good addition to PS because if I'm not wrong 50% of the end user drone market is owned by DJI and all their drones suffer this same issue.

Isaac

[Isaac H. E.]

Hi rossnixon,

DJI drones mix the GPS altitude with their on board barometric altimeter to produce a smooth altitude output... there seems to be something wrong in the way they do it, this problem has nothing to do with ionospheric activity (CMEs, scintillation, ...) I have worked for 7 years in the GNSS industry and I can tell you that the largest height error you are going to see when operating in open sky, like I was doing, is 5 to 10 metres (in a small patch antenna). DJI seems to be using some sort of algorithm to track elevation changes because I have made 5 flights in totalover the same area, two of the flights were performed the 6th of Spetember and 3 of them the 10th. The altitudes of the flights performed the same day agree very well (high precision) between battery changes but the height of the flights performed during different days displays 124 metres of difference.

Isaac

[Yoann Courtois]

I guess there is another way to solve it.
Indeed the X and Y coordinates are actually right in WGS84, but Z coordinate sometimes drops.
Should be some parameters in our DJI drones to be set up.
We should be able to get correct 3D coordinates directly from the drone, and not by using another data.
I will go further in that point in a couple of weeks.

And for both of you, I have to say I already got that problem (more than 100m of Z-shift)...between two consecutive flights...
Actually, I handled a survey that needed 3 flights: First one gave correct Z-coordinates in WGS84 (+- 2m), and both second and third flights gave me a Z-shift of about 100m...

If what you say is true Isaac, it should be possible to set that the drone only use GPS altitude and don't smooth it with some barometric data.

Regards

[Isaac H. E.]

Hi Yoann,

You don´t really want to see the GNSS altitude in the EXIF metadata, the problem with the unfiltered GNSS altitude is that it is far more noisy than the altitude from the barometer, it is more accurate but less precise, ideally we should get a fix from DJI algorithms so that we can get 5-10 metres accuracy with high barometric precision (one good example of how this works in a real life product is handheld GNSS receivers from Garmin).

Isaac

[Yoann Courtois]

We shouldn't need barometric measurement.

Indeed GNSS natural positioning (Without RTK or post-processing) is around 5m accurate in XY and 10-15m in Z., which should be enough in a first estimation.