Why do linestrings auto-convert to multilinestrings w/ 0 z elevation?

[JOHNDONALDSON]

I'm using the ArcGIS Online REST API to add/delete features from a 3D web layer.
I'm able to POST linestrings to the layer.

But, seemingly randomly, some (not all) of the linestrings get converted to multilinestrings. And when they do get converted, there are less points and their z elevation values are set to 0 ?!
(when they're not converted, the z values are fine and map well to a local Scene)

I know they're converted because after I POST the linestrings, I download the layer data and review.

Here is a sample POST (the original linestring has 20 points):

{
"geometry": {
"hasZ": true,
"hasM": false,
"paths": [
[
[
-122.18396,
37.7475538,
84
],
[
-122.183954,
37.7475596,
84.1
],
[
-122.183955,
37.7475597,
84
],
[
-122.183954,
37.7475596,
84.2
],
[
-122.183955,
37.7475597,
84
],
[
-122.183955,
37.7475597,
84
],
[
-122.183954,
37.7475596,
84.1
],
[
-122.183955,
37.7475597,
84
],
[
-122.183955,
37.7475597,
84
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475597,
84
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475597,
84
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475597,
84
],
[
-122.183949,
37.7475596,
84.3
],
[
-122.183949,
37.7475597,
84
],
[
-122.183978,
37.7475482,
89
]
]
],
"spatialReference": {
"wkid": 4326
}
},
"attributes": {
"id": "07JDD3P00100TV",
"model": "Phantom 4",
"Detectiontime": "2019-08-08T17:27:17Z"
}
}

and then here it is converted to a multilinestring (only 11 points?) w/ 0 as the z values:

{
"type": "Feature",
"id": 1,
"geometry": {
"type": "MultiLineString",
"coordinates": [
[
[
-122.183957302425,
37.7475564076597,
0
],
[
-122.183949241999,
37.7475596040345,
0
],
[
-122.183948999999,
37.7475596000012,
0
],
[
-122.183948999999,
37.7475596999999,
0
],
[
-122.183949241999,
37.7475596040345,
0
],
[
-122.183955000002,
37.7475596999999,
0
],
[
-122.183954000001,
37.7475596000012,
0
],
[
-122.183957302425,
37.7475564076597,
0
]
],
[
[
-122.183960000004,
37.7475538000011,
0
],
[
-122.183957302425,
37.7475564076597,
0
],
[
-122.183978000004,
37.7475482000014,
0
]
]
]
},
"properties": {
"OBJECTID": 1,
"id": "07JDD3P00100TV",
"model": "Phantom 4",
"Detectiontime": "Thu, 08 Aug 2019 17:27:17 GMT",
"GlobalID": "e7a29f56-90a5-484d-be77-3aef40dc9a7d"
}
},

The original layer was created in ArcGIS Pro. There's a setting just before you share it as a web layer to set the default z value. Curiously the same points that get set to 0 will get set to 99 if I set this to 99.

[AdamEversole1]

Hi John, 

Thank you for calling into support about this issue I was glad to take your call.  I wanted to recap here for geonet some of our findings. 

In summary: We found the line is altered when its submitted to ArcGIS online because it is not meeting OGC standards for geometry. 

Quick Documentation notes:

The apply Edits Documentation for the Rest API states "Any geometry edits made to the service are validated with OGC standards."

OGC Standards can be found here- OGC Standards | OGC 

Here is how to use Esri software to determine the validity to the string presented in Json. 

A)  Use Json to Feature to bring the Data into ArcGIS Pro. 

- Note the above format needed to be converted into GeoJson, We can use the Feature to Json to output a example of valid GeoJson file. 

Here is the linestring rendered in ArcGIS Pro. ( Feature vertices to points also indicates the vertex ordering)

B) ArcGIS Pro, passing the feature layer to the Check Geometry tool using the OGC methodology, We find a Short Segments as an indicated problem.

Because ArcGIS Online would want to validate this with OGC this feature would be considered invalid. Thus we would want to check our geometry, preferably with the Check Geometry tool, to ensure it is clean of errors before submitting it to ArcGIS Online. Additionally providing XY measurements with additional precision would help to minimize running into geometry errors. 

The resulting multistring we see in ArcGIS Online looks to be the result of the OGC validation cleaning up the errors. however the dropped z values is unexpected, a support defect was logged to address this.

For any customers also running into this issue, please feel free to contact Esri Technical Support if you would like to have your account attached to bug record that was submitted. Ref BUG-000125529

Regards

- Adam E

Esri Technical Support.

[JohnDonaldson2]

This is an excellent response Adam. Thank you.
I'd close the issue but I can't login to that particular account anymore!