I have a KML file containing wind vectors represented as LineString. I notice that it takes a lot of memory and a long time to render these vectors using Cesium comparing to using Google Earth plugin. The rendering quality of the vectors in Cesium is also not as good as GE. If I overlay the vectors on top of an image (using GroundOverlay in KML), it looks fine when displaying the globe in 3D. If I switch to the 2D view, the vectors got under the image layer and I can’t make it appear on top of the image.
I did some benchmarking using Safari, Chrome, and Firefox on my MacBook, the results are similar. For a KML file containing about 38,800 vectors, it takes about 1.3GB memory to render the file in Firefox using Cesium and only 0.06 GB using GE plugin. It took 15+ seconds to get the vectors displayed using Cesium and less than a second in GE plugin. Is there a way to improve the performance? Is the time mostly spent in parsing the KML files? If I use other representation for the vectors, such as GeoJSon, will that improve the memory usage and speed?
Thanks for your help!
Peggy Li
The KML code hasn’t been optimized yet, so I’m sure there are plenty of things we can do to make it faster. Can you share the file with us? It’s hard to know what the problem is without being able to run it ourselves.
Matt, thank you for the prompt reply. Enclosed is the file. We have a test website, but since it is still under development, it is better for me to send you the URL in a private message.
peggy
VECTOR-NORAIN-DAILY_RAPIDSCAT_999_201501210000_201501212359.kmz (1010 KB)
Thanks for the sample file. I can reproduce what you describe and will certainly use this file to help optimize both our KML and geometry implementations. I already found a few spots that should shave a couple of seconds off.
The 2D overlay issue is a known problem and will be fixed in the near term (maybe even the next release).
I noticed that you are creating 3 linestrings per data point in order to form an arrow. This is very inefficient. If you have the ability to change the code generating this data, then the best possible thing you could do in the short term is use the built in support for arrow lines in Cesium, for example, choose it in the Polyline combo box on this demo: http://cesiumjs.org/Cesium/Apps/Sandcastle/index.html?src=Materials.html&label=Showcases Your file would then only include one line per data point, which should be a tremendous improvement on load and also reduce your file size significantly. If you’re interested in trying this out, let me know and I can provide some sample code for you to run after the KMZ loads, replacing the white lines with arrow lines. Obviously this approach is only possible if you can generate KML differently than what you are doing now.
All other things being the same, I don’t think GeoJSON will provide any improvement over KML, but I could be wrong (since GeoJSON has been optimized already and KML hasn’t).
Matt, thank you so much for your suggestions! Yes, I know it is very inefficient to draw an arrow the way I did. I generated the KML file and I can change the code and I will try your suggestion. Please send me the sample code.
Peggy
Matt, I implemented the vectors using Cesium’s polylineArrow Material and it ran much much faster and the arrows look really nice. However, I have a problem. I can only see the arrows when I zoom in to very close to the earth. If I zoom out, I only see the arrow heads. Is there a way to scale the size of the arrow head? In my KML approach, I set the length of the arrow head to be 30% of the length of the arrows, therefore I can always see the arrows regardless my viewpoint. Another question is whether it is possible to tile the vectors so that I will see fewer arrows when I zoom out and more arrows when I get closer?
Thanks,
peggy
PS: Here is a sample page with the wind arrows http://mwsci.jpl.nasa.gov/cesium-kml/rapidscat/arrowTest2.html
Hi Peggy, sorry for not getting back to you earlier. The only way to control the arrow head right now is by setting the width of the polyline. So a width of 30, for instances, means the arrowhead will always be 30 pixels big no matter the zoom level. If that’s not what you’re seeing, let us know.
Hi Peggy,Have you ever considered using dynamic particles to express the wind?,Similar to the following effect:earth.nullschool.net
在 2015年3月4日星期三 UTC+8上午1:53:33，Peggy Li写道：