3D Line (Vertical in Z-axis) is rejected in a FeatureLayer when applyingEdits()

[ChristopheSuter]

3D Line (Vertical in Z-axis) is rejected by FeatureLayer (with local data) when applyingEdits, as well as polygons which nodes share a vertical plane. Anyone knows about a workaround for this ? 

[JonathanDawe_BAS]

There’s a bit of information on this here. I think this is a bit of can of worms in terms of support because many core iso and ogc standards explicitly do not allow polylines or polygons to have points with same xy location and different z values. Esri has its own data model and definitely does allow data like this in some situations ( maybe in the pro client and maybe for some services?) 

Some of what you are describing is the reason why the multipatch data model was added. https://content.esri.com/support/whitepapers/ao_/j9749_multipatch_geometry_type.pdf

I’m interested to see if you can get this working!

[ChristopheSuter]

In fact there a 2 types of errors, for polylines geometry is perfectly stored in the FeatureLayer, it seems it is its rendering in 3d Scene that throws [esri.views.3d.layers.graphics.Graphics3DCore] Graphic in layer ... has no geometry and will not render. But the feature is perfectly visible in a 2d MapView. For polygons it just does not save the geometry if its points share the same vertical plane

[JonathanDawe_BAS]

The polygon vs polyline difference in behaviour makes sense to me... a vertical polyline is definitely something that will occur in utility networks (e.g. for supply into vertical structures). What is your use case for vertically oriented polygon? 

[ChristopheSuter]

Walls, doors, windows. I really do not understand the idea behind invalidating that kind of geometries since it is supported in graphicLayers ..

[JonathanDawe_BAS]

vertical planes feels like its stepping outside the realms of geospatial into 3D meshes. I've always pictured these layers as a 2.5D representation of the world. The geospatial data models haven't been designed to to capture full fidelity 3D data.

For example coincident points for polygons probably breaks all sorts of the 2D validation rules, such as the screw rule:

•  Exterior Rings (Outer Boundaries):

  When defining a polygon's outer boundary, the vertices should be listed in a clockwise direction. This indicates the area inside the polygon.
• Interior Rings (Holes):

  If a polygon has a hole, the vertices of the hole should be listed in a counter-clockwise direction. This indicates the area outside the hole but still inside the polygon.
  

Fundamentally I think the only way to achieve what you are describing is with rendering options such as extruding a polyline to a certain height within the 3D view of the data.