This removes geometry specific change events. Since geometries are mere observables, we only get generic change events. To minimize changes in other places, as a workaround, we cache geometry bounds on features. This is not the way things should be long term, but the objective is to remove the geometry specific event.
This adds a bit more inconsistency to the library, but we didn't have complete consistency before. Almost all existing string enum values are lowercase (a couple are camelCase and one is dash-separated). The closure library isn't consistent either (with case for enum properties or values). I imagine this could be justified in saying someone could blindly use GeoJSON type values in places, but in the end, you'll need to read the docs before guessing right.
Our geometries are mutable, so they can be modified without
creating garbage by changing coordinates in place and calling
setGeometry afterwards. But this also means that we need to
create a deep clone of the coordinates.
Since we do not use the 'along' property anywhere, and the
resulting array returned by closestOnSegment could cause trouble
when working with 3d coodinates, now only the closest point is
returned, and the squared distance to the segment is calculated
by squaredDistanceToSegment instead.
Previously, the tests were using eql to make assertions about matching geometries. This is inappropriate for structures with circular references (as with goog.events.EventTarget);
In the typical sequence of parse-transform-render the most efficient place to transform coordinate values is deep within the parser immediately after values have been read (this would avoid a second pass over whatever structure is used to back geometries). To accomplish this transform during parsing, we could add back parser read options to pass the transform function around.
Until then, a transform method on geometries is straightforward to implement. This means we do a second pass through coordinate structures to transform, but this is typically done only once immediately after parsing.
Using the y-coordinate of the polygon's bounding box, this
simple algorithm intersects the polygon with the horizontal
center line of its bounding box. The x-coordinate of the label
point is the center of the longest segment of this intersection
that is inside the polygon.
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.
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.
