Matthew,
Thank for the thorough answer.
The main reason I'm asking all this is that we're also pursuing KML
support, but frankly, we have found some major issues with your
approach, which Gabor has detailed earlier on this list. currently our
conclusion is that our approach is better, with not using dynamic
objects, but creating geometries for the KML constructs.
basically I'd like to dig down in this topic, and find out why the
dynamic object approach would be beneficial, which you have adopted.
Currently the items that are checked in the roadmap are believed to be
completed and working in Andre's branch. Though those items are still
pending my review. Andre checks them when he thinks he's ready to
have me review them. Any checked item should be working, but we have
separate items for simply processing the geometry versus extruding it.
So LinearRing is checked because we read in the coordinates, not
because all options for it are supported.
I see - this clears up a lot
Unchecked items are planned, but not at all working yet. The line
string is not completely implemented yet, though that is planned.
Some of these features depend on improving our Visualizer system,
which is a big item on the roadmap I'm actively working on now.
I see.
from Gabor, and following this thread, I had the impression that styling
/ coloring has considerable issues, in the sense that it's very
difficult to assign different styles to different geometry types, or
different parts of the same geometry (say, the extruded part of a
LineString or the 'line' part of the LineString). is this so? is this
about to improve?
as stated above, we started to work in your codebase, in the hope that
this would have more momentum, but we've found major obstacles that
basically made us stop.
All features should be thoroughly tested by our unit tests in
Specs/DynamicScene/KmlDataSourceSpec.js.
I see
do you have visual samples as well?
We will certainly flesh out these tests to cover everything before it
comes into master, and any bugs reported will always have a new test
added for it so that we prevent future regression.
good to hear
The styles are not 100% implemented, but will be before this comes
into master. I'm not sure exactly which parts are implemented yet or
not, but extrusion is not one of them.
good to know.
as stated earlier, we're really worried about the styling assignment
design (see Gabor's earlier e-mail)
DynamicScene is no longer a good name for this layer. We will most
likely rename it to DataSource. The general idea is that all data is
processed into a common set of objects, which can then all be treated
the same by an application, regardless of where the data came from.
this sounds like a good idea.
OTOH, I think Geometry and Appearance objects also fit the above
description. I wonder what this additional abstraction layer brings to
the table.
This also allows the visualization system to automatically determine
the best way to render it. If the data is static, then we can use the
Geometry & appearances. If it's dynamic, we use a different rendering
path. It will also allow for data to be written out in different
formats, as well as be used for additional app features other than
visualization. For example, we are working on both a Balloon widget,
similar to Google Earth and a data source browser to show the tree
structure of the KML document. So whether the data is time-dynamic or
not, there are still good reasons for not creating primitives directly
and instead go through the DataSource layer.
I see your point, OTOH, I'm a bit skeptical - this sounds too generic,
and thus of limited value. OTOH, I might be wrong 
However, you are mistaken in thinking that KML is not time-dynamic.
There are plenty of time-dynamic feature in KML, gx:Track and
gx:TimeSpan for example. Here's an example that uses the time-slider
in Google
Earth: https://developers.google.com/kml/documentation/us_states.kml
Also, the NetworkLink and NetworkLinkUpdate features require the kind
of book-keeping that the DynamicScene layer already offers.
I see - these are valid points.
I hope that helps explain our thought process. Like I said, I want to
post this on the issue or the wiki to give people an idea of where we
are heading. It may be too early for you to really make use of what
has been done with KML so far, but I expect a lot to change by the end
of the month, and if all goes well, we can have initial KML support
included in b22 or b23.
good to know.
in the meantime, we're working on gx:Tour now, to have it drive camera
movement in Cesium. Will let you know if we have something that actually
works.
our initial goals are to display an extruded LineString, which we've
done already earlier using Geometry objects, and have a gx:Tour object
'lead' the camera through the same path (it's the same aircraft flight
path, visualized with the LineString, and 're-played' using gx:Tour)
Akos