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.
Tom Payne
ahocevar
Paul Spencer
Tim Schaub