Converting from Ellipsoidal to Orthometric Height

[DaveBodak]

We are working on taking some topographic shots and, from what we've read, it seems like Field Maps can only collect the Ellipsoidal height, even though Trimble Mobile Manager provides both the Ellipsoidal and Orthometric height.

After we collected the data (about 250 shots) we're looking for a way to convert over from Ellipsoidal to Orthometric. Does anyone know of an easy way to do this?

[BillFox]

does trimble capture the ellipsoidal height in meters, then convert it to orthometric height in meters before it sticks it in the z-value of the feature's geometry column?

[BillFox]

reference:

https://community.esri.com/t5/arcgis-field-maps-questions/field-map-alternatives-for-windows-11/m-p/...

"Planning to use ArcGIS Pro on Windows 11 tough tablet because it does the GPS RTK vertical elevation on-the-fly adjustment to orthometric height in ftUS into the geometry's z-value"

we have the EOS Arrow Gold+ rover unit with their EOS ProTools and the GoldRTK base station

[JPowell]

Hi Dave,

With a Trimble device (such as DA2/R2) here is the workflow I am using and some notes on where the real-time aspects fall short at the moment.

There is currently no way for a real orthometric height with a proper geoid model applied to write directly to attribute data within GIS. This shortcoming is not associated to the device, but present many devices like the Trimble DA2. The shortcoming lies with ESRI's GNSS metadata fields not having a field or other mechanism to write the numeric elevation into the data in real time. If there are devices that exist which have found a solution to this I'd be curious to know about them myself. Here is some other context:

• If GIS data is prepped properly, with z-enabled, and GNSS metadata fields applied, the correct elevation is present in the collected GPS shot, but it ONLY lives in the z-geometry of the feature (in metric). You will not find any mention of this requirement in any help-documentation from ESRI.
• Without a place for that information to be stored in GIS attribution, it requires a field calc in GIS of the z-geometry into a relevant field (e.g. rim elevation for a manhole). 
• This is the field calc I run - ROUND((Geometry($feature).Z)*3.28084,2).
• Again, if Z-enabled feature classes are not present there is no z-geometry for that elevation to be stored, and without attribution elsewhere, you are wasting your time in the field.
• It can be a common to assume the "altitude" field in GNSS metadata to be the desired value, but this measurement is typically only the HAE measurement and lacks the geoid model. 

[ScottKiley]

In typical Esri fashion the messaging is all over the place on this. As @JPowell mentioned there's no mention of publishing Z-Enabled data in their documentation to Prepare for high-accuracy data collection, but a video from their Field Maps team walks through setting up Arcade to calculate the Orthometric height without ever mentioning that the data needs to be Z-Enabled: https://community.esri.com/t5/arcgis-field-maps-videos/tip-from-morgan-zhang-collect-orthometric-hei... 

[tikola]

Yes:

https://pro.arcgis.com/en/pro-app/latest/help/mapping/properties/arcgis-coordinate-systems-data.htm 

I will do this on weekly/monthly basis. Typically a drone data is in ellipsoidal height and floats over the ground. I turn that to orthometric just using Project LAS Geoprocessing tool. But for normal vector GIS data Project geoprocessing makes the same thing.

Basically my instruction to my customers is that in ArcGIS there nearly never should be a situation where you need to go back on site and do remapping. You really can not map in such a wrong way that it can not be fixed at office.

So if we reply on original question is there a simple tool in ArcGIS Pro to fix elevation system the answer is yes. Or at least coordinate systems I use there is working and fairly simple solution.

[tikola]

Just made further tests in one case and current conclutions with latest 10/2025 Field Maps and Z value are

• Trimble external RTK GPS (R10 in my test) gives always one and single value to ESRI and it writes same value in geometry and Altitude GPS metadata field. The domain of value depends which vertical coordinate system is defined in Trimble Mobile Manager tool
• Leica external RTK GPS (FLX100 in my test) gives typically  separate values in feature geometry z and Altitude attribute. This is controlled by Leica Zeno Connect tool that defines the settings for device. Also projection of webmap affects on this - so you need to be careful that your map document and device settings match. However when settings are as they should Leica FLX gives nicely local orthometric heights in feature geometry and in same time writes in GPS metadata Altitude field proper GPS WGS84 ellipsoidal height. So Leica external GPS is only tool that currently gives me two separate values and logics for that makes sense - as well as writing same value in both.
• Apple mobile device internal GPS gives EGM96 height which in my case matches within accuracy limits to local orthometric system. So when using Apple in Field Maps I get local correct values without doing any tricks
• Biggest challenge in my case is Android mobile devices. Android reports height always in WGS84 ellipsoidal and that is in my case 20m off. So in nutshell for Android phone based mapping I need to run Project geoprocessing tool to get heights in correct local domain. 

So the real development need I see is that in Android there should be a way to get coordinates in some other form than WGS84. Is there any app/setting that would do such trick instead just reporting to Field Maps the  height the OS gives?