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.
