Philippe Rivière

Should we try and do this for d3-geo@2 d3-geo-projection@3 d3-geo-polygon@2 ? I'm really not sure about immutable projections — they would mean rewriting almost all map interactions everywhere; but projection.copy()...

Agree, but I don't have the beginning of an idea how to implement this—projections are a very complex object and there's no easy "deep clone" operation. Maybe I'm missing something?...

it could probably be added—it would slow things down by two substractions—probably not even measurable

That part of the code is particularly difficult. It was copied over from [this commit](https://github.com/d3/d3/commit/d93f45ee82b2274cfbdcdfae81ef4e423e6053b8) in d3v3 and has since been left mostly untouched (except for variable names and formatting)....

If what we want is to clip a geojson with a polygon, this is a geometric operation that should happen on the sphere. It’s not clear to me why this...

Also that particular use case is arguably better served by planar post-clipping _projection_.clipExtent https://observablehq.com/d/c613d80805786986 but of course this currently allows only rectangle extents. It would be cool to allow arbitrary...

See also https://github.com/d3/d3-polygon/issues/4

Would be useful @ https://observablehq.com/@fil/pointer-events-svg

See also https://github.com/d3/d3-chord/issues/13#issuecomment-557300322 & https://pomax.github.io/bezierinfo/#graduatedoffset

inset can be passed before ( `projection.inset(10).fitWidth(…)` ) but could alternatively be an option of fitWidth: `projection.fitWidth(width, object, {inset: 10})` In terms of usability I'd love to have `{type:Sphere}` as...