To be honest, this code needs some major refactoring. I'd like to make a function that takes a `Document` and a single data structure that represents the pass output. In a [previous personal project](https://github.com/twpayne/tcx2kmz) I've had good success using a [double-stack approach with an event-driven XML parser](https://github.com/twpayne/tcx2kmz/blob/master/builder.py) where one stack contains the parsers and the second stack contains the object being built. However, JavaScript provides DOM-style XML parser so in this code I tried a different approach. I'm not happy with the result. It works, but there's a lot of code duplication (e.g. it iterates over child nodes in several different places).

I'll take me some time to adapt the double stack / event driven parser approach (which I believe is very flexible) here, but here's a quick outline.

There are two stacks.
The first stack contains the currently active parsers.
The second stack contains the objects being built.
The event-driven approach means that you basically get three events: "enter node", "content", "exit node".
In response to these events you manipulate one, or both, stacks.

Here are some examples of how it would be applied to KML.

The net result of parsing a KML file is an `Array.<ol.Feature>`.
So, when you enter the `kml` tag you push an empty array onto the object stack, and a hash of parsers (keyed by node type) on to the parser stack.
Hitting `Document` or `Folder` KML node pushes stuff onto the parser stack, but not the object stack: you're still adding elements to the `Array` of `ol.Feature`s.
Let's say you hit a `Placemark`. This will become an `ol.Feature`. So, when you enter a `Placemark` you push a new `ol.Feature` object onto the object stack, and a new set of parsers onto the parser stack.
These parsers will (basically) manipulate the `ol.Feature` at the top of the object stack. For example, hitting a `name` element will set the name of the `ol.Feature` at the top of the stack.
When you *exit* the `Placemark` node, you pop the `ol.Feature` off the top of the object stack, and add it to the `Array.<ol.Feature>` which is now at the top of the object stack.
At the end of the parse, you'll exit the `kml` node and return the object at the top of the object stack, i.e. the `Array.<ol.Feature>`.

What's nice about this approach is that it decouples the structure of the result (the `Array.<ol.Feature>`) from the structure of the XML tree, while still preserving modularity. For example, if you need to read a `ol.geom.Geometry`, (simplifying slightly) you push an empty `ol.geom.Geometry` object onto the stack, the relevant parsers onto the parser stack, and when you exit you'll have a completed `ol.geom.Geometry` object on top of the object stack, which you can add to your feature.

Sorry for the short description. I'll write some code to see how it works for ol3.