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.

[PhillipWhatley]

@tikola what is the geoprocessing tool to extract the geometry Z value to the attribute table?

[tikola]

Calculate Geometry Attributes:

Calculate Geometry Attributes (Data Management)—ArcGIS Pro | Documentation

Need to study a bit what was the tool vice versa

[ArchieStewart]

We are looking to collect data points including orthometric heights in the UK compatible with OS.

We are using Trimble Catalyst for RTK.

What is the simplest way to achieve this?

It seems very clumsy that we have to use workarounds to record the Z correctly.

We are not GIS professionals and need software that provides the accurate information quickly without building in areas for error. 

Is there a plan for this to be included in Field maps soon? 

[Y_Chau]

@ArchieStewart if you are using a Trimble receiver then it is already possible in Field Maps. One condition, your geoid model should be there in TMM. Check with your local Trimble dealer.

[ScottKiley]

The Geoid Model isn't the only condition. The data must also be Z-Enabled, but maybe that was assumed to already be configured.

Recent activity on these posts describes all the requirements:

https://community.esri.com/t5/arcgis-pro-questions/converting-from-ellipsoidal-to-orthometric-height... 

https://community.esri.com/t5/arcgis-field-maps-questions/high-accuracy-gps-leica-gg04-plus-field-ma... 

[ArchieStewart]

Thank you

https://community.esri.com/t5/user/viewprofilepage/user-id/544039

https://community.esri.com/t5/user/viewprofilepage/user-id/52333

The geoid is showing in Trimble and the data is Z enabled.

What is really needed is a solution to the problem rather than workarounds.

[LaurenceLanglois1]

Archie Stewart, I agree with you. No workarounds!

If the application knows and can display the correct elevation for a given point, why isn't there a simple, built-in function to automatically capture that specific elevation value into an 'elevation field' when the point is created?

This seems like a logical and necessary feature. Having an 'elevation field' that automatically populates with the accurate elevation data already available within the app would streamline workflows and improve data accuracy, eliminating the need for manual input or potentially cumbersome workarounds. It definitely raises the question of why this seemingly straightforward functionality might be missing or difficult to implement from the developer's side. It has been over 3 years since this came up.

Also, I am looking for instructions to use a base map in my 'State Plane Projection' in Field Maps. It is not straightforward, and doing that seems like a workaround...

[tikola]

Half a year ago I would have said that Laurence&Archie you nail the need. Now when rethinking the issue the more sense the current approach makes. Altitude/height/feature Z is a complex topic and you can not use it in same way as you handle X and Y coordinates. Horizontal coordinates can be converted from system to another via pure calculations. ArcGIS automatically handles them correct by default. If coordinate system is known, the software makes needed mathematical reprojections and it works always correctly.

Height system conversions are not equally mathematical. There is often a gravity measurement based reference (geoid model) that is needed to convert height system to another. This is why software makes no automatic system conversions and it just uses height in way user has set it up.  If you want to convert height you really need to do it and change the values. That is the reason why you need in ArcGIS Pro the Additional Geometry Models package. That gives you the geoid models needed to convert elevation systems.

In philosophical sense you can use statement: “Height totally depends where you just happen to set the reference level.”  That defines the whole problem quite well. It is easy to say that second floor is higher than first floor but what happens if second floor happens to be on the other side of the country – which is higher then?

I assume you are referring for example to a Sewer Data Management solution and its Manhole layer. The field you are referring has an alias name Altitude. The field itself is named as an ESRIGNSS_ALTITUDE.  That field name explains more about the field than the alias it has. It is a GNSS metadata based Z value. It is not a true altitude in system you choose. It is just a GPS metadata as device it reports. That in all cases is an ellipsoidal height in WGS84. The main issue here is that alias naming for that field is slightly misleading. Leaving just a word Altitude leads to impression you have true height of the target. Alias should probably be GPS Altitude etc. So Alias as a name is not as good as it can be – that I agree.

The wish you have makes in generally sense. You want to see true height of a target immediately after mapping. If you think Esri environment in generally this wish is a clear exception in this whole ecosystem. Geometry is always stored in feature geometry and in top of that feature has some attributes that have some characteristic value. Coordinate information is never written/stored in attributes. Coordinates can be shown in attributes but that requires separate geoprocessing. It is done by Calculate Geometry Attributes tool and that gives the thing you need. That is always a static once calculated value and it does not follow the changes made in feature. So if you remap/edit the feature the geometry values written in attributes does not change. That is one reason geometry and attributes are not in same table.

So you are really requesting – would it be possible to start store feature Z value in totally different way than anywhere else in Esri ecosystem?

I understand the need. I want also to store Rim Elevation in this way and I want it to be an attribute value so that editing that value in field is easy enough. So the need I have is that whenever I map a new Manhole its Geometry Z value is written to Rim Elevation field. I believe this is your request too. Why it is not a default function?

• Esri never stores geometry in attributes
• Your idea works with points – how about lines and polygons? I mean single feature with multiple tie points can have just one attribute value for height. How you handle the variations in tie point heights? This issue appears for example in sewer pipes in this same solution.
• Height systems are different – depending how you tune up system you get/want a different number in height. How Esri can assume that number you have given is a correct height? GPS metadata value is more explicit and it is always correct.

You say that there should not be workarounds. I say that there is so many things related in this topic you must anyway to do a workaround. Following simple Arcade returns geometry z value to a RIM elevation:

var featureGeometry = Geometry($feature);

var geometryZ = featureGeometry.Z;

if (geometryZ == null) {

  return null

}

return Round(geometryZ,2)

It is used in Field Maps Designer forms. The requirement of using this is that device and location profile is tuned so that I really get local height in Geometry.Z So when process is working as it should I can get Rim Elevation attribute to follow Z value stored in feature geometry immediately when mapped in Field Maps.

So yes you can tune up you system return correct feature height in some attribute. You need to make sure that settings are correct before you can do it like this. So in height many thing should be correct before you can do it in this way. In X and Y it does not matter – ArcGIS makes conversion on the fly if needed but it does not do that with height. Z is just a value that is shown as system gets it.

This has nothing to do with Z accuracy. Accuracy is always same no matter which height domain is used. So accuracy is just as device says and that is clearly stored in GPS attributes when using Field Maps.

Feature height is a very complex thing and you can not simplify it in a way stated in comments here.

[LaurenceLanglois1]

I think it's reasonable to ask for rim elevation to be filled in at the time of the point snap.  The Leica app shows the height.  example 120ft

[tikola]

Which this script does: 

**********************************************

var featureGeometry = Geometry($feature);

var geometryZ = featureGeometry.Z;

if (geometryZ == null) {

  return null

}

return Round(geometryZ,2)

****************************************

The question is what is the correct field in each case where height is written? In manhole case it is rim elevation but in some other data it is something else. So it is impossible to make a generic tool that always writes correct value in correct place.

In practise 3d mapping works well when your setup is tuned for that excact case. Things gets bit more complex if you vary what you map and where. However with water facilities mapping is nearly always remapping (or adding) manholes or valves. You rarely map something else.

I am pretty happy with current setup. It works extremely well with local water utility companies that I work with. 

I can easily show you way more complex ancient text file based formats that are till very commonly used in mapping tasks here.