This adds a parser (read/write) for GML v2 and v3. GML v3 is limited to the
simple features profile of GML 3.1.1, just like OpenLayers 2 was. This will
be the basis for the WFS parser, but it only makes sense to continue this work
once feature modification (insert, update, delete) is in place in ol3. So the
WFS parser will be another pull request.
Without this we get the following warning from the compiler:
JSC_EXPORTED_FUNCTION_UNKNOWN_RETURN_TYPE. Unable to determine return type for exported function ol.control.Control.prototype.handleMapPostrender at ../src/ol/control/control.js line 79 : 51
I'm not sure why explicitely specifying the return type is required here.
If we use ol.control.Control.prototype.handleMapPostrender = goog.nullFunction the API doc doesn't show the mapEvent parameter of the handleMapPostRender function.
Now that we correctly export the ol.animation.*, ol.easing.* and ol.coordinate.* symbols we can make the generate-exports.py script work for more cases.
This .exports file made goog.require be exported as a null function. This was needed to be able to run the ol3 examples uncompiled against the ol.js build. Now that host-examples target removes the goog.require statements from the examples' js files (74b8fea6) we don't need to export goog.require anymore.
This also involves some modifications to the xmleql functionality now that
it was tested with a real-life case (KML). Also, some of the input KML files
needed to be changed since we currently cannot roundtrip 100% of the input.
As suggested by @tschaub in #674, geom.pointInPoly is not needed
if we have geom.LinearRing#containsCoordinate. This pull request
also adds tests and documentation on the limitations of the
containsCoordinate method.
I think for now it is ok to keep geometry/topology functions as
simple as possible in ol3. If we decide to not rely on third
party libraries like jsts for topology operations, we can always
refine what we have and e.g. port topology operations over from
ol2.
