Matthew Amato –
For that many static points, you would have better luck using PointPrimitiveCollection directly. It doesn’t have all of the features of using the Entity API, but there is a lot less overhead. We want to support these use cases at the Entity/DataSource layer in the future (and will definitely support them in 3D Tiles), but it will require some significant refactoring.
Matthew Amato –
Re: [cesium-dev] Re: KML big File size not working..
Sorry for taking a while to reply, but the answer here is a bit complicated and nuanced and I wanted to make sure I provided everyone with a good explanation.
The truth is, that the size of a KML is not a good metric for whether or not Cesium will be able to load the data, it’s what is in the KML that matters. Also keep in mind, that the size of a KML file means something very different than the size of a KMZ file. Since KMZ files are compressed and XML is so repetitive/compressible, a 1 meg KMZ file could easily be 20 megs of KML once decompressed. You can see this yourself by renaming .kmz to .zip and unzipping it.
For a real world example, Michael posted a 3.5 megabyte KMZ file that once decompressed is actually 59 megabytes of KML (which is about 1.3 million lines) containing around 154,000 placemarks. Cesium currently runs out of memory while trying to process this data.
So what does affect Cesium’s ability to load a KML/KMZ file? There are several things.
Most importantly right now is probably the number of placemarks. This is partially due to inefficiencies in Cesium and partially due to the nature of browsers (which I’ll discuss more of in a minute). For example, I’ve loaded KML files as large as 70 megs but with only ~20,000 highly detailed polygons total. Cesium can actually load this data without a problem (but it does take a few minutes). This is from my memory, I’ll see if I can dig up an actual file for better comparison.
The type of placemarks have an effect as well. For example, Polygons probably take longer to load, but you can load a lot more of them compared to Point geometry. You could probably get away with 30,000 polygons but you might choke on 30,000 markers.
Another important thing to keep in mind is that there are a lot of crazy KML files out there than go out of their way to try and express data in a way Google Earth can understand. For example, Michael’s 60 megs of KML appear to create a simple outline of a tunnel. Cesium’s PolylineVolume can probably do the same thing instantaneously in a couple of lines of code. Since Google Earth doesn’t support polyline volumes, whomever created that KML file had no choice by to shoehorn the data into Google Earth in a way it could understand. (And even Google Earth starts to chug with that particular file) This is an important point to make, just because Cesium may have problems with the KML doesn’t mean Cesium can’t easily perform the same visualization that the KML represents. It may just require a different (and usually simpler) approach. Obviously this doesn’t help people with a library of KML files that they didn’t create themselves, but it’s still an important distinction.
My overall point is that there is no simple answer to “can Cesium handle this KML file?”
As an aside, I strongly recommend anyone who can to use 64-bit Chrome, it will give you the best performance and allow the most memory usage of any of the browsers (as far as I am aware). A lot of people are using 32-bit Chrome and selling themselves short.
Hopefully, that will answer any and all questions people have about KML loading performance, if not, please let me know and I’ll try to clarify further. Thanks.