APPL RFC: Use IAU Sphere for HiRISE DTM Projects in Socet Set/GXP

This is a repost from the original Astrodiscuss site (by D.M. from June 25, 2020). Since the Mars aeroid continues to be a confusing issue, I find this description valuable and can help with our use of SOCET SET/GXP®.

Summary

The Astrogeology Planetary Photogrammetry Lab’s (APPL) SOP for creating HiRISE DTMs currently involves initializing a project in SOCET SET® using a three-dimensional coordinate system based on a biaxial ellipsoid for Mars, but establishes ground control using MOLA-derived heights relative to the geoid (e.g. MOLA Topography). This RFC proposes initializing SOCET SET® projects for HiRISE DTMs using a sphere, rather than a biaxial ellipsoid, and using a reference datset for ground control with heights relative to the geoid.

Motivation

SOCET SET® requires that users specify a coordinate reference system for stereo projects. APPL’s current SOP for creating HiRISE DTMs at low and mid-latitudes calls for using a geographic coordinate system based on the IAU-recommended biaxial ellipsoid for Mars. This coordinate system includes planetographic latitudes, and elevations defined as heights relative to ellipsoid.

Ground control of the DTM is achieved by estimating a rigid three-dimensional transformation from an initial HiRISE DTM and a reference dataset with elevations defined as heights relative to the geoid (e.g. MOLA Topography). This transform is applied to the latitude, longitude, and ellipsoidal height values of a set of tie points associated with the HiRISE stereopair. These updated ground coordinates are then re-imported to Socet Set and used as the basis of a final bundle adjustment. This results in a final HiRISE DTM with elevation values that are numerically-consistent with heights relative to the geoid, but the mixed use of heights relative to an ellipsoid and relative to the geoid is not theoretically rigorous.

In particular, the camera angles that are calculated in the final bundle adjustment based on the ground control points determined from MOLA Topography are not strictly correct. It is also possible that aligning an initial HiRISE DTM with ellipsoidal heights to MOLA Topography can introduce spurious rotations in the final HiRISE DTM if the stereopair covers an area of the planet where the height of the geoid changes much more rapidly than the ellipsoid. This effect is unlikely to be large because the MOLA-defined geoid for Mars has an effective resolution that is several orders of magnitude coarser than a HiRISE DTM, but could render a HiRISE DTM unsuitable for certain scientific investigations.

This RFC is therefore motivated by a desire to eliminate the possible negative effects caused by mixing ellipsoid and geoid heights in the HiRISE DTM SOP.

Proposed Changes

This RFC proposes 3 changes to the existing HiRISE DTM SOP:

1. Initialize projects in SOCET SET® using the IAU-recommended sphere for Mars (radius = 3396190 meters)
2. Use an elevation product for purposes of ground control with heights measured relative to a sphere, rather than the geoid
3. Use the dem_geoid program to convert pixel values in the final controlled HiRISE DTMs from heights relative to a sphere to heights relative to the geoid

Drawbacks

(none identified)

Alternatives

Continue using the existing SOP despite the shortcomings identified in the Motivation section above.

Future Possibilities

The proposed changes in this RFC have the potential to be extended to SOPs for creating DTMs from other Mars image datasets, such as CTX or HRSC.

dem_geoid is part of the Ames Stereo Pipeline (ASP). The ASP tool pc_align has been an integral part of the HiRISE DTM SOP since ~2013, so the use of dem_geoid doesn’t change the risk associated with relying on a third party application as part of the SOP because it comes from the same package as one that is already part of the workflow.

That being said, dem_geoid isn’t doing anything particularly fancy. It uses a stored raster of the MOLA-defined geoid and subtracts it as appropriate off of the values in an input raster. If dem_geoid ceased to be available, we could mimic this behavior using a copy of the geoid raster from the PDS and any conventional GIS tools that are capable of performing raster arithmetic.

The use of dem_geoid will either marginally increase the accuracy or have a negligible effect on the accuracy of the final DTM compared to the current method. The magnitude of the effect depends on the exact geographic location of the HiRISE stereopair.

This RFC is focused specifically on HiRISE, where the effects of mixing datums are usually negligible because of the small geographic areas covered by a single HiRISE DTM. However, this RFC has implications for creating SOPs for other datasets, such as HRSC, where the effects of mixing datums can lead to vertical errors on the order of kilometers.