Contour polygon insideness is reverse.

[Li Dong]

Thanks for creating this great library! It saves me a lot of time!

I have applied it to create contours for precipitation data which is regional not global, and projected the contours onto orthogonal projection, but I found that the polygon insideness of some levels is reverse. In following figure, the left panel is wrong. Any idea why d3 draws this path with its insideness reverse? When not projected, there is no such problem.

...
var contours = d3Contour.contours().size([record.width, record.height])
                                   .smooth(false)
                                   .thresholds(record.colormap.domain)(record.rawData)
                                   // Change planar coordinates to spherical coordinates.
                                   .map(convertCoordinates)

svg.selectAll('path')
   .data(contours)
   .enter().append('path')
   .exit().remove()
svg.selectAll('path')
   .data(contours)
   .attr('d', path)
   .attr('transform', view.transform)
   .attr('fill', (d, i) => record.colormap.range[i])
   .attr('fill-rule', 'evenodd')
        .attr('value', d => d.value)

function convertCoordinates (d) {
  var e = Object.assign({}, d)
  e.coordinates = d.coordinates.map(polygon => {
    return polygon.map(ring => {
      return ring.map(point => {
        return [
          point[0] * record.grid.dlon + record.grid.startLon,
          point[1] * record.grid.dlat + record.grid.startLat
        ]
      })
    })
  })
  return e
}

[Mike Bostock]

I think you probably want to reverse the coordinates of the rings, since the GeoJSON polygons generated by d3-contour are planar, while the polygons you want to pass to the orthographic projection are assumed to be spherical; the assumed coordinate system for planar geometry assumes that y points down, while the assumed coordinate system for spherical geometry assumes that y (latitude) points up.

(It’s also possible that there’s a winding order bug in d3-geo for very small polygons, but that should be unlikely given that the size of the polygons here is determined by the size of the pixel grid, and the marching squares algorithm is guaranteed not to generated degenerate polygons.)

But, you haven’t linked to a live example that reproduces the issue, so it’s impossible for me to investigate. When reporting an issue, please include a link to a live example, preferably on bl.ocks.org or RunKit, or as a pull request in the appropriate repository with new unit tests, that demonstrates that the described behavior is not the expected behavior. Use only the minimum amount of code necessary to reproduce the unexpected behavior.

A good bug report should isolate specific methods that exhibit unexpected behavior and precisely define how expectations were violated. What did you expect the method or methods to do, and how did the observed behavior differ? The more precisely you isolate the issue, the faster I can investigate.

Non-actionable bugs may be temporarily closed until you provide additional information. If you can’t isolate the bug any further, please let me know and I will try to help. However, I beg your patience: I must balance your request against many other responsibilities—fixing other bugs, answering other questions, new features, new documentation, etc. Please also consider asking for help on Stack Overflow.

If you have a question about D3’s behavior and want to discuss it with other users, also consider the d3-js Google Group or joining the d3-js Slack.

Thank you! 🤗

[Li Dong]

Thanks for help! I have encountered difficulties to extract an actionable code snippet, since it involves several data and other codes. It would be great if you can guide me to figure out where is wrong.

I have converted the planar coordinates into spherical ones, so it may not be the problem of coordinates? And when used d3.geoPath(d3.geoIdentity()) path, the wrong level above is correct but with upside down and scale not matched. See the following figure, where for the convenience, I have flipped the right panel in Y direction.

So does it mean it is the problems of projection (geoOrthogonal)?

[Mike Bostock]

Sorry but I cannot investigate further unless you post code that reproduces the issue. I also suggest taking a look at the d3.geoStitch example linked from the README that demonstrates more generally steps that may be required to convert planar to spherical coordinates; it is not simply a matter of scaling and translating.

[Li Dong]

@mbostock I may have found the cause. In the first figure (thank geojson.io), I spotted a polygon with negative area, which means it should be a hole, but it is outside the main polygon (the biggest one). After delete all the hole polygons, the projected contour has correct fill as shown in second figure. Any idea why this lost polygon is generated?

[Mike Bostock]

Sorry but I cannot investigate further unless you post code that reproduces the issue.

[Li Dong]

@mbostock I have created an example to show the problem, but I cannot upload binary data to gist... so I created tar file here. Thanks!

[Li Dong]

I inspected more into the data, and found the data that causes the negative area polygon is as following:

[Li Dong]

@mbostock I think I found a bug in d3-contour:

holes.forEach(function(hole) {
  for (var i = 0, n = polygons.length, polygon; i < n; ++i) {
    if (contains((polygon = polygons[i])[0], hole) !== -1) { // This should be compared with -1!
      polygon.push(hole);
      return;
    }
  }
});

contains function return -1 to indicate not-contain situation, but that if condition pass -1! When add !== -1, the contours are correct.

[Mike Bostock]

Thanks for the test case! I’ve verified your fix in a test and released it as 1.1.1. Here’s a before using your data:

And after:

[Li Dong]

@mbostock I am very happy to contribute my humble efforts. 😛