polygonContains make my demo wrong

[sknightq]

Hello D3 Team:
I used OpenLayers and D3 for wind display. It worked great in D3 version3. After D3 version4 publishing, I tried to upgrade from version 3 to version 4. Certainly, I changed the function name like from d3.geo.mercator() to d3.geoMercator() . But failed at the end.
The v3 demo (correct)
The v4 demo (wrong, the center of the area will be wrong when you scroll mouse to zoom map )
I compared much code and found the difference.
v3.5.16 :
return (polarAngle < -ε || polarAngle < ε && d3_geo_areaRingSum < 0) ^ winding & 1;
After v3.5.16 (v3.5.17, v4) :
return (polarAngle < -ε || polarAngle < ε && d3_geo_areaRingSum < -ε) ^ winding & 1;
Could anyone explain the changes, please?
How can I modify my current code if the changes are necessary?
My code snippets :

 var d3Projection = d3.geoMercator().translate([0, 0]);
 var d3Path = d3.geoPath().projection(d3Projection);
 var pixelBounds = d3Path.bounds(features);  // get wong pixel Bounds in D3 V4
 var pixelBoundsWidth = pixelBounds[1][0] - pixelBounds[0][0];
 var pixelBoundsHeight = pixelBounds[1][1] - pixelBounds[0][1];

This is my stackoverflow detail

I will express my sincere thanks to you if you can reply me!

[sknightq]

@Fil
At first, thanks for your quick replying!
I viewed the commit log. But it's different from my mentioned.

d3/d3@eff0a11:
from
return (!southPole && !polar && d3_geo_areaRingSum < 0 || polarAngle < -ε) ^ winding & 1;
to
return (polarAngle < -ε || polarAngle < ε && d3_geo_areaRingSum < 0) ^ winding & 1;

My confusion :
from
return (polarAngle < -ε || polarAngle < ε && d3_geo_areaRingSum < 0) ^ winding & 1;
to
return (polarAngle < -ε || polarAngle < ε && d3_geo_areaRingSum < -ε) ^ winding & 1;

What's more, I want to check the data of my topoJSON(contain polygon data) whether is standard. Do you know some tools that can detect my data or some documents that describe the standard?
my topopJSON

[Fil]

You can test your topojson file with http://mapshaper.org/

You're right, the commit that introduced that epsilon was
d3/d3@dab64a2#diff-9e52f2bedd0fa6315adc31b0688e35e0

The corresponding issue #2025 has sadly disappeared, but there is a related discussion here https://stackoverflow.com/questions/25895676/how-to-stop-d3-js-from-creating-infinite-areas-from-linear-polygons

It would be very useful to create a simple demo of the bug so we can work on it.

[sknightq]

@Fil
The following is my simple demos：
v3.5.16 (correct)
v4.13.0 (incorrect)
You will get an incorrect result when using lib after version 3.5.16, the different code was mentioned above.

[Fil]

There is no test for (disappeared) issue #2025, which means that if you build d3-geo by reverting dab64a2 on https://github.com/d3/d3-geo/blob/master/src/polygonContains.js#L71 , all the unit tests pass. However, this does not seem to be the solution because…

it appears that two small polygons in your dataset are counter-clockwise, which means that they should be drawn as "the whole planet around the polygon", and their geoBounds are (correctly) evaluated as [-180…180].
See https://beta.observablehq.com/@fil/small-triangle-test for details.

However there seems to be a (different) bug that makes d3.geoPath draw them as if they were clockwise. https://beta.observablehq.com/@fil/small-circle-test (filed under #141)

[sknightq]

@Fil Thanks for the bug of details and point out the data with counter-clockwise.
Should I modify the data with counter-clockwise to clockwise or waiting for fixing the bug?