Segments that intersect the replay group's extent are drawn. Any segment that represents a change in coordinate-extent relationship is drawn. This maintains the left/right relationship (or cross product) between points in the rendered extent and every rendered segment.
Still left undone: clip the replay group's rendering to the max extent.
This works at resolutions where simplification is significantly reducing the number of points in the line. At high resolutions, navigation becomes unresponsive. Limiting draw instructions to a replay group's extent will fix this.
Fix test failures on Chrome 33. The trig functions in V8 have changed, and are may change again (see https://code.google.com/p/v8/issues/detail?id=3006 for the full story). As a result, we no longer rely on Vincenty for antipodal distance calculations (not recommended anyway), and we use a very low precision match for testing cosine distance on a sphere.
The context is at the bottom of the object stack. All entry
points to parsing (#readGeometryFromNode(),
#readFeaturesFromNode()) set up the context now, and parsers
always access the context at index 0 of the objectStack.
Chris Veness' discussion of using the spherical law of cosines (http://www.movable-type.co.uk/scripts/latlong.html) suggests it gives well-conditioned results "around 1 metre" in JavaScript (this assumes a sphere with 6,371km radius).
In Chrome 33, Math.pow(Math.cos(Math.PI / 4), 2) yields 0.4999999999999999. When we take the arccosine of twice this, we get something significantly different than zero. Multiplying by 6371 means we can't assert that this is within 1e-9 of zero.
The Vincenty formula can fail to converge for antipodal points (see http://en.wikipedia.org/wiki/Vincenty's_formulae#Nearly_antipodal_points), so those test cases are removed. These tests fail with the latest V8 due to optimization of trig functions with lookup tables. For example, Math.cos(Math.PI / 2) is no longer calculated based on the value of Math.PI / 2 (which is different than the actual value of π / 2). Instead, values close to multiples of π / 2 are determined to be 0 (which is arguably what you want). Previously the tests were relying on very small numbers being returned in this case.
