This makes the asynchronous and synchronous versions of
readFeatures work with the same data structures, and leaves
projection handling outside the parsers.
As demonstrated in the tests, a MultiGeometry may contain other MultiGeometry nodes. We can support this with heterogenous GeometryCollection instances - though these are not currently rendered.
KML and WKT don't specify a winding order, so we write those out in CW/CCW order (for exterior/interior). GML references ISO 19107 that specifies CCW/CW, so we serialize in that winding order.
Having hand generated all this GML data the first time around, I reserve the right to modify it for the tests.
Now that we have FeatureId support (see #733), we can add this back to the
GML parsers (v2 and v3). Also add write support for FeatureId in KML, read
support was already added by @fredj
On servers that report an incorrect content type for XML
documents, responseXML will be empty. In these cases we need to
use responseText instead. This change also prevents readNode
calls with empty data.
XMLHttpRequest in the KML example
Since the content-type on github.io is application/octet-stream we need
to implement an Async string based parser interface in the KML parser.
Also use plain XmlHttpRequest in the example instead of jQuery Ajax since
the vector-features example also uses that.
