SHAPE_Length是否考虑了海拔值？

该Shape_Length属性是否考虑了海拔？举例来说，如果我有3点：A，B，和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

然后创建两行：L1和L2。

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

我所观察的结果是，SHAPE_Length属性上是相同的L1和L2。我已经确认所有点和所有折线都是ZAware。

因此，假设SHAPE_Length属性将形状的Z考虑在内是我的错误吗？

我可以毫无问题地存储Z值或对其进行操作。我正在使用IPolyline。

据我所知，SHAPE_Length仅是2D且不可编辑。

我已经使用PolylineZ，PolygonZ和PointZ要素类很长时间了，我的经验是该SHAPE_Length字段严格为XY。因为我没有3D分析师（我的老板认为不合适），所以我不得不做一些花哨的几何图形来处理高程。（是的，从理论上讲，向量方程式会更容易，但是我现在还不了解这一点。）因此，如果没有3D Analyst，它似乎SHAPE_Length只是XY。现在，3D Analyst可能会或可能不会在3D中显示这些自动字段。我不知道 是否有幸运的3D Analyst用户知道该消息？

可以将转换为PolylineZ高程的Z值存储在PolylineZ Shapefile形状类型中：

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

看到

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

下：

可变长度记录内容取决于形状类型。以下是可能的形状类型：

ET GeoWizard可以快速将Polyline转换为PolylineZ。 http://www.ian-ko.com/ET_GeoWizards/gw_demo.htm

如果使用基于Open GIS联盟简单要素规范的ArcSDE或RDBMS，则长度为2D。即使在1.2.1规范中，Z值仍仅为纵坐标；X和Y是标准化几何的唯一坐标。二进制几何仍然不包含Z或M作为规范的一部分。
请参阅第6.1.5节：
http : //www.opengeospatial.org/standards/sfs
在检查规范的几种实现时，它们都指定曲线的ST_LENGTH目前不考虑Z值，并且看起来规范测试没有考虑Z值。

我不确定文件地理数据库是否可以实现Z坐标。与ArcSDE不同，文件地理数据库使用真实曲线而不是密集曲线，并且不遵循OGC SFS。因此，文件地理数据库可能会进行Z感知的长度计算。

它是2D。如果要计算3D线的3D长度，请使用ICurve3D :: Length3D http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/Length3D_Property/002m0000010s000000/