[
-32768, 0, 1,
13, 6, 7,
8, 9
]
and the theshold is [0,1,2,3,4,5,6,7,8,9,10,11,12,13,14]
while the output polygons contains value 10/11/12.
the length of the output polygons which value is 10/11/12 is the same as the length of polygons which value is 9.
Is it a bug? how get the output without 10/11/12?
Hi guys,
We are updating our dependency on d3-contour from 3.0.1 to 4.0.2.
But, it looks like it's not backward compatible starting from 3.0.2.
The breaking change was introduced in PR#57 and published as a patch version (3.0.2)
In our application, we provide thresholds as a callback function which returns an array:
contourDensity().thresholds((densityValues) => someArrayOfThresholds)
Could you suggest, how to make it compatible with the latest version (4.0.2) of d3-contour?
Maybe we need to use some built-in function like thresholdFreedmanDiaconis
, thresholdScott
, thresholdSturges
to make the density chart drawn correctly again?
I have an XY grid, with each cell address mapped to a specific GPS coordinate. After generating contours I see I get polygons with coordinates based on cell positions.
I guess for earth data where pixels are regular and bound by some projection system, I would be able to re-project back to map coordinates, but I can't easily do this with my irregular grid - I think I would need to interpolate every coordinate of the resulting polygon based on closest known real coordinates.
Would it be possible to update the API to allow for specifying coordinates along with a values array that the library then uses to calculate the resulting polygons? (I'm not sure if this makes sense as I don't know how the marching squares algorithm works)
If so, I would be happy to try contribute to this, although I would probably need some guidance!