Berücksichtigt SHAPE_Length Höhenwerte?

Hat das Shape_Lengthnehmen Attribut berücksichtigt die Erhebung? Zum Beispiel, wenn ich 3 Punkte haben: A, B, undC

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

Dann erstelle ich zwei Zeilen: L1und L2.

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

Was ich in den Ergebnissen beobachte, ist, dass das SHAPE_LengthAttribut für L1und gleich ist L2. Ich habe überprüft, dass alle Punkte und alle Polylinien ZAware sind.

Bin ich also falsch anzunehmen, dass das SHAPE_LengthAttribut das Z der Formen berücksichtigt?

Ich habe kein Problem damit, die Z-Werte zu speichern oder zu manipulieren. Ich benutze IPolyline.

Nach dem, was ich gehört habe, ist SHAPE_Length nur 2D und kann nicht bearbeitet werden.

Ich arbeite seit langer Zeit mit Feature-Classes von PolylineZ, PolygonZ und PointZ und habe die Erfahrung gemacht, dass das SHAPE_LengthFeld ausschließlich XY ist. Da ich keinen 3D-Analysten habe (mein Arbeitgeber hat es nicht für angebracht gehalten, ihn zu erhalten), musste ich eine ausgefallene Geometrie erstellen, um mit Höhen zu arbeiten. (Ja, Vektorgleichungen wären theoretisch einfacher, aber dem bin ich momentan nicht gewachsen.) Ohne 3D Analyst scheint es also SHAPE_Lengthnur XY zu sein. Jetzt kann 3D Analyst diese automatischen Felder in 3D darstellen oder nicht. Ich würde es nicht wissen. Kennen glückliche 3D Analyst-Benutzer die Schaufel?

In PolylineZ zur Ansicht konvertieren kann als Z-Wert in PolylineZ-Shapefile-Formtypen gespeichert werden:

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

Sehen

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

unter:

Der Inhalt des Datensatzes mit variabler Länge hängt vom Formtyp ab. Folgende Formtypen sind möglich:

ET GeoWizard kann Polyline schnell in PolylineZ konvertieren. http://www.ian-ko.com/ET_GeoWizards/gw_demo.htm

Wenn Sie ein ArcSDE- oder RDBMS verwenden, das auf der Open GIS Consortium Simple Feature Specification basiert, beträgt die Länge 2D. Selbst bei der Spezifikation 1.2.1 sind Z-Werte nur Ordinatenwerte. X und Y sind die einzigen Koordinaten für die normalisierte Geometrie. Die binäre Geometrie enthält immer noch nicht Z oder M als Teil der Spezifikation.
Siehe Abschnitt 6.1.5:
http://www.opengeospatial.org/standards/sfs Bei
einer Überprüfung mehrerer Implementierungen der Spezifikation geben alle an, dass ST_LENGTH für Kurven derzeit keine Z-Werte berücksichtigt Es sieht nicht so aus, als würden die Spezifikationstests Z-Werte berücksichtigen.

Ich bin nicht sicher, ob eine Datei-Geodatabase Z-Koordinaten implementieren würde. Im Gegensatz zu ArcSDE verwenden Filegeodatabases echte Kurven anstelle von verdichteten Kurven und folgen nicht dem OGC-SFS. Es ist also möglich, dass Filegeodatabases Z-fähige Längenberechnungen durchführen.

Es ist 2D. Wenn Sie die 3D - Länge für 3D - Linien zu berechnen, verwenden ICurve3D :: Length3D http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/Length3D_Property/002m0000010s000000/