Measure the orthometric height in Field Maps

[Hegik]

What the Field-Maps App is doing:

Right now our measurement crews connect their GNSS-antenna to their iPad (iPad Pro 11”, 2nd generation running iOs 14.3) and add points to our web-feature-layer. The height, which the app is saving is known as “Height Above Ellipsoid”. Germany (and other European countries) use another height called the “Normalhöhennull” (orthometric height). The Field-Maps app can display the “Normalhöhennull” but it will only save the (for us useless) “HAE”.

What is the problem:

If we want to measure the height of the GNSS-antenna, we always need to open the app of the antenna manufacturer, copy the (orthometric) height, and then we paste it into a field of the feature layer we specifically created for this purpose. This adds human error to the process, which is unfortunate. Another workaround would be post processing the data, but that would need a person who does that, and would probably add calculation error, so we would like to have it shown correctly in the first place.

How this will help us:

In the past few months we’ve invested in a lot of hardware (e.g. GNSS-Antennas, iPads, etc.) with the goal to simplify the process of our measurements, but with the wrong height it is more of an obstacle than a relief to use it. At the moment the data that the measuring crews are gathering, needs to be fixed by an ArcGIS Pro operator before it can be further processed and analysed by our CAD or laboratory staff. This adds big delays to our workflow.

Why this is important:

We as a German authority must work with our official German standards especially when we are measuring things. The “Normalhöhennull” is the standard for every German authority, office, department and university. I would say, that every time someone is measuring the height somewhere in Germany, it will most certainly need to be the “Normalhöhennull” because it is the national standard since 1992. Because of that not only our authority has this problem, but everyone who wants to measure the height in Germany using Field Maps.

[Y_Chau]

@LaurenceLanglois1 if you select the correct geoid in Leica Zeno Connect app then the MSL heights are transferred to feature Z. The GNSS metadata will always display HAE though. I did this test with Leica FLX100.

Sincerely

[Basbo]

@Y_Chauthank you for your message. What do you mean that the heights are transferred to feature Z?

Is there any attribute showing this information? Or do I need to add POINT_Z with ArcGIS Pro to see this value?

[Y_Chau]

@Basbo hello, Add XY Coordinates (Data Management)—ArcGIS Pro | Documentation

This tool will pull geoid heights from feature geometry and write them to POINT_Z field. Your layer SHOULD be Z enabled.

If you don't have one of the esri partner GNSS devices, then you will get ellipsoidal heights in both metadata and feature geometry. In this case you can do a vertical transformation from ellipsoidal to geoid, provided your geoid is available in the esri supported vertical CS files. You have to install a special CS package to do vertical transformations.

[LaurenceLanglois1]

My goal is to have this work without any extra steps.  My Zeno Connectpp shows the altitude on the screen. I would think it would easily move that altitude info into a field in field maps. That is not the case.

[ZachEdwards_WDSGIS]

Yes. I don't understand how orthometric heights are not standard in ESRI Field Maps. This post goes back to 2021 and yet here we still are in 2024. Let's get this implemented ESRI! Using Arcade is a nice workaround; however, it's still a bandaid. The same goes for the "colllected date." We shouldn't have to use Now() in an arcade expression to have the collector automatically collect today's date without input from the user. I realize that templates can be used for that too but it's still a workaround in my opinion. 

[LaurenceLanglois1]

Also setting the 'base map' for 'Field maps' to use in the projection I want is very complicated. I can't figute it out.
My collection points are off because the base map is not what I want to use.
Larry

[LaurenceLanglois1]

Also setting the 'base map' for 'Field maps' to use in the projection I want is very complicated. I can't figure it out.

My collection points are off because the 'base map projection' is not what I want to use.

Larry

[Sietse_de_Haan]

Hey guys,

I contacted Leica, and they send me some documents collect the correct height in NAP values (Dutch height).After installing in Zeno Connect we are now collecting heights in Dutch NAP values.

I dont know, but maybe this can work the same for the countries you are in. I cant attach them here for some reason (pdf and zip). Reach out to me if you want them.

[tikola]

As Y_Chau wrote it goes all the time correctly to feature geometry attribute if settings are as they should but stays wrong (or different) in normal attribute table. This is case in Finland where  Leica Zeno Connect contains neccessary geoid models. The steps I needed to do to make it work in Finland are:

1) Set Zeno Connect to use local projection and geoid model to get orthometric heights. I get confirmation that this works just by looking coordinate values that Zeno Connect shows.

2) Second I needed to make a webmap that had a basemap in projection my editable data is. In case you do not do that you end up easily to result that Profile you define in Field Maps is not valid for a map used and things stop there as map does not open at all in Field Maps

3) As a final step you need to define Profile in Field Maps that contains correct coordinate systems as they should be.

As an output of this process I get all the time in attribute table a height that is 20m above true orthometric value. That you may consider a bug or feature to be fixed but on the other hand it makes sense to store also the mathematic ellipsoidal height. So one way to fix this issue is to wrote attribute name in some more intuitive way than just "Altitude".....maybe "Ellipsoidal Altitude" would be a better name.

In the same time the feature geometry attribute is correct orthometric height all the time. The challenge of course is that ArcGIS Pro is the only(?) way to see this value. So system works as it should in a smart way but there is no very easy way to confirm this. And the only value you easily see  tells you that it has not worked in proper way. So before thinking that process does not work check always is there a difference in attribute table

There is no problem to transfer values from geometry attribute to normal attribute or vice versa. There is a geoprocessing tool in both ways.

[tikola]

After re thinking I agree there is a mislogic here. When using device internal GPS the attribute value works as it should but with extrenal GPS (Leixa FLX&Leica Zeno Connect) in my case it acts differently and stores ellipsoidal height despite everything is configured for orthometric. So that is a mislogic but I am not sure which is better - both ways have their sense. However as commented in Geometry.z this issue does not exist - Field Maps stores correct orthometric height always in geometry.z in my tests in Finland.