SHAPE_Length leva em consideração os valores de elevação?

O Shape_Lengthatributo leva em consideração a elevação? Por exemplo, se eu tenho 3 pontos: A, BeC

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

Então eu crio duas linhas:, L1e L2.

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

O que estou observando nos resultados é que o SHAPE_Lengthatributo é o mesmo para ambos L1e L2. Eu verifiquei que todos os pontos e polilinhas são o ZAware.

Então, estou errado ao assumir que o SHAPE_Lengthatributo leva em consideração o Z das formas?

Não tenho nenhum problema em armazenar os valores Z ou em manipulá-los. Eu estou usando IPolyline.

Pelo que ouvi, SHAPE_Length é apenas 2D e não é editável.

Há muito tempo que trabalho com as classes de recursos PolylineZ, PolygonZ e PointZ, e minha experiência é que o SHAPE_Lengthcampo é estritamente XY. Como não tenho analista em 3D (meu empregador não achou adequado obtê-lo), tive que fazer uma geometria sofisticada para trabalhar com elevações. (Sim, as equações vetoriais seriam teoricamente mais fáceis, mas não estou de acordo com isso no momento.) Portanto, sem o 3D Analyst, parece que SHAPE_Lengthé apenas XY. Agora, o 3D Analyst pode ou não descobrir esses campos automáticos em 3D. Eu não saberia. Algum usuário sortudo de analistas em 3D conhece o furo?

Converter em PolylineZ para elevação pode ser armazenado como um valor Z nos tipos de forma PolylineZ Shapefile:

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

Vejo

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

debaixo:

O conteúdo do registro de comprimento variável depende do tipo de forma. A seguir, são possíveis os tipos de formas:

O ET GeoWizard pode converter Polilinha em PolilinhaZ rapidamente. http://www.ian-ko.com/ET_GeoWizards/gw_demo.htm

Se você estiver usando um ArcSDE ou um RDBMS baseado na especificação de recursos simples do Open GIS Consortium, o comprimento será 2D. Mesmo na especificação 1.2.1, os valores Z ainda são apenas valores ordenados; X e Y são as únicas coordenadas da geometria normalizada. A geometria binária ainda não inclui Z ou M como parte da especificação.
Consulte a seção 6.1.5:
http://www.opengeospatial.org/standards/sfs.
Verificando várias implementações da especificação, todas especificam que ST_LENGTH para curvas não leva em consideração os valores Z neste momento e não parece que os testes de especificação levem em consideração os valores de Z.

Não tenho certeza se um arquivo-geodatabase implementaria coordenadas Z. Ao contrário do ArcSDE, os bancos de dados de arquivos usam curvas verdadeiras, em vez de curvas densificadas, e não seguem o OGC SFS. Portanto, é possível que os bancos de dados de arquivos estejam fazendo cálculos de comprimento ciente de Z.

É 2D. Se você deseja calcular o comprimento 3D para linhas 3D, use ICurve3D :: Length3D http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/Length3D_Property/002m0000010s000000/