Another polyline precision issue?

[mramato]

As seen on the forum. Our new duplicate removal changes in 1.5 are causing CZML files that used to work in 1.4 to now crash in 1.5.

@bagnell is this new behavior "correct" or are the tolerances still wrong in some places? If the behavior is correct, I should probably handle this somewhere in the entity pipeline to avoid throwing the exception; since we have a similar problem for KML.

Here's the CZML snippet that was provided.

[
  {
    "id": "document",
    "version": "1.0"
  },
  {
    "polyline": {
      "positions": {
        "cartographicDegrees": [
          -87.719606109668,
          43.759647034233,
          0,
          -87.71960610967,
          43.759647034233,
          0,
          -87.719606109669,
          43.759647034233,
          0
        ]
      }
    }
  }
]

Here's the same file, but with values pre-converted to Cartesian.

[
  {
    "id": "document",
    "version": "1.0"
  },
  {
    "polyline": {
      "positions": {
        "cartesian": [
            183589.97538701253,
            -4610333.314044575,
            4388842.362350027,

            183589.97538685286,
            -4610333.314044581,
            4388842.362350028,

            183589.9753869327,
            -4610333.314044578,
            4388842.362350027
        ]
      }
    }
  }
]

[GatorScott]

A couple of issues are exposed here.

First, removeDuplicates has created the condition (1 point left), so the item should simply not be drawn.

Second, we should probably be as tolerant of "bad" data as possible. We could emit a GeometryError (or similar) exception in this case and let the application developer decide what to do. Alternatively, we could silently ignore the item.

[pjcozzi]

@GatorScott and I talked a bit offline, and perhaps our exceptions are not, well, exceptional enough in cases like this. For example, when the user gets data from the server and provides it to Cesium, is it really a DeveloperError if the points are too close together, if a polyline has only one point, or if a polygon has only two points. Certainty in this case where Cesium is the one to strip it down to one point, I don't think we should throw.

[mramato]

Fix in above pull.

[angelwithaneye]

@GatorScott @mramato Hey guys; I wanted to ask will this allow points in the line to be drawn? We have segments of polylines that are close and we are getting this error. Example (in web mercator although we are converting to geographic before pushing to cesium):
Point_0 -998.235016360454 998.688453477717
Point_1 -997.075348391704 998.688453477717

I really appreciate your assistance. If not, what can we do to get these rendering? It is so essential for us...

To be clear, we don't have these latest pulls but are receiving this error:

TypeError: Cannot read property 'x' of undefined
TypeError: Cannot read property 'x' of undefined
at Function.o.subtract (http://localhost:51351/web/cesium/Cesium/Workers/createGeometry.js:58:6028)
at Object.C.computePositions (http://localhost:51351/web/cesium/Cesium/Workers/createPolylineVolumeGeometry.js:229:23933)
at Function.x.createGeometry (http://localhost:51351/web/cesium/Cesium/Workers/createPolylineVolumeGeometry.js:229:28507)
at n (http://localhost:51351/web/cesium/Cesium/Workers/createPolylineVolumeGeometry.js:229:28759)
at o (http://localhost:51351/web/cesium/Cesium/Workers/createGeometry.js:61:14717)
at DedicatedWorkerGlobalScope. (http://localhost:51351/web/cesium/Cesium/Workers/createGeometry.js:61:14018)

It seems like your fix will return undefined, however we need it to be drawn...

Thanks!

[mramato]

That doesn't look like the same issue as above, and you are also using a polyline volume, which is totally different than regular lines. Please update to the latest official Cesium version (1.5 as of this writing) and if the problem still persists, post about it on the forum, preferably with a small complete example to reproduce the issue. Please don't continue to comment on this issue, as it's closed and most likely unrelated.