Attribute Rule Auto Calcualte Length Arc Pro 2.8

[srpotter]

I have a line feature class with domains set and I am trying to auto populate/calculate a field (LIN_FT) with the length in FT using the Add Attribute Rule. My understanding is it can be done however the hang-up is with the expression, or so I think. 

[RhettZufelt]

Try something like this in the expression:

Length($feature, 'feet')

R_ 

[srpotter]

 Tried both with no success. 

Length($feature.LIN_FT, 'feet')

Length($feature.LIN_FT)

[RhettZufelt · Accepted solution]

Close, but having the field (LIN_FT) in there is "confusing" it.

Drop the .LIN_FT from it:

Length($feature, 'feet')
or
return Length($feature, 'feet')

R_

[RobertBorchert]

Why not simply use the shape length field that is already in existence and calculate it into a Integer(long) field unless the decimal point accuracy is necessary.  If you shape length is calculated in Meters simple do 

Shape_Length / 3.28084     where 3.28084 is the number of feet in a meter

[srpotter]

The goal would be for the end user to not have to do any calculation. The desired result is for the line to be created and the LIN_FT field to be auto populated with with the length in Ft.

[RhettZufelt]

I was continuing your method with the arcade "Length()" option.  However, @RobertBorchert suggestion would work just as well, maybe better and does not need any user calculations.

When a line is created/modified, the Shape_Length field is automatically populated/updated with length in map units.

If you used that method, it would not need to calculate the length for each feature twice.  Since Shape_Length is already populated, it just converts it to feet (assuming your data is in meters, and that is the whole purpose of this)

So, instead of 

Length($feature, 'feet')

you would just use:

$feature['Shape_Length'] / 3.28084
or
return $feature['Shape_Length'] / 3.28084

Also, from the Arcade documentation:

Also note that geometries fetched from feature services, especially polylines and polygons, are generalized according to the view's scale resolution. Be aware that using a feature's geometry (i.e. $feature) as input to any geometry function will yield results only as precise as the view scale. Therefore, results returned from geometry operations in the visualization and labeling profiles may be different at each scale level.

I really can't find much info regarding this, and if it ONLY applies to feature services and not feature classes, or how much affect it might have at your digitizing scales, but, if it does apply, @RobertBorchert suggestion shouldn't be subject to this as it is just basic math on existing fields and is not using Geometry functions.

R_