Using Entity API with large number of data-points


  I am new to Cesium and I was trying to see how many data-points I can put in the globe without degrading performance. I was able to run fine with few thousand data-points but when I went up to around 60k it started crashing. Based on a post that I saw in stack overflow, people have been able to put 500k data points using the old API. Is there anyway I can get that kind of performance using the Entity API?

  Application I am working on has ~200k data-points. All data points fall into a handful of categories that I plan to distinguish using different coloured points. If I can display all the points and be able to detect mouse-over/click on them I will be good...


Here is the post that I saw:

Here is the code I tried running in the sand box:

var viewer = new Cesium.Viewer('cesiumContainer');

for(var count = 0; count < 60000; count++) {
    var lat = (Math.random() * 360 - 180).toFixed(10) * 1;
    var lng = (Math.random() * 360 - 180).toFixed(10) * 1;
    var entity = viewer.entities.add({
        id : count,
        position: Cesium.Cartesian3.fromDegrees(lat, lng),
        name : 'Entity At ' + count,
        point : {
            color : Cesium.Color.RED,

These links might be of interest. However it’s not in Cesium just yet, and they seem to be primitives not entities.

Actually although it is a primitive, apparently entity.point will use it as well, I didn’t read it carefully the first time through.

Thanks! I will try it out...

There are two levels of problems that cause issues with using the Entity API with large data sets.

  1. The Entity API itself has lots of room for improvement, both in memory usage (which currently gets out of hand with large data sets) and run time performance of static entities (which does more work than needed every frame). Both of these are very solvable issues and some of it can be mitigated today with a small amount of customization. As soon as I can find some time to work on these issues, I will. I’m hoping it’s within the next couple of months.

  2. Limitations of JavaScript and browsers. Because JavaScript (ES5) lacks hash sets and maps, we emulate them in Cesium (There may be a few other browser issues like this in the code, but this is the biggest problem by far). The only way to do so is to have an object whose property names are Entity IDs and whose values are the Entity instances themselves. Chrome seems to crash using this technique when there are a large number of entities (Firefox seems to do okay though). The only real solution to this problem is to rely on the new ES6 Map functionality, which may or may not be performant enough for Cesium’s use cases. The problem with using Map is that it might not be possible to do so without breaking backwards compatibility with the current API. More research is needed to determine what can be done. Even if we fix 1 above, number 2 is a showstopper for large data sets unless ES6 Maps prove to be a workable solution.

You are correct in that using BillboardPrimitive or the new PointPrimitive directly can handle hundreds of thousands of items. But you lose a lot of functionality provided by the Entity API in doing so. There is nothing wrong with taking this route if massive datasets are the most important aspect of your app as long as you are willing to accept that trade off.