# Field Map Measurements - which is correct?

1906
7
01-04-2023 06:24 AM
New Contributor III

Hello - I have field workers who need line measurements in feet. My feature is in state plane (feet). I am utilizing the shape length to provide them with a measurement. However the Field Maps app is giving us a separate measurement in feet in the data entry pop up window and I don't know which is correct. I am not the one in the field. Screenshot attached for information. The data field Span Distance is pulling from Shape Length and displaying 131.22 feet, so I feel like that is correct. But the fielders are asking about the 372.0 ft displayed up top. And when I measure in my configured Web App, the 372.0 ft looks correct as opposed to my shape length.

Which number is correct? And if the 372.0 ft is correct how do I get that into my data? If that 372.0 number is correct, why/how is my calculated shape_length so far off? I have quadruple checked that my data is in State Plane (feet).

Any help would be greatly appreciated.

1 Solution

Accepted Solutions
Regular Contributor

When you checked the CS, did you check in Pro or the hosted feature layer?  If you have a layer in Pro that is in state plane, but you publish it from a map who's CS is something other than state plane, the hosted layer will be published with the map's CS not the layer's CS (i.e the layer takes the CS of the map it is published from rather than it's own CS).

Also, if the hosted feature layer is state plane, is the web map's basemap also state plane?  The default is Web Mercator.  The difference in the numbers is almost, but not quite the difference between meters and feet.

In the web, I tend to avoid mixing CS at all cost.  Either everything is Web Mercator or everything is state plane (including the basemap).

Have you tried calculating the length using arcade? It will depend on the situation but try these and see what it returns:

Geometry(\$feature)

Length(\$feature, 'feet')

Length3D(\$feature, 'feet')

LengthGeodetic(\$feature, 'feet')

- Justin Reynolds, PE
7 Replies
Regular Contributor

When you checked the CS, did you check in Pro or the hosted feature layer?  If you have a layer in Pro that is in state plane, but you publish it from a map who's CS is something other than state plane, the hosted layer will be published with the map's CS not the layer's CS (i.e the layer takes the CS of the map it is published from rather than it's own CS).

Also, if the hosted feature layer is state plane, is the web map's basemap also state plane?  The default is Web Mercator.  The difference in the numbers is almost, but not quite the difference between meters and feet.

In the web, I tend to avoid mixing CS at all cost.  Either everything is Web Mercator or everything is state plane (including the basemap).

Have you tried calculating the length using arcade? It will depend on the situation but try these and see what it returns:

Geometry(\$feature)

Length(\$feature, 'feet')

Length3D(\$feature, 'feet')

LengthGeodetic(\$feature, 'feet')

- Justin Reynolds, PE
New Contributor III

Hello,

Ah okay, that must be where I went wrong. I as aware of that as an issue before and I must have overlooked that when putting this together this time. I am too far down the line and data collection has started so I cannot remake these layers again. I'll have to fix it on the back end.

Thank you for your input, it does sound like my error was not updating the CS of the map in Pro.

New Contributor III

I didn't see the second part of the message earlier. I have tried the Length(\$feature, 'feet') in the past for other projects and it always results in either an error or 0 for some reason for me. Which I don't understand.

Regular Contributor

When authoring the arcade expression in the Arcade Editor, the "test" \$feature may not exist.  If it does exist its \$Geometry may be null.  The "test" feature is the first feature in your dataset.  If you don't have any data collected yet then this is a case where you may get an error or 0 because the Arcade editor didn't find a feature in which to test with; but once you are in field maps you'll have a feature and its geometry to work with... its geometry will change as you add points to the line and you calculation will update as a result.

Also, a point feature won't have a length.

In Arcade, you will want to protect yourself from null geometries before trying to using it as a argument in a function, such as with the Length functions. Otherwise, you may get errors until the geometries exist.

Here is an example using a couple of test geometries unrelated to a feature:

``````// CREATE a POLYLINE TO TEST WITH
var polylineJSON =
{
"paths": [
[
[-97.06138,32.837],[-97.06133,32.836],
[-97.06124,32.834],[-97.06127,32.832]
],
[
[-97.06326,32.759],[-97.06298,32.755]
]
],
'curvePaths': [[]],
"spatialReference": { "wkid": 3857 }
};

// TEST 1 -> Non Empty Geom
var geom = Geometry(polylineJSON);

// Test 2 -> Empty Geom
// var geom = Geometry({})

console(geom);
if (!IsEmpty(geom)){return Round(lengthGeodetic(geom, 'feet'), 4)};

// ^^^ Returns 0.0294 feet -> Testing with the "Non Empty Geom"
// ^^^ Returns Null -> Testing with the "Empty geom"``````

The same thing, but using the feature's geometry:

``````if (!IsEmpty(Geometry(\$feature))) { /* -> Handle No Geometry*/
return round(lengthGeodetic(Geometry(\$feature), 'feet'), 4)
}; // ELSE -> Return Nothing``````

@MichaelLohr  makes some great points below about the shape_length or area fields.  I would not use them for the purpose you need them for.  Instead access the geometry itself to determine the length on-the-fly with Arcade.

Keep in mind, that this too will stop being a source of truth if the lines are manipulated outside of field maps or the map viewer that uses the field maps form as the calculation won't update if not editing with the form.  You would then need to calculate manually again for it to be correct.

- Justin Reynolds, PE
Occasional Contributor II

The other thing to keep in mind is that in the underlying feature class for the online map, ESRI does not always maintain a live dynamic link between the geometry field in the shapefile or geodatabase and the feature )line segment), and if the original features ever get modified (split) the attribute table will still display the old (now incorrect) length in the shape field in the attribute table, until that field is manually recalculated in ArcMap. Those attribute fields drive the pop up boxes, so, if that outdated feature class makes it to an online map, or a hosted layer, it will still display incorrect geometry. You always want to recalculate all your geometry fields  in Pro or ArcMap prior to publishing a new map.

New Contributor III

That's interesting, I've never heard of that. Good to know. When I go to generate my deliverables, I'll calculate geometry on my length fields.

Occasional Contributor II

Area fields work the same way as length fields in shapefiles. Or if you ever calculate XY or Lat/Lon positions, then display them in your online map pop up boxes, if those points ever get moved for some reason, the attribute table will not display the updated position in those fields until manually recalculated, although the position on the map will be correct. Consider those geometry fields to be simple labels that are disconnected from the actual feature and not updated automatically. And you are provided no message or warning that your labels are no longer correct.

The nuance is that if your underlying features are contained in a file geodatabase rather than a simple shapefile, then the "SHAPE_Leng" and "SHAPE_Area" fields are dynamically updated and you cannot modify those. However, if the geodatabase got converted or exported to a simple shapefile, then the dynamic updating does not continue in the shapefile. Hope that helps.