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.
