nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Unsuccessful at getting Z-Value in Feet

SheldonBina2

Hello-

I am using Field Maps connected to a Leica GG04 GNSS Receiver. I have created an expression using Geometry($feature).Z in my Web Map and also created an Elevation field and calculated geometry using the Point Z-Coordinate Property in ArcGIS Pro. The value I get is the correct Mean Sea Level elevation, but it is in meters. I am using the Geoid18 model and have the vertical coordinate system set as NAVD88 (height) (ftUS) in my feature layer, and have settings set to US Feet in the Leica Zeno Connect App. I'm not sure if my workflow is complete or is this a limitation of collecting Z-Values in Field Maps? Any guidance/assistance is appreciated.

Thank You!

Finde mehr Beiträge mit dem Tag

Accepted answers

KevinBurke

Hi @SheldonBina2

Sorry for the delay.

The support for vertical datum transformations is something we hope to implement in the second half of 2021 within ArcGIS Field Maps.

Thank you

-Kevin

KevinBurke

Hi @SheldonBina2

That is correct. In this case because the elevations are coming from Zeno Connect with a vertical coordinate system of NAVD88 in meters, once Field Maps supports vertical datum transformations, the app should be able to transform into NAVD88 in feet. However because Field Maps doesn't currently support vertical datum transformations, the elevations obtained from Zeno Connect remain as-is in units of meters.

This is why I suggested that since the elevation values themselves are accurate from Zeno Connect and all that's needed is a unit conversion, you could use the Project geoprocessing tool in ArcGIS Pro to vertically transform to NAVD88 in feet.

Or, if all that's needed is the actual elevation values themselves, you could use ArcGIS Pro to add the Z values from the features geometry into the attribute table and then simply use the Field Calculator to convert to feet. This of course doesn't update the values that are still part of the geometry still being in meters.

With regards to horizontal transformations, yes, this happens in Field Maps per the Location Profile configured and the datums/projections chosen between the GNSS correction service and the web map's spatial reference.

Thank you

-Kevin

All comments

KevinBurke

Hi @SheldonBina2,

Thank you for the feedback.

Currently by default, the units for Z-values stored with the feature geometry is in meters this is due to the NMEA standard also sending the elevation values in meters.

ArcGIS Field Maps doesn't currently have support for performing vertical datum transformations to the desired vertical coordinate systems and in the desired units of feet. This is functionality that's on the road map to be supported in a future release.

In this scenario because you've captured features using the Geoid18 gravity model from Zeno Connect and have confirmed the values themselves are correct, just in meters instead of feet using NAVD88, you could use the Project geoprocessing tool to perform a vertical datum transformation to output to the NAVD88 ft VCS in Pro. This will require the Coordinate System Data to be installed for ArcGIS Pro.

- Have you configured a RTK correction source within Zeno Connect?

Thanks

-Kevin

SheldonBina2

Hi Kevin,

Thank you for the information.

Yes, I have configured an RTK correction source within Zeno Connect. It is in NAD83 2011.

Do you have an idea on when this functionality will be released within Field Maps?

Thanks again,

Sheldon

KevinBurke

Hi @SheldonBina2

Sorry for the delay.

The support for vertical datum transformations is something we hope to implement in the second half of 2021 within ArcGIS Field Maps.

Thank you

-Kevin

SheldonBina2

Sounds good Kevin. Thanks for the update!

KevinBurke

Hi @SheldonBina2 I just wanted to follow-up just to check that I've answered your original question?

Thanks

-Kevin

SheldonBina2

Hi Kevin-
I believe so. I was hoping it could just be a "transfer" of the Zeno Connect NAVD88 elevation in feet to Field Maps or a simple calculation to feet, but it sounds like the datum transformation has to actually happen within Field Maps? I guess it brings up another question. Since it is possible to get horizontal coordinates in feet using Field Maps, is this transformation actually happening within Field Maps and not a simple "transfer" of the coordinates in feet from Zeno Connect?
Thank You for the follow-up.
Sheldon

KevinBurke

Hi @SheldonBina2

Thank you

-Kevin

SharonUngerer_DNREC

This post is super helpful thank you! I just want to make sure I am on the right track because there is esri documentation out there that the location profile doesn't change the GNSS metadata fields collected from receivers.

Is this true only of the metadata fields? Does the location profile perform a datum transformation on the feature geometry and the metadata fields?

"Latitude—Position received from the GPS receiver prior to applying data transformations in the location profile
Longitude—Position received from the GPS receiver prior to applying data transformations in the location profile
Altitude—Ellipsoidal height received from the GPS receiver (not orthometric height, as used for z-values)"

Collector: https://doc.arcgis.com/en/collector/android-phone/help/high-accuracy-prep.htm#ESRI_SECTION1_C992B4FE465A4AFAB98A4972E336E808
Field Maps: https://doc.arcgis.com/en/field-maps/android/help/high-accuracy-data-collection.htm
Collector (Classic): https://doc.arcgis.com/en/collector-classic/ios/create-maps/gps-map-prep.htm

JustB

Hi Kevin, is there any update on this functionality for Field Maps? We just upgraded to new Trimble R2 units and are now recording data straight to Field Maps instead of manually uploading shapefiles from the units. However, I noticed that all of our Z values are reported in meters in the attribute geometry, even though both our projected and vertical coordinate systems are in US Feet. I'm just wondering if I need to change anything for my feature class configurations or my map settings, or if this functionality is still in the process of being rolled out.

Here's an example of what all of our recent attributes look like. The Geometry still says "Z (US Feet)", but it is actually recording in meters. For reference, our elevation is about 4,310 Ft on average here.

MikeDahm

Is there an update on when vertical datum transformations will be in ArcGIS Field Maps?

NateKirkwold

@KevinBurke Hi Kevin, it looks like there are still a few of us running into this issue with Z values. Is there a configuration setting we might be missing or is this feature still in the process of being rolled out?

Thank you!

-Nate

ADS

Hello, I will ask the same question for us for year 2023. When will US ft. be usable in any of these apps. We are trying to not post processs.

MikeDahm

I have been waiting a long time for this feature. We got several trimble units and use Field Maps (was collector) letting our clients know this feature was coming. Second half of 2021 was a long time ago.

RyanJalynski

I'm also waiting for this feature to be available. Is this no longer being considered for development?

KevinBurke

Hi @ADS , @MikeDahm, and @RyanJalynski I apologize for the delayed response. Support for vertical datum transformations is absolutely still on our mid-term road map for Field Maps. More information will be provided as it becomes available for this work.

If the goal is to just see the converted Z values in units of US Feet for point features in the form while out in the field, then this is possible through the use of the Calculated Expressions through the Field Maps Designer (ArcGIS Online, Enterprise 11+). In that case you would create a double field in the attribute table, and add the following calculated expression to the field in the smart form:

// Get the Z value

var geom = Geometry($feature)

if (IsEmpty(geom)) {

return null

} else {

return geom.Z * 3.28084

}

While that will store the Z value as an attribute in the new field in units of feet, it will not convert the actual Z value that is part of the point geometry. That will still be in units of meters. If that's the goal then, as I mentioned in an earlier post, you will need to use the Project geoprocessing tool in Pro to covert the vertical CS to one that supports US Feet.

Please let me know if you have any questions.

MikeDahm

Is this converting elevation in height above MSL? Or is this still height above ellipsoid? We need height above mean sea level.

Aymen_Farhat

Any updates?

JonRedd

Thank you Kevin, this helps tremendously for point layers. Do you happen to have a current option for line features. In ArcPro you can utilize the calculate geometry attributes and I have it set in a model tool to get the minimum z value to populate one field for a pipe feature and the maximum z-coordinate to populate another field. I am switching to hosted feature layers to get rid of all post processing through ArcPro and only utilizing Online and Field maps for collecting the data.

BillFox

for comparison, has anyone tried the option of similar workflow with ArcGIS Pro 3.2.1/Windows 11 tough-book/tough-tablet in the field for on-the-fly (no back office post-processing) horizontal state-plane feet and NAVD88 vertical (Ortho-metric Height in feet)?

KevinBurke

Hi @JonRedd

I was able to leverage the following calculated expression for the form in Field Maps to obtain the maximum Z value:

var geom = Geometry($feature);

var z = [];

for (var part in geom.paths) {

var line_part = geom.paths[part]

for (var i in line_part) {

var vertex = line_part[i]

var zval = vertex.z

z[i] = zval

}

return Max(z)

for the minimum Z, just update the last line from Max to Min.

In my scenario I published a line feature and added two double-type fields, one for max Z and one for min Z and added this as a calculated expression for both using Field Maps Designer.

Let me know if you run into any issues with those.

Thank you!

Nick_Creedon

I have setup a profile in field maps and set my GNSS Coordinate System, Map Coordinate System and Datum Transformation and my Z values were still coming out in meters.

I created a web map projected in my local state plane and my layers are also in a local state plane.

My antenna is a trimble R2 usings our local VRS

I did notice I had my "Units" under general settings set to "AUTO" I changed that and need to try it again.

In field maps, you can see the location accuracy of the antenna, if you click that you get more detailed location accuracy. In there I see my elevation in FT but once I brought it into pro the underlying Z data was in meters.

I am curious if other have had any success?

Whitewater

Checking in on this thread in 2026... Have the same exact setup, only have been directed to workarounds to get accurate U.S. Ft Z-value later transformed or calculated in a field. I'd like both my horizontal and vertical datum in U.S. Feet, but I always have to set the vertical to be in meters. Is there a roadmap where this feature is still on?

TylerHomrich

@KevinBurke is there any update on adding support for vertical datum transformations in field maps. Having to perform a post processing tool on the data is not a total solution and is only a work around. This is really hurting the ability to use field maps to collect data directly into the system of record, and is forcing people to temporary feature classes to collect the data then post processing the data then append it to the system of record that use 3D data. This is very important for certain areas like sanitary and storm sewer utilities where the elevations are used in a lot of analysis.

KevinBurke

Hi @TylerHomrich

Just to confirm, you're looking to have the Z values stored in units of feet over meters directly in the feature geometry itself as oppose to simply storing it as an attribute via a form calculation. Is that correct?

Thank you!

-Kevin

TylerHomrich

Yes. I have a data in NAD 83 (2011) Michigan State Plane South (intl feet) and NAVD88 height (Intl feet) as the vertical datum. We use the Z values stored in feet for analysis on slope calculation for new builds to ensure we will have enough slope for proper flow for Storm and Sanitary Sewer work. It would be much cleaner and efficient if we could collect data directly into our system, but instead we have to do use a GPS only feature to collect the data then migrate it over later.

Nimm an der Diskussion teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.