Currently, OpenAthena for Android only outputs height of the target as height above the WGS84 reference ellipsoid, A.K.A "hae".

Some applications, such as military use, prefer to use Geoidal height (such as mean sea level) that take the shape and rotation of the earth into consideration and using the expected sea level as the base.

OpenAthena for Android should be able to output height of the target in either format

Related issue:
#63

More info:
https://www.reddit.com/r/askscience/comments/13t44me/how_do_modern_navigation_aids_account_for/jltapm4/

https://enterprise-insights.dji.com/blog/geoid-vs-ellipsoid

For getting altitude information from the GeoTIFF DEM, it may be possible to just use the Apache Commons Imaging Library an existing Java Library. An advantage of this technique is the source code is all in java, which would require no use of the Android NDK for running bytecode

https://commons.apache.org/proper/commons-imaging/index.html

ref: https://monitor.f-droid.org/builds/log/com.openathena/30#site-footer

/LE: fyi https://gitlab.com/fdroid/fdroiddata/-/commit/ea626b3f16224a850504e0dd8b64a3f6f16d9e66

will get a diff asap

Some European countries use a comma "," instead of a period "." to distingush the whole number and decimal components of a float

In the current version of the app, if a European locale is used which adheres to this format, the Google Maps link provided will be malformed and unusable

This may also adversely effect the cursor on target message feature

The code which generates the Google Maps link must be forced to use the "." period decimal format

The current process for obtaining a DEM and drone image is burdensome to the user.

To make usage of the app much more simple, long press actions should be added to the ⛰, 🖼, and 🧮 buttons with the following features:

• ⛰: download a DEM raster from the SRTM GL1 a few Km wide and tall, centered on the user
• 🖼: take a picture from the paired drone and use its telemetry
• 🧮: do both of the above and calculate a target location

Depends on #22

For naval use out on the ocean, no digital elevation model should be necessary. It's okay to just use the Mean Sea Level for the local area, like so:

googlemaps/android-maps-utils#704

This will require updating app/src/main/java/com/openathena/AthenaActivity.java with a boolean selector for terrain or sea mode (and an associated radio button in the associated layout.xml file), and new logic in app/src/main/java/com/openathena/MainActivity.java and app/src/main/java/com/openathena/TargetGetter.java to use correctly use Mean Sea Level instead of terrain elevation if the sea mode is selected

How can one obtain real-time video streaming along with real-time flight parameter data? Is it feasible to calculate the position of arbitrary pixels based on the video stream, with an acceptable margin of error?

Context

For OpenAthena to calculate a target, it needs to be loaded with a Digital Elevation Model (DEM) which stores terrain elevation for a certain area of Earth. These DEM's can vary in size, from extremely small to extremely large.

Currently, if a user selects a DEM to load, it can take 10 seconds or more to complete this operation with a large file. Because the DEM loading task is not given its own thread, this blocks the main application UI for an unacceptable amount of time (and will even cause an "application not responding" termination prompt for the user from the Android OS)

Steps to reproduce:

Open the app. Click the "⛰" button and choose a large DEM. Observe how the app blocks for a long period of time

Desired state:

As a user, I want a DEM to be loaded as a background process so that I can use the app with confidence without fear of an apparent application crash

This is a good place to start:
adobe/XMP-Toolkit-SDK#5

XMP Java core 6.1.11 is available here, but without source code:
https://search.maven.org/artifact/com.adobe.xmp/xmpcore/6.1.11/bundle

The license restrictions are also unclear

Might end up using this fork instead, which has less ambiguous licensing terms:
https://github.com/veraPDF/veraPDF-xmp

Added in 5ff492b. Rather than just using the nearest elevation value without interpolation, now the engine uses the four nearest samples for weighting. The interpolation is done according to a function called Inverse Distance Weighting, where the effect (weight) of each sample is inversely correlated to its distance to the interpolated point:

More info:
https://doi.org/10.3846/gac.2023.16591
https://pro.arcgis.com/en/pro-app/latest/help/analysis/geostatistical-analyst/how-inverse-distance-weighted-interpolation-works.htm

Description:

In OpenAthena for Android, GeoTIFF digital elevation model loading is performed by a new thread upon initiation of the task.

The app (by design) does not preclude the user from initiating a new load operation even when one is ongoing.

The issue is that these loading threads are not synchronized with each other properly. This may cause a different GeoTIFF to be loaded than the user expects!

Steps to reproduce:

Load a large GeoTIFF file. While the load operation is ongoing, change your mind and select a small GeoTIFF file. The small file will load before the large one, but then the large one will load after (even though the task was initiated first).

When the user goes to select an image and then calculate, the loaded file will be the large one even though they expected it to be the small one.

Possible solution:

Use a synchronized stack across the loading and man UI thread. Pop from the stack only the last inputted GeoTIFF

When Android reports the rendered size of an ImageView, it may be incorrect if a constraint layout is forcing an image to be squished by constraints. This causes a dis-coupling between the actual marker and its reported x and y, which degrades accuracy.

This will need to be fixed before v0.15 release

Description

It appears that huge drone images of a large resolution still crash the app, despite this safety check in this code of MainActivity.java

An appropriate fix will need to copy the image to the app cache directory, make a scaled down copy, and load the scaled scaled down copy for display and use with the app. This would allow even huge drone images to be safely used with the app.

User story

As a user, I want to load huge drone images, so that I can use my huge drone images with the app

Apparently, the text encoding is not unicode-compliant like I thought. If there are special characters outside of normal ASCII within the CoT message, ATAK will fail to parse it

One character change to this line:

The coordinate system used by most people in the world for latitude, longitude locations is the WGS84 standard. However: multiple alternatives exist and are considered standard in certain professions and countries

OpenAthena Android should output a WGS84 lat/lon pair by default, and have the following alternative modes selectable for output:

• WGS84 Geodetic (° " ')
• NATO MGRS
• SK-42 (CK-42) (истема координат 1942 года)
• SK-42 (CK-42) (истема координат 1942 года) (° " ')
• SK-42 (CK-42) Gauss-Krüger gridref

Currently, OpenAthena only performs a raycast from the exact center of the image. It would be nice if the user could click an arbitrary point on the image to determine its location.

This may be possible with a camera intrinsic matrix:
https://towardsdatascience.com/what-are-intrinsic-and-extrinsic-camera-parameters-in-computer-vision-7071b72fb8ec
https://towardsdatascience.com/camera-intrinsic-matrix-with-example-in-python-d79bf2478c12
https://stackoverflow.com/questions/47896876/camera-intrinsic-matrix-for-dji-phantom-4
https://doc.arcgis.com/en/drone2map/latest/help/edit-camera.htm

However, a unique set of values of the intrinsic matrix will be needed for every possible model drone. Factors such as digital crop and/or zoom may have a metadata-dependent mitigation or may be un-rectifiable.

Theta has created a new repo DroneModels where we will keep track of the intrinsic parameters (such as sensor physical width and height, pixels width and height, and distortion parameters) of many makes and models of drones.

The included droneModels.json is in a standardized JSON format which we will use for loading the same intrinsic parameters across the various OpenAthena products.

OpenAthenaAndroid must be able to load droneModels.json and extract the relevant values for the particular make and model of the drone image being analyzed

This issue is a prerequisite for #74

@rdkgit @sethgcanada

helpful links:
https://github.com/nutiteq/gdal/wiki/AndroidHowto
https://trac.osgeo.org/gdal/wiki/BuildingForAndroid

Currently, the user interface of this app is entirely in English.

Localized versions of information text must be provided for the user to allow the app to be used without confusion.

A way I've accomplished this in the past has been with the Transifex service, which integrates with GitHub and is free for use with open source projects:
https://github.com/mkrupczak3/Transifex-Android-Strings-Yaml

Description

A user reports that target location accuracy appears to decrease as range to the target increases (when a target is further away).

This could be related to a known issue with lens distortion (issue #74), a problem with images scaled down using post-processing without a corresponding update to EXIF metadata, or could be due to a bug in commit ecf3133 which added a correction for the Earth's curvature across long distances.

User Story:

As a user, I want the app to remain accurate across long distances, so that I can use target locations confidently

Our current calculation for ray angle from a selected image point is entirely based on the idealized pinhole camera model. This makes no consideration of the properties of the actual camera lens, which introduces its own image distortion subtly different than may be expected in the pinhole camera model. These distortions may be especially pronounced with fisheye cameras or zoom lenses at larger focal lengths:
https://en.wikipedia.org/wiki/Distortion_(optics)

This deviation due to distortion is noticeably more pronounced near the edges of images, causing the marked point to deviate from the desired calculated location.

A different project called PIX4D, which is used for drone mapping and photogrammetry, has published how they account for lens distortion. Proper angle calculation is very important for photogrammetry's technique of stitching together images taken from different angles, so we may assume their model is reasonably accurate:

https://support.pix4d.com/hc/en-us/articles/202559089-How-are-the-Internal-and-External-Camera-Parameters-defined

We need to store R₁, R₂, R₃, T₁, and T₂ for common camera models, and use the equations as defined above to apply a correction for lens distortion which then allows us to use the pinhole camera model appropriately for ray angle calculation

Hi,

Thanks a lot for OpenAthena for Android !

I cannot work with Open Athena for Android and my mavic mini 1.

I do not understand : It seems that my Mavic mini 1 seems to do not have geolocalization data in exif under irfanview.
But when i look at the pic in my android phone... it show me some geolocalization data in google map !

Please could you help me, i do not understand.

The code only references the roll value of the camera. If the roll value of the aircraft is not 0, will there be any issues with the result?

Some model drones, such as the DJI Mini 2, fail to provide correct metadata in the standard format of their make

Open Athena must be able to recognize when incompatible metadata is present and provide a specific error message to the user.

Military software usually uses DTED format DEM's, not GeoTIFF

https://www.nga.mil/news/With_50-year_legacy_Digital_Terrain_Elevation_Data.html

This library is a good candidate for inclusion in OpenAthena:

https://github.com/mkrupczak3/DTED-File-Parser-in-Java

full_description.txt and short_description.txt for zh-CN are empty (0 byte) files which causes some issues: the "empty" description might overwrite the fallback en-US one causing the app to show up without any description for that locale – or as in my case, it throws an "failed download: empty file" error on each update.

So could you please either fill those files with content, or remove them entirely? Thanks in advance!

Oh, and btw: you might wish to pick a badge to accompany the lonely PlayStore one, linking it to https://apt.izzysoft.de/packages/com.openathena/ 😉

Currently, the cross-hair is a high visibility pink dot, and while it's visible it does cover over the selected target in the image

Should be simple to change the mark-able image view to have a cross-hair with 4 thin rectangles aranged radially from the center

Context:

If a user begins operation of the app by loading a DEM then rotates their phone/tablet, the DEM is discarded upon the change in orientation. The same applies for the current selected image or calculation output.

Steps to reproduce:

A: Select and load a DEM. Upon success, change screen orientation. Loaded DEM has been discarded and subsequent image load and calculation will fail until the DEM is re-loaded
B: Select and load a DEM, an Image, and perform a calculation. Upon success, change screen orientation. Both TextViews displaying target calculation output are reverted, the selected image is unloaded from the ImageView and the loaded DEM is discarded

Desired state:

As a user, I want to maintain application state across screen orientation state so that I can perform seamless operation of the app without interruption

Description

Currently, the app allows tap to locate target selection in both the MainActivity and a dedicated fullscreen SelectionActivity which appears larger on the screen.

In this fullscreen SelectionActivity, A user should be able to pinch to zoom (two touch gesture) and tap and drag (one touch gesture) to translate the zoomed window. Users expect this functionality from mobile apps, and it would make it easier to identify and select targets accurately.

User story

As a user, I want to pinch and zoom in the target selection activity, so that I can identify and select targets more accurately

For easier comprehension and communication, the output values of the CK-42 Gauss-Krüger should be broken up into 2 (or 3) most-significant digits, a dash, and 5 least-significant digits. This format would be in parity with something like Kropyva or FireFly

e.g.:

import java.lang.Math;

public class EulerAngleCorrection {
    public static void main(String[] args) {
        double theta = Math.toRadians(45); // Convert to radians if given in degrees
        double phi = Math.toRadians(30); // Convert to radians if given in degrees
        double r = Math.toRadians(15); // Convert to radians if given in degrees

        double[] correctedAngles = correctEulerAngles(theta, phi, r);
        System.out.println("Corrected Euler angles (θ', φ'): (" + Math.toDegrees(correctedAngles[0]) + ", " + Math.toDegrees(correctedAngles[1]) + ")");
    }

    public static double[] correctEulerAngles(double theta, double phi, double r) {
        // Convert Euler angles to unit vector
        double x = Math.sin(theta) * Math.cos(phi);
        double y = Math.sin(theta) * Math.sin(phi);
        double z = Math.cos(theta);

        // Create rotation matrix for roll angle r in the xz plane
        double[][] rotationMatrix = {
                {Math.cos(r), 0, Math.sin(r)},
                {0, 1, 0},
                {-Math.sin(r), 0, Math.cos(r)}
        };

        // Rotate the unit vector
        double[] rotatedVector = {
                rotationMatrix[0][0] * x + rotationMatrix[0][1] * y + rotationMatrix[0][2] * z,
                rotationMatrix[1][0] * x + rotationMatrix[1][1] * y + rotationMatrix[1][2] * z,
                rotationMatrix[2][0] * x + rotationMatrix[2][1] * y + rotationMatrix[2][2] * z
        };

        // Convert rotated unit vector back to corrected Euler angles
        double correctedTheta = Math.acos(rotatedVector[2]);
        double correctedPhi = Math.atan2(rotatedVector[1], rotatedVector[0]);

        return new double[]{correctedTheta, correctedPhi};
    }
}

Currently, MainActivity.java has functions for much of the data parsing and extraction used in the app

Such data extraction and transformation methods should be moved to their own class to improve the quality and extensibility of the codebase

Description

Currently, the user must download a DEM for their Area of Operations. The process is somewhat confusing and is only possible to do on a computer with mouse and keyboard.

The program should be modified to have a new default online mode, where a DEM is automatically downloaded when a drone image is loaded.

User Story

As a user, I want the program to obtain DEM for me automatically, so that I can tap to locate without thinking about it.

Description

Currently, a user needs to select a Digital Elevation Model (DEM), then select a drone image every time the app is restarted. It would be easier for the user if the previously-selected DEM would automatically load the next time the application starts. There will also need to be a fail-safe to make sure there is no possibility that the app may crash-loop on an invalid DEM file.

Solution

app/src/main/java/com/openathena/MainActivity.java will need to be modified to use persistent information to keep a reference towards the DEM file in cache across app restarts.

User story

As a user, I want the app to persist my selected DEM across restarts, so that I can get my work done faster

The Android Team Awareness Kit (ATAK) is free and open source software which integrates a geographic information system for both military and civilian use.

For easier use of ATAK with targets calculated by OpenAthena, OpenAthena should send a Cursor on Target message upon the successful calculation of a target to 127.0.0.1:6969. This would allow for immediate use of the calculated target location in ATAK

A new SeekBar has been added to the PrefsActivity in 78af4a3 and f15639d which allows the user to manually correct for bad data from a poorly-calibrated drone compass:

Now, the relevant text Strings for this feature must be localized into all 8 supported languages, and documentation in the README must be updated to describe the use of the new feature.

Of upmost importance: making it clear to the user that this SeekBar is for manual sensor value correction only, and it is not intended for input of magnetic declination (which is already handled by drone's WMM)

Visibility of the currently loaded image can be poor on small screen devices due to the presence of other objects in the UI.

As a user, I want a streamlined, full-screen image view activity so I can more accurately accomplish the target selection process

This is Inverse Distance Weighting, as implemented in this project:

More info:
https://doi.org/10.3846/gac.2023.16591
https://pro.arcgis.com/en/pro-app/latest/help/analysis/geostatistical-analyst/how-inverse-distance-weighted-interpolation-works.htm

We need to do some more testing to find an optimal value of p, which controls how heavily nearer points are weighted compared to further ones. Values close to 1.0 are akin to simple averaging of all points, while values close to 2.0 are akin to just using the closest point.

Directly related to issue #70

Currently, the raycast iteration does not account for the curvature of the earth. Over very long distances, the iteration vector will curve [upwards] instead of remaining a straight vector parallel with the initial ray

To fix this, the ray direction must be rotated [downwards] after each iteration (very very small number)

If the Java double precision floating point is accurate enough for values close to 0, this may slightly improve target resolution accuracy

In the current version of the app, all three buttons (⛰, 🖼, 🧮) are visible and enabled, even though the calculate function depends on a DEM and Image being loaded first

This confuses the user, because they may not be aware of which button to use to load a DEM, which to load an Image, and what the calculate button does

In addition, the user may press the ⛰ button, select a DEM, hit 🖼, load an image, and then in some cases is able to hit 🧮 before the DEM has finished from the ⛰ button press.

To remedy this, the 🖼 button should be disabled until a DEM is loaded, and the 🧮 should be disabled until both a DEM and Image are loaded.

God I hate programming for android:

https://medium.com/microsoft-mobile-engineering/scoped-storage-in-android-10-android-11-28d58d989f3c
https://www.geeksforgeeks.org/scoped-storage-in-android/

Integrate the DJI-SDK to obtain live telemetry from a paired DJI drone. This will allow for target resolutions to be obtained instantly even during flight

Does this project necessarily rely on laser ranging

Currently, there exists an edge condition which incorrectly makes the calculate button available before the app is in a ready state.

If a user selects a large GeoTIFF file, then selects a drone image file while the GeoTIFF is still loading, the calculate button will incorrectly become available before it is ready.

The finite state machine of the app may be modified to remove this edge condition

In the current v0.15 preview, the selected point reset to the center upon change in screen orientation, or any other time onCreate() is called.

While the target location is recovered, the selected point is not recovered. This causes a temporary discrepancy between the visible point marker and the target location which is most unfortunate.

This will need to be fixed before the v0.15 release

Description:

Currently, the DroneModels JSON file is hard-coded into the app and is not user-configurable. While it has data for many drone models, it is conceivable that users may find their particular drone is unsupported. In addition, some users of proprietary drones may not be permitted by their workplace to share details of their drone with this project.

The program should let a user load their own custom JSON file so that they can configure and add support for their own particular drone model

User Story

As a User, I want to load a DroneModels JSON file, so that I can use my drone with the app

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