Open justin-bits opened 5 years ago
Stats for that KML:
The polygon number sticks out a bit but from the image it appears that each of them are fairly simple, so the overall vertex count probably isn't too bad. The biggest thing that jumps out is that each item has a ton of Javascript in its description markup (which also appears to be unnecessarily repeated rather than using a single BalloonStyle). This is likely burning a hole in the CPU with our XSS protection logic.
Edit: Loading the file without descriptions isn't that much different. It is definitely the polygon count and the complexity of the polygons.
for what it's worth, some of the linear rings are not complete.... I don't have the information describing which ring is incomplete.
ERROR:18:11:11.845 [Envoy[KMLEnvoy]-1] (io.opensphere.core.data.DefaultQueryTracker:376) - Query failed: java.lang.IllegalArgumentException: Points of LinearRing do not form a closed linestring
java.lang.IllegalArgumentException: Points of LinearRing do not form a closed linestring
at com.vividsolutions.jts.geom.LinearRing.validateConstruction(LinearRing.java:111)
at com.vividsolutions.jts.geom.LinearRing.<init>(LinearRing.java:106)
at io.opensphere.kml.envoy.KMLParserPool$Parser.convertToJTSLinearRing(KMLParserPool.java:337)
at io.opensphere.kml.envoy.KMLParserPool$Parser.convertToJTS(KMLParserPool.java:295)
at io.opensphere.kml.envoy.KMLParserPool$Parser.normalize(KMLParserPool.java:252)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:232)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:209)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:209)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:209)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:209)
at io.opensphere.kml.envoy.KMLParserPool$Parser.replaceGeometries(KMLParserPool.java:188)
at io.opensphere.kml.envoy.KMLParserPool$Parser.unmarshalKml(KMLParserPool.java:166)
at io.opensphere.kml.envoy.KMLParserPool.process(KMLParserPool.java:75)
at io.opensphere.kml.envoy.KMLProcessor.parseKMLInputStream(KMLProcessor.java:194)
at io.opensphere.kml.envoy.KMLProcessor.process(KMLProcessor.java:103)
at io.opensphere.kml.envoy.KMLEnvoy.processKMZ(KMLEnvoy.java:568)
at io.opensphere.kml.envoy.KMLEnvoy.process(KMLEnvoy.java:471)
at io.opensphere.kml.envoy.KMLEnvoy.process(KMLEnvoy.java:517)
at io.opensphere.kml.envoy.KMLEnvoy.query(KMLEnvoy.java:174)
at io.opensphere.core.data.CachingDataRegistryDataProvider.lambda$0(CachingDataRegistryDataProvider.java:158)
at io.opensphere.core.data.DefaultQueryTracker$RunnableWrapper.run(DefaultQueryTracker.java:499)
at io.opensphere.core.util.lang.TaskCanceller.lambda$4(TaskCanceller.java:153)
at io.opensphere.core.util.lang.TaskCanceller.lambda$0(TaskCanceller.java:100)
at io.opensphere.core.util.lang.TaskCanceller.lambda$3(TaskCanceller.java:155)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1135)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at io.opensphere.core.util.concurrent.PausingThreadPoolExecutor$WorkerProxy.run(PausingThreadPoolExecutor.java:303)
at java.base/java.lang.Thread.run(Thread.java:844)
at io.opensphere.core.util.lang.NamedThreadFactory$1.run(NamedThreadFactory.java:84)
84,176 <coordinate>
tags with a total of 2,649,511 individual coordinates. Only 425 placemarks are extruded.
One issue with the initial load of that KML is that we do not support ListStyle
, which controls how the KML tree is displayed.
The airspace KML uses checkHideChildren
to limit how much of the tree is displayed in the UI, which also prevents hidden child visibility from bubbling up to the parents. This is why considerably less data is initially displayed when loading the file in Google Earth vs OpenSphere.
Update: I tried a quick fix to disable the nodes impacted by ListStyle
, and Cesium still crashed with the set of features initially displayed in Google Earth. The GPU process was at 100% CPU and ~4GB memory, followed by Cesium's rendering breaking and a lot of console errors.
https://www.faa.gov/nextgen/equipadsb/research/airspace/ https://www.faa.gov/nextgen/equipadsb/research/airspace/media/2020ADS-BAirspaceMap.kmz
This KML loads properly in GE, but causes OS to become nearly non-responsive. Even after OS works through the invalid polygons, it's still not possible to pan the globe around.