intersects code suffers due to floating point errors

[crschmidt]

This code breaks:

features = wkt.read("POLYGON((-8239529.462853361 4980952.065110421,-8224242.057199065 4980952.065110421,-8224242.057199065 4988844.188279452,-8239529.462853361 4988844.188279452,-8239529.462853361 4980952.065110421))");
point = new OpenLayers.Geometry.Point(-8225445.94039435, 4982695.78481786);
features.geometry.intersects(point)

19:05:36 < tschaub> yeah, -8224242.057199557 != -8224242.057199065
19:06:00 < tschaub> guess the coordinates aren't big enough in the test cases 
                    to run in to floating point issues
19:06:19 < tschaub> the code is good - the floating point math is bad

[tschaub]

if(cx < Math.min(x1, x2) cx > Math.max(x1, x2)) and the next bit about >= don't leave room matching big numbers. grrr

[tschaub]

limit significant figures in calculating intersections

[tschaub]

So, if you're intersections occur beyond the thirteenth significant figure, watch out! Though we may want a different solution long term, this keeps us safe(r) testing for intersections given geometries whose coordinates have many digits.

Tests pass in FF and IE (what a pleasant surprise).

[pspencer]

looks good to me, changing to commit.

[tschaub]

(In [5673]) Getting explicit about precision. We now support thirteen significant digits in coordinates when testing for geometry intersections. r=pspencer (closes #1245)