geoid.exe --text-file mode echoes the datum reported in geoid metadata (whether correct or not) (v 1.2.6, 06 SEPT)

[jhaasdyk-au]

ISSUE TYPE: Error in output (Failure to catch error on input data)
URGENCY: Moderate / High

Description
** geoid.exe** run with --text-file (text file mode) reports back the metadata in supplied geoid file.
If that metadata is incorrect, then the geoid.exe output reporting is incorrect.
It is known (and reported to GA in late August 2022) that the some GSB files are reporting incorrect metadata:

• CURRENT AUSGeoid2020 gsb reports “SYSTEM_F": "GDA94", "SYSTEM_T": "AHD_1971" (Should be GDA2020, AHD_1971)
• OLDER AGQG gsb reports: “SYSTEM_F": "GDA94", "SYSTEM_T": "AHD_1971" (Should be GDA2020 and AVWS)

Steps to reproduce
INPUT(S):

• skye_lat_long_formatted.txt
• AUSGeoid09_V1.01.gsb (from GeoscienceAustralia ‘agrstoolsandmodels’)
• AUSGeoid2020_20180201.gsb (from GeoscienceAustralia ‘agrstoolsandmodels’)
• AGQG_20201120.gsb (from GeoscienceAustralia ‘agrstoolsandmodels’)

COMMANDS (command line):

• geoid -g AUSGeoid09_V1.01.gsb -t skye_lat_long_formatted.txt --direction 0
• geoid -g AUSGeoid09_V1.01.gsb -t skye_lat_long_formatted.txt --direction 1
• geoid -g AUSGeoid2020_20180201.gsb -t skye_lat_long_formatted.txt --direction 0
• geoid -g AUSGeoid2020_20180201.gsb -t skye_lat_long_formatted.txt --direction 1
• geoid -g AGQG_20201120.gsb -t skye_lat_long_formatted.txt --direction 0
• geoid -g AGQG_20201120.gsb -t skye_lat_long_formatted.txt --direction 1

OUTPUT(S):

• skye_lat_long_formatted_out.txt [Rename each file as it is produced to avoid overwriting by next command]
• Review first two lines of the above output files.
• commands invoking AUSGeoid09 report derivation of GDA94 and AHD_1971 heights, in output files. (CORRECT)
• commands invoking AUSGEOID2020 report derivation of GDA94 and AHD_1971 heights, in output files. (INCORRECT) -
• commands invoking AGQG correctly report derivation of GDA2020 and AVWS heights, in output files. (CORRECT)
• We infer that geoid reads the metadata from the GSB file.
• Note: CURRENT AUSGeoid2002 gsb files, and older AGQG gsb files are known to incorrectly report "SYSTEM_F": "GDA94", "SYSTEM_T": "AHD_1971", (Reported to G.A. late AUG 2022)
• [Alas GitHub is currently returning an error when I try to attach a screen shot - Yes I know it SHOULD work ;-)]

Expected behaviour / Recommendation
RECOMMEND:

1. Make file output more generic; Do not specify the height datums, but only the user supplied geoid file (which then implicitly dictates the ’from' and 'to' height systems)
   => “Derived orthometric heights from ellipsoid heights using AUSGeoid2020_20180201.gsb, Version 1.0.0.0”
   => “Point Latitude Longitude Orth. Ht Ell. Ht N value D.Merid D.PrimeV”

2. ... Ideally: Read and apply interpolation datum(s) from the interpolation file metadata (as per current behaviour)
   HOWEVER, this method is not foolproof, as CURRENT AUSGeoid202 gsb files, and older AGQG gsb files incorrectly report "SYSTEM_F": "GDA94", "SYSTEM_T": "AHD_1971", (Reported to G.A. late AUG 2022)
   Therefore also report metadata source to help with trouble shooting.

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

[jhaasdyk-au]

The observation that ANY geoid can be applied regardless of the underlying default reference frame in the .BST file, indicates that there is NOT currently any compatibility checking (i.e. to compare the datum in the Project vs Geoid).
Demonstrated for geoid non-interactive mode at #193 (comment) (Item No.6)

This observation supports recommendation #1 above (remove datum references in text output from geoid.exe)
OR supports additional compatibility checking + warning(s). (i.e. an enhancement, not yet submitted at time of posting)

• Note: Known errors in the current AUSGeoid2020 model, datum metadata (as described at Issue #193, Item No.6 )

[rogerfraser]

Thanks @jhaasdyk-au. As I see it, this is a metadata issue with AUSGeoid, not a shortcoming in the way DynAdjust applies a geoid model. That said, while it is the user’s responsibility for selecting the right geoid model, I agree with your sentiment that DynAdjust could or should do some “compatibility checking” and present a warning if there is a perceived incompatibility based on the project EPSG and the geoid model’s EPSG. To achieve the desired behaviour, this may need some changes to the way metadata is printed to the geoid file. FYI @nich0lasbr0wn.

[JackMcCubbineGA]

@jhaasdyk-au The AusGeoid2020 meta data provided via the AGRS tools and models page was updated in September. The meta data on this new file is now correct.

[rogerfraser]

Thanks @JackMcCubbineGA