Does SHAPE_Length take into account elevation values?

Question

Does the Shape_Length attribute take into account the elevation? For instance, if I have 3 points: A, B, and C

A.X = 10
A.Y = 10
A.Z = 10
B.X = 10
B.Y = 10
B.Z = 50
C.X = 0
C.Y = 0
C.Z = 10

Then I create two lines: L1, and L2.

L1.fromPoint = A
L1.toPoint = C
L2.fromPoint = B
L2.toPoint = C

What I am observing in the results is that the SHAPE_Length attribute is the same for both L1 and L2. I have verified that all the points and all the polylines are ZAware.

So, am I wrong to assume the SHAPE_Length attribute takes into account the Z of the shapes?

UPDATE: I have no problem storing the Z Values or manipulating them. I am using IPolyline.

UPDATE 2: Apparently if you have 3D Analyst the SHAPE_Length does include the Z value. If not, it is strictly XY. IF that is the case is there a way in .NET ArcObjects to update the SHAPE_Length field to include the Z value in the calculation? Is there anything I need to do or watch out for when manually updating this attribute?

UPDATE 3: From what I’ve been hearing, SHAPE_Length is 2D only and isn’t editable.

Answer 1

I have been working with PolylineZ, PolygonZ, and PointZ feature classes for a long time now, and my experience is that the SHAPE_Length field is strictly XY. Because I do not have 3D Analyst (My employer has not seen fit to get it), I have had to do some fancy geometry to work with elevations. (Yes, vector equations would theoretically be easier, but I'm not up to that right now.) So, without 3D Analyst, it would appear that SHAPE_Length is XY only. Now, 3D Analyst may or may not figure these automatic fields in 3D. I wouldn't know. Do any lucky 3D Analyst users out there know the scoop?

Answer 2

It is 2D. If you want to calculate the 3D length for 3D lines, use ICurve3D::Length3D http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/Length3D_Property/002m0000010s000000/

Answer 3

If you are using using an ArcSDE or an RDBMS based on the Open GIS Consortium Simple Feature Specification, then length is 2D. Even at the 1.2.1 spec, Z values are still ordinate values only; X and Y are the only coordinates for normalized geometry. Binary geometry still does not include Z or M as part o the spec.
Refer to section 6.1.5:
http://www.opengeospatial.org/standards/sfs
Doing a check of several implementations of the spec, they all specify that ST_LENGTH for curves does not take into account Z-Values at this time, and it does not look like the specification tests take Z values into account.

I am not certain if a file-geodatabase would implement Z coordinates. Unlike ArcSDE, filegeodatabases use true curves instead of densified curves and do not follow the OGC SFS. So, it is possible that filegeodatabases are doing Z aware length calculations.

Answer 4

Convert to PolylineZ for Elevation can be stored as a Z Value in PolylineZ Shapefile shape types:

   PolylineZ    Mandatory: MBR, Number of parts, Number of points, Parts, Points, Z range, Z array
    Optional: M range, M array

See

http://en.wikipedia.org/wiki/Shapefile#Shapefile_shape_format_.28.shp.29

under:

The variable length record contents depend on the shape type. The following are the possible shape types:

ET GeoWizard can convert Polyline to PolylineZ quickly. http://www.ian-ko.com/ET_GeoWizards/gw_demo.htm