Multiple geoids (e.g. AG09 (in) + AG2020 (in) -> Ellipsoidal (adjust) -> AVWS (out) )

[jhaasdyk-au]

The purpose of this github discussion is to:

• publicise some personal investigations into handling of multiple geoids in a single DynAdjust project.
• record findings, feedback and questions to inform planned discussions with icsm-au/DynAdjust subject matter experts
  i.e. to inform additional user(self)-education, or potential enhancements or defects.

All findings and recommendations are my own and may not correctly represent current or planned DynAdjust behaviour.

---

Consider the following scenarios, each of which needs to apply multiple geoid models.

• AHD (in) -> Ellipsoidal (adjust) -> AVWS (out)
• AHD-derived-using-AUSGeoid09 (input) + AHD-derived-using-AUSGeoid2020 (input) -> (combined adjustment)...
• AVWS (old dataset, old-geoid) + AVWS (new dataset, new-geoid) -> (combined adjustment)

Does (or should) DynAdjust cater for these use cases? Implicitly or explicitly?

---

Yes, DynaNet supports this indirectly via a "multi-step" approach (similar to 3.3.1: Handling multiple different reference frames):

i) Group together all files requiring a particular geoid model;
Set the required reference frame with import,
Set the required geoid model (and --convert-stn-hts!) using geoid.
- if geoids DO share common from/to datums? use import, geoid(--convert), geoid(reset geoid), reftran(export only)
- if geoids DO NOT share common from/to datums? use import, geoid(--convert), geoid(reset geoid), reftran(transform & export)
ii) Execute reftran with the desired reference frame and (--export) the data.
iii) Repeat (1) and (2) as required.
iv) Re-import into a combined project, and don't forget geoid (--convert-stn-hts) again

DEMO / TESTING / FINDINGS
Dynadjust_import_adjust_multiple_geoids.txt: batch file containing testing, with short demo at the end shows:

1. import.exe can only be run once per project. Data must be pre-prepared as noted above.
2. geoid.exe does not have an export function (as per User Guide). Relies on reftran for that job.
3. geoid.exe can be called a multiple times to reset the geoid as needed (i.e. before export)
   • reporting will always use the latest geoid set.
   • --convert-stn-hts is NOT default behaviour, Discussed more at Issue #185 )
   • notably: only the last geoid set is reported in the dnaproj file. All other geoids are relegated to log files, or by default, forgotten.

and noting possible bugs / enhancements:

4. reftran will only export LLH records. [Consider an enhancement to support LLR (other?)]
5. reftran, when asked to transform between 3D datums in the absence of a previous call to geoid(--convert), will use LLH heights as if they are ellipsoid heights and report the output as ellipsoid height [This seems to be a bug to me, but more info MIGHT be available in log files or verbose records.]
6. Import returns a misleading error when importing files by name of 'skye_test.bst', or 'skye_test.msr'.
   "- Error: .\skye_test.bat does not exist". They DO exist, they are just not supported.

OUTSTANDING
7. At time of writing, I have NOT tested whether the same methods will cater for OrthoHeight (H) or ELlipsoid Height (R) MEASUREMENTS.
Does DynAdjust need an enhancement where these MSR types can be transformed / converted using geoids?

Operating system
Windows 10 Enterprise
DynAdjust v1.2.6
DynAdjust Users Guide.PDF (‘Sept 2022’) gather 06/SEPT/2022 from fork rogerfraser/DynAdjust

[jhaasdyk-au]

I must say, In retrospect the information / methods above seem perfectly obviously.
However, in practice, for someone re-exploring this program and documentation with fresh eyes, it took a bit of probing and testing to truly undertstand it.

I recommend a short section in the Users Guide discussing 'Handling multiple different geoid models.'
This is very similar, but distinct from the existing Section 3.3.1 subsection 'Handling multiple different reference frames'.
In my experience, careful thought must be given by the user to cater for the interaction between geoid(s). reference frame and default reference frame.

[rogerfraser]

Thanks @jhaasdyk-au. This is somewhat related to #6 and will be considered as part of work to resolve that feature request for the next release.