Certain DJI Mini 3 Pro test images produce "Bad Altitude or Terrain Data" error

[mkrupczak3]

The DJI Mini 3 Pro may be using a Real-time Kinematics (RTK) GPS, which typically expresses altitude as WGS84 height above ellipsoid rather than the default EGM96 above mean sea level.

There is some logic in the parser which is supposed to detect the use of an RTK device and avoid performing a conversion if the vertical datum is already ellipsoidal. It appears however this may not be working correctly for the Mini 3 Pro:
https://github.com/Theta-Limited/OpenAthenaAndroid/blob/44299f50cc59b99344802b516b0a94ef3bb2b696/app/src/main/java/com/openathena/MetadataExtractor.java#L290C8-L290C8

[mkrupczak3]

Example XMP string from a Mini 3 Pro using RTK:

<?xpacket begin="<feff>" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/">
 <rdf:RDF xmlns:rdf=["http://www.w3.org/1999/02/22-rdf-syntax-ns#"](http://www.w3.org/1999/02/22-rdf-syntax-ns#)>
  <rdf:Description rdf:about="DJI Meta Data"
    xmlns:tiff=["http://ns.adobe.com/tiff/1.0/"](http://ns.adobe.com/tiff/1.0/)
    xmlns:exif=["http://ns.adobe.com/exif/1.0/"](http://ns.adobe.com/exif/1.0/)
    xmlns:xmp=["http://ns.adobe.com/xap/1.0/"](http://ns.adobe.com/xap/1.0/)
    xmlns:xmpMM=["http://ns.adobe.com/xap/1.0/mm/"](http://ns.adobe.com/xap/1.0/mm/)
    xmlns:dc=["http://purl.org/dc/elements/1.1/"](http://purl.org/dc/elements/1.1/)
    xmlns:crs=["http://ns.adobe.com/camera-raw-settings/1.0/"](http://ns.adobe.com/camera-raw-settings/1.0/)
    xmlns:drone-dji=["http://www.dji.com/drone-dji/1.0/"](http://www.dji.com/drone-dji/1.0/)
    xmlns:GPano=["http://ns.google.com/photos/1.0/panorama/"](http://ns.google.com/photos/1.0/panorama/)
   xmp:ModifyDate="2023-04-05T14:12:47+00:00"
   xmp:CreateDate="2023-04-05T14:12:47+00:00"
   tiff:Make="DJI"
   tiff:Model="FC3582"
   dc:format="image/jpg"
   drone-dji:Version="1.5"
   drone-dji:ImageSource="DefaultCamera"
   drone-dji:GpsStatus="Invalid"
   drone-dji:AltitudeType="RtkAlt"
   drone-dji:GpsLatitude="REDACTED"
   drone-dji:GpsLongitude="REDACTED"
   drone-dji:AbsoluteAltitude="+344.490"
   drone-dji:RelativeAltitude="+121.600"
   drone-dji:GimbalRollDegree="+0.00"
   drone-dji:GimbalYawDegree="-87.70"
   drone-dji:GimbalPitchDegree="-22.00"
   drone-dji:FlightRollDegree="-16.10"
   drone-dji:FlightYawDegree="-104.10"
   drone-dji:FlightPitchDegree="-7.80"
   drone-dji:FlightXSpeed="0.6"
   drone-dji:FlightYSpeed="0.1"
   drone-dji:FlightZSpeed="0.0"
   drone-dji:CamReverse="0"
   drone-dji:GimbalReverse="0"
   drone-dji:SelfData=""
   drone-dji:SurveyingMode="0"
   drone-dji:UTCAtExposure=""
   drone-dji:ShutterType="Electronic"
   drone-dji:CameraSerialNumber="REDACTED"
   drone-dji:LensSerialNumber=""
   drone-dji:DroneModel="Mini 3 Pro"
   drone-dji:DroneSerialNumber="REDACTED"
   crs:Version="7.0"
   crs:HasSettings="False"
   crs:HasCrop="False"
   crs:AlreadyApplied="False">
  </rdf:Description>
 </rdf:RDF>
</x:xmpmeta>

[mkrupczak3]

Should be fixed in b79389b, but I will do some more testing to make sure

[mkrupczak3]

Calculation accuracy after the previous commit were no good at all. I think the drone-dji:AltitudeType="RtkAlt" tag just implies accuracy of the sensor, not vertical datum (even though presence of rtkflag indicated so on previous drone models per the metadata spec).

I reverted b79389b in 061a722. The issue with our test images are probably something else

[mkrupczak3]

Seems this issue is related to poor GPS fix before takeoff, causing the altitude reading to be incorrect for the remainder of flight session. Will do some more testing, but it would seem only possible mitigation is to leave drone on longer before takeoff so it can acquire better GPS fix.