Matthew,
The nice thing about open source is that we can both pursue different
approaches and in the end, the best approach will win. The Cesium
project's development philosophy is that the best answer from a
technical perspective wins, it doesn't matter who wrote the code. I
have no problem with you continuing down your path, whether you plan
on trying to get it merged into Cesium is up to you. Perhaps we can
even end up sharing some code regardless.
sure, especially non-rendering code like gx:Tour, which manages the
camera and uses the Timeline widget, etc.
Once both approaches have matured, I'm sure we can compare and
contrast the benefits and drawbacks of each. Cesium's goal is to
ultimately support the entire KML spec, as well as the Google standard
gx extensions. So anything going into master will have to show that
an architecture is in place to achieve that goal. We also want to be
able to manipulate and browse the KML tree similar to how the Google
Earth GUI works. You can see the dataSourceBrowser branch for an
early alpha of where we are heading with this.
I'm pretty sure that there is an easy fix for Gabor's concerns. Can
you share a KML file that shows the issue so we can be sure to fix the
bug? I'm pretty sure I know exactly what you're talking about, but I
just want to confirm we are on the same page and I figured getting a
snippet from you would be the easiest way to do that.
let me paste Gabor's description from earlier. also you can use for
example this file: http://www.diamondaviators.net/reports/files/4427?mode=3d
where is how it renders with our implementation using Geometries:
http://openaviationmap.org/reggeli/
here is Gabor's description of the issue from earlier:
It seems that the way KML styles and objects are merged and eventually transformed to dynamic scene objects has an inherent flaw. I'm still learning the code but to my best understanding all collected styles are mixed together to form a new dynamic object even a particular definition is not applicable to a KML geometry. This leads to geometry misinterpretation.
Given the following KML example
<kml xmlns="http://www.opengis.net/kml/2.2">
<Document>
<Style id="flightpath">
<LineStyle><color>7f00ffff</color><width>4</width</LineStyle>
<PolyStyle><color>7f00ff00</color></PolyStyle>
</Style>
<Placemark>
<styleUrl>#flightpath</styleUrl>
<LineString>
<coordinates>...</coordinates>
</LineString>
</Placemark>..
The renderer ends up calculating overlaps and intersections of a polygon consisting of 1500 vertices instead of drawing a simple set of lines just because of existence of .polygon property derived from PolyStyle definition.
I'm working out a fix that applies only certain dynamic properties to the target objet depending on the geometry type of the original KML placemark. Please confirm that I'm going the right direction.