nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I found many problems with 3D arcpy.Polylines

AlessandroValra

This is just to inform about things that are most likely bugs.

I already posted a question and answer myself here: arcgis desktop - arcpy - creating a 3d arcpy.Polyline - Geographic Information Systems Stack Exchange.

The thing is: I need to create a 3d polyline with arcpy having a series of XYZ coordinates.

If I do:

<SPAN class="">array </SPAN><SPAN class="">=</SPAN><SPAN class=""> arcpy</SPAN><SPAN class="">.</SPAN><SPAN class="">Array</SPAN><SPAN class="">([</SPAN><SPAN class="">arcpy</SPAN><SPAN class="">.</SPAN><SPAN class="">Point</SPAN><SPAN class="">(</SPAN><SPAN class="">0</SPAN><SPAN class="">,</SPAN><SPAN class=""> </SPAN><SPAN class="">0</SPAN><SPAN class="">,</SPAN><SPAN class=""> </SPAN><SPAN class="">0</SPAN><SPAN class="">),</SPAN><SPAN class="">arcpy</SPAN><SPAN class="">.</SPAN><SPAN class="">Point</SPAN><SPAN class="">(</SPAN><SPAN class="">0</SPAN><SPAN class="">,</SPAN><SPAN class=""> </SPAN><SPAN class="">100</SPAN><SPAN class="">,</SPAN><SPAN class=""> </SPAN><SPAN class="">-</SPAN><SPAN class="">1000</SPAN><SPAN class="">)])
</SPAN><SPAN class="">polyline </SPAN><SPAN class="">=</SPAN><SPAN class=""> arcpy</SPAN><SPAN class="">.</SPAN><SPAN class="">Polyline</SPAN><SPAN class="">(</SPAN><SPAN class="">array</SPAN><SPAN class="">,</SPAN><SPAN class=""> has_z</SPAN><SPAN class="">=</SPAN><SPAN class="">True</SPAN><SPAN class="">)</SPAN>

I get an error, saying that has_z property is Read-only. From the arcpy.Polyline official docs, this is an optional input parameter, and lke so, the user should be able to set it (to True or False).

However, if I set has_z parameter via python positional parameters rather than named parameter, it works:

<SPAN class=""></SPAN><SPAN class=""></SPAN><CODE><SPAN class="">polyline </SPAN><SPAN class="">=</SPAN><SPAN class=""> arcpy</SPAN><SPAN class="">.</SPAN><SPAN class="">Polyline</SPAN><SPAN class="">(</SPAN><SPAN class="">array</SPAN><SPAN class="">,</SPAN><SPAN class=""> None, </SPAN><SPAN class=""></SPAN><SPAN class="">True</SPAN><SPAN class="">)
</SPAN>

Another problem with 3d Polylines in general, is that their Shape_Length is always 0 for vertical lines (i.e. with equal first and lastPoint).
Also, length is probably calculated regardless the Z coordinate, resulting in strange lengths values.

Encontre mais publicações marcadas com

Accepted answers

JoshuaBixby

In terms of creating your Polyline, definitely a bug. Esri's geoprocessing tools have always had gremlins when it comes to working with Python named arguments. The gremlins get less as users keep reporting them to Esri, so I encourage you to open a case with Esri Support.

The behavior you are seeing with Z values and length is expected. On the surface (no pun intended), most people assume Z equates to elevation/height/depth. Although Z can store elevation, it was designed to store a value that could be something else as well. From Feature class basics—ArcGIS Help | ArcGIS Desktop :

Vertical measurements using z-values
Feature coordinates can include x,y and x,y,z vertices. Z-values are most commonly used to represent elevations, but they can represent other measurements such as annual rainfall or air quality.

The X,Y values are required to be coordinates, but the software doesn't know whether the Z value is storing elevation, annual rainfall, or air quality information. The tools in What is the ArcGIS 3D Analyst extension?—Help | ArcGIS Desktop are designed to work with Z values under the assumption those values represent elevation in some form. For feature classes, run Add Z Information—Help | ArcGIS Desktop to add a "LENGTH_3D" field. For ArcPy Polyline—Help | ArcGIS Desktop, use Polyline.length3D.

The idea that Z values can represent something other than elevation and that spatial operations ignore Z and M values by default isn't just an Esri thing. The OpenGIS Simple Feature Access standard reflects the same view:

The z coordinate of a point is typically, but not necessarily, represents altitude or elevation.

and

... it is possible to store and obtain z (and m) coordinate values but they are ignored in all other operations which are based on map geometries. Implementations are free to include true 3D geometric operations, but should be consistent with ISO 19107.

Any spatial product that is OGC Simple Feature Access compliant will behave the same way.

All comments

Arne_Gelfert

Whether bug or mere oversight on my end, this was extremely helpful. Among all the examples of creating features from points, there are no good examples for 3D, not to mention one that shows this syntax. Saved the day!

JoshuaBixby

See Esri Support Contact Support . If you are in the United States, an organization/user contacts Esri Support directly. Outside of the US, an organization/user usually contacts the Esri distributor for that country/area. Another option is to use the "Tell us what you think" link at the very bottom of each documentation page. Although you won't necessarily hear back directly from Esri, nor have the ability to track progress on any resolution, the Product Leads do get the feedback.

AlessandroValra

That makes perfect sense, thank you for clarifying this!

The gremlins get less as users keep reporting them to Esri, so I encourage you to open a case with Esri Support.

I'd really like to, but how/where am I suppose to report a bug?

I was struggling in the past to find such a place, but never could find one...

JoshuaBixby

Vertical measurements using z-values
Feature coordinates can include x,y and x,y,z vertices. Z-values are most commonly used to represent elevations, but they can represent other measurements such as annual rainfall or air quality.

The z coordinate of a point is typically, but not necessarily, represents altitude or elevation.

and

... it is possible to store and obtain z (and m) coordinate values but they are ignored in all other operations which are based on map geometries. Implementations are free to include true 3D geometric operations, but should be consistent with ISO 19107.

Any spatial product that is OGC Simple Feature Access compliant will behave the same way.

NeilAyres

I have always created geometries with the positional arguments and with a spatial reference.

arcpy<SPAN class="punctuation token">.</SPAN>Polyline<SPAN class="punctuation token">(</SPAN>array<SPAN class="punctuation token">,</SPAN> sr<SPAN class="punctuation token">,</SPAN> <SPAN class="token boolean">True</SPAN><SPAN class="punctuation token">)</SPAN><SPAN class="line-numbers-rows"><SPAN>‍</SPAN></SPAN>

Not sure that the has_z formulation will work, well it doesn't for you.

As regards the length, yes, vertical lines are zero length in plan view. If you want the 3d length you can calculate it or add it.

Participe da Conversa

Membros conectados podem postar, seguir atualizações e mais. Novo aqui? Registre uma conta gratuita.

Links Rápidos

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.