Greetings -
First, I have no programming experience beyond a few basic scripts, including some in a scripting language for Windows called AutoHotkey. If I could find a user-oriented RTKLIB forum I would post there first. My apologies if this is a stoopid question.
RTKPOST offers to produce "Geodetic" elevations using a variety of geoid models, but so far my attempts to use GEOID18 as provided by the U.S. National Geodetic Survey (NGS) have been unsuccessful. I peeked into the source code at geoid.c and see that RTKLIB has a built-in geoid model in ASCII format, so have been concentrating on the ASCII version of GEOID18. In RTKPOST under Options > Files I enter the location of the GEOID18 file (both in ASCII and BIN versions) in the Geoid Data File field, but at one test point the geoid separation (difference between Ellipsoidal and Geodetic heights) is always -10.730 m while the GEOID18 separation is -11.951 m at that point. So apparently RTKPOST is always using its built-in geoid model.
I am assisting two retired PhD geologists on an unpaid project to determine the slope of the detachment plane of a huge low-angle landslide. They are using a multi-constellation tri-band GNSS receiver and, for simplicity, planning to use the OPUS online processing system provided by NGS. OPUS currently uses only GPS observations and delivers geodetic (orthometric in NGS parlance) elevations based on GEOID18.
As a backup for locations where obstructions prevent a successful GPS-only position from OPUS I am working up a method using a somewhat nearby GNSS receiver that is part of EarthScope's Network of the Americas. That receiver provides GPS, GLONASS, and Galileo data via RINEX files. It is hoped that the additional satellites may provide good results in obstructed locations.
All processing will be using RTKPOST (updated yesterday to RTKPOST-EX 2.5.1) in Static mode with standard RINEX OBS and NAV files. I set the base position manually along with all options.
So far it seems I have resolved the issue of the base receiver's published position being in IGS14 but GEOID18 is based on NAD83(2011). I get from RTKPOST fixed NAD83(2011) horizontal positions and ellipsoid heights that agree with those from OPUS on test data.
It would be nice to find a way to provide geodetic / orthometric elevations directly from RTKPOST without an extra step to subtract the GEOID18 separation.
I checked the Issues in both the original RTKLIB repository as well as this one and have not found any solutions. It seems this feature of the program is sort of neglected, likely because of more pressing concerns. It could use a bit of tuneup and more documentation.
Thanks for reading this far and for any guidance and/or assistance you may be willing to provide.
Greetings -
First, I have no programming experience beyond a few basic scripts, including some in a scripting language for Windows called AutoHotkey. If I could find a user-oriented RTKLIB forum I would post there first. My apologies if this is a stoopid question.
RTKPOST offers to produce "Geodetic" elevations using a variety of geoid models, but so far my attempts to use GEOID18 as provided by the U.S. National Geodetic Survey (NGS) have been unsuccessful. I peeked into the source code at geoid.c and see that RTKLIB has a built-in geoid model in ASCII format, so have been concentrating on the ASCII version of GEOID18. In RTKPOST under Options > Files I enter the location of the GEOID18 file (both in ASCII and BIN versions) in the Geoid Data File field, but at one test point the geoid separation (difference between Ellipsoidal and Geodetic heights) is always -10.730 m while the GEOID18 separation is -11.951 m at that point. So apparently RTKPOST is always using its built-in geoid model.
I am assisting two retired PhD geologists on an unpaid project to determine the slope of the detachment plane of a huge low-angle landslide. They are using a multi-constellation tri-band GNSS receiver and, for simplicity, planning to use the OPUS online processing system provided by NGS. OPUS currently uses only GPS observations and delivers geodetic (orthometric in NGS parlance) elevations based on GEOID18.
As a backup for locations where obstructions prevent a successful GPS-only position from OPUS I am working up a method using a somewhat nearby GNSS receiver that is part of EarthScope's Network of the Americas. That receiver provides GPS, GLONASS, and Galileo data via RINEX files. It is hoped that the additional satellites may provide good results in obstructed locations.
All processing will be using RTKPOST (updated yesterday to RTKPOST-EX 2.5.1) in Static mode with standard RINEX OBS and NAV files. I set the base position manually along with all options.
So far it seems I have resolved the issue of the base receiver's published position being in IGS14 but GEOID18 is based on NAD83(2011). I get from RTKPOST fixed NAD83(2011) horizontal positions and ellipsoid heights that agree with those from OPUS on test data.
It would be nice to find a way to provide geodetic / orthometric elevations directly from RTKPOST without an extra step to subtract the GEOID18 separation.
I checked the Issues in both the original RTKLIB repository as well as this one and have not found any solutions. It seems this feature of the program is sort of neglected, likely because of more pressing concerns. It could use a bit of tuneup and more documentation.
Thanks for reading this far and for any guidance and/or assistance you may be willing to provide.