Unit Length Showing in Small Decimals

[Anonymous]

Hello!

I have features that I imported via 2d Shape files that on the GPS unit the data is collected on is displayed (rightfully) in feet, however when viewed in Map 3D are displayed as small decimals instead of the units selected (which is feet, verified via the UNITS command).

For example, a feature that is supposed to be approximately 100' in length is instead displayed as having a length of 0.0188097772

Any assistance with this would be greatly appreciated

[ChicagoLooper]

So you have a shapefile sitting in your drawing. What is the coordinate system assigned to modelspace? What are the 'units' of that CS?

[Anonymous]

I am currently using FL83-EF, which has US Survey Foot as the Unit.

What's interesting is that my area attributes are displaying correctly in square feet, however anything involving length is a long decimal like in the previous example.

I greatly appreciate your help thus far; your other solution worked fantastically!

[ChicagoLooper]

Shapefile attributes are not like AutoCad properties. When you stretch or shorted a line in AutoCad, the Properties Palette will reflect the change. When a shapefile's attribute is entered into the shapefile's database, it will remain as written until it is manually edited. The shapefile attribute values, despite geometric edits like stretching, are static. This contrasts with AutoCad because geometric changes  are dynamic.    

Would it be possible to upload the shapefile or further troubleshooting?

[Pointdump]

Vincent,
Can you post your data and drawing?
Dave

[parkr4st · Accepted solution]

open the data table, right click a column header and enter the formula   Length2D ( Geometry )    and  click   OK

check the distance calculated to see if it is the correct number of feet or the decimal such as your example .

dave 

[Anonymous]

Thank you all for the assistance, Dave's solution of adding a Length2D calculation does what I was looking for!

[parkr4st]

all that does is show the length is calculated correctly based on?  ground measurements? or other?

The decimal problem may still exist and as was stated first is likely related to a coordinate system problem.  That problem should be eliminated for sure.

and if that calculation is correct the data will need to be saved to a sdf or bulk copied so the new column is added to the data table for future use.  MApimport and mapexport can be used to tailor the data table to what is needed in a particular FDO file format.