SHAPE_Length prend-il en compte les valeurs d'élévation?

L' Shape_Lengthattribut prend-il en compte l'élévation? Par exemple, si j'ai 3 points: A, BetC

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

Ensuite, je crée deux lignes:, L1et L2.

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

Ce que j'observe dans les résultats, c'est que l' SHAPE_Lengthattribut est le même pour L1et L2. J'ai vérifié que tous les points et toutes les polylignes sont ZAware.

Alors, ai-je tort de supposer que l' SHAPE_Lengthattribut prend en compte le Z des formes?

Je n'ai aucun problème à stocker les valeurs Z ou à les manipuler. J'utilise IPolyline.

D'après ce que j'ai entendu, SHAPE_Length est en 2D uniquement et n'est pas modifiable.

Je travaille depuis longtemps avec les classes d'entités PolylineZ, PolygonZ et PointZ, et mon expérience est que le SHAPE_Lengthchamp est strictement XY. Parce que je n'ai pas d'analyste 3D (mon employeur n'a pas jugé bon de l'obtenir), j'ai dû faire une géométrie de fantaisie pour travailler avec les élévations. (Oui, les équations vectorielles seraient théoriquement plus faciles, mais je ne suis pas à la hauteur pour l'instant.) Donc, sans 3D Analyst, il semblerait que ce ne soit que SHAPE_LengthXY. Désormais, 3D Analyst peut ou non représenter ces champs automatiques en 3D. Je ne sais pas. Les utilisateurs chanceux de 3D Analyst connaissent-ils le scoop?

Convertir en PolylineZ pour l'élévation peut être stocké en tant que valeur Z dans les types de formes PolylineZ Shapefile:

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

Voir

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

en dessous de:

Le contenu de l'enregistrement de longueur variable dépend du type de forme. Voici les types de formes possibles:

ET GeoWizard peut convertir rapidement Polyline en PolylineZ. http://www.ian-ko.com/ET_GeoWizards/gw_demo.htm

Si vous utilisez un ArcSDE ou un SGBDR basé sur la spécification d'entité simple Open GIS Consortium, la longueur est 2D. Même avec la spécification 1.2.1, les valeurs Z sont toujours des valeurs ordonnées; X et Y sont les seules coordonnées de la géométrie normalisée. La géométrie binaire n'inclut toujours pas Z ou M comme partie de la spécification.
Reportez-vous à la section 6.1.5:
http://www.opengeospatial.org/standards/sfs En
vérifiant plusieurs implémentations de la spécification, elles précisent toutes que ST_LENGTH pour les courbes ne prend pas en compte les valeurs Z pour le moment, et il ne semble pas que les tests de spécification prennent en compte les valeurs Z.

Je ne suis pas certain qu'une géodatabase fichier implémenterait des coordonnées Z. Contrairement à ArcSDE, les bases de données de fichiers utilisent de vraies courbes au lieu de courbes densifiées et ne suivent pas l'OGC SFS. Il est donc possible que les bases de données de fichiers effectuent des calculs de longueur prenant en compte Z.

C'est 2D. Si vous souhaitez calculer la longueur 3D des lignes 3D, utilisez ICurve3D :: Length3D http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/Length3D_Property/002m0000010s000000/