ngageoint / opensphere

OpenSphere
Apache License 2.0
185 stars 90 forks source link

Airspace KML causes OS to become non-usable #421

Open justin-bits opened 5 years ago

justin-bits commented 5 years ago

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.

airspace ge

wallw-teal commented 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.

rkausch commented 5 years ago

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)
wallw-teal commented 5 years ago

84,176 <coordinate> tags with a total of 2,649,511 individual coordinates. Only 425 placemarks are extruded.

schmidtk commented 5 years ago

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.