Why does a constructed line, with a specific, manually entered length, not maintain that exact length in the shape_length attribute?

[Anonymous User]

ArcGIS Desktop 10.6.1, Windows 10, file geodatabase at default precision, NAD_1983_StatePlane_Kentucky_FIPS_1600_Feet

I'm certain that this subject has been discussed to death but I can't find anything specific to my needs.  If I draw a line in a featureclass and specifically enter it's length manually at 36 ft, why does the shape_length indicate 35.999972.  I think I have some inking into this phenomenon but I'd like a more definitive explanation to take to the CAD users that will want to know why these lines are not exactly 36 ft long.

Please help?

[DanPatterson]

you entered 36.0? or 36?   floating point representation would be my guess otherwise

[Anonymous User]

Thanks Dan. I have tried entering the value with and without decimal places.  Same results either way.

[jcarlson]

I'd check out the resolution of your feature class or dataset. We encounter this a lot with entering COGO lines for our parcel fabric. Because the default resolution is quite small, you will likely not be able to see it, but your vertices are actually being "snapped" to a minute grid.

For a neat "see it in action" exercise, create a new feature class in the same spatial reference, but manually enter the resolution as a much larger value, say 10 or 100 feet. If you attempt to create features in this new feature class, you'll find that you are literally unable to place vertices in between the 10 or 100-foot increments of your feature class's resolution.

Another test exercise: create the same line with a manually-entered length, and have it perfectly aligned with either the X or Y axis of your spatial reference, i.e., due north/south/east/west. More than likely, it will have a shape length of the value you entered, because of course 36 is divisible by .00001 or whatever it happens to be. It's at angles that the grid minutely shifts your vertices, leaving you with a slightly different length.

[Anonymous User]

This makes sense to me. I thought that "resolution" was the right tree to bark up.

How do you work around this issue in your parcel data?  Separate attribution? Higher resolution?

I ask because in the real world, especially with regard to the width of a survey pin or the width road striping, the default resolution of 0.003937 inches is essentially immeasureable.  Since the grid can't have 0 resolution though, I guess there will technically always be some error.

Thanks,

Hank Pritchard
Qk4 Engineering & Planning

[jcarlson]

Separate attribution is the way we go. In our parcel data (we use ESRI's Parcel Fabric data model), all boundary feature classes have separate COGO attribution, which are used to store the legal dimensions of a line. Adjacent deeds and surveys from different eras don't always agree, but we can represent what the different legal descriptions say about a shared boundary without necessarily making lines of different length.