# Does SHAPE_Length take into account elevation values?

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?

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

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

• It depends on the Shapefile [shape type] - if it is a PolylineZ
– Mapperz
Jul 29 '11 at 14:19
• @Mapperz SHAPE_Length is not automatically computed for shapefiles. Jul 29 '11 at 17:15
• Correct but shape_Return3D_Length.cal from ian-ko.com/free/free_arcgis.htm#Calculate will create the correct length
– Mapperz
Jul 29 '11 at 17:20

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?

• +1, Hmmm. That is very interesting. That changes my question. Jul 29 '11 at 15:27
• This answers my original question, and put me on track to realizing everything I needed to know to move on. Thanks! Jul 29 '11 at 15:42

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

• But what is the answer to the question? Jul 29 '11 at 14:57
• I have no problem storing or manipulating the Z values. I am using IPolyline. Jul 29 '11 at 15:10

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.

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/