[Obsolete] d3.geoPolyhedral() now uses d3-geo-polygon if the plugin is available.

[Fil]

I have been as conservative as possible: d3-geo-projection works as usual without d3-geo-polygon, and checks that it has projection.preclip (d3-geo > 1.8.1).

Examples and issues at d3-geo-polygon

Solves #129
Solves #124
Solves d3/d3-geo#108
Solves #86

Most of the credit goes to @jasondavies @mbostock and @espinielli

[espinielli]

IMHO no credit to me but for watching what you were doing...well done, @Fil ! Super professional.

[mbostock]

test/compare-images should be testing the default configuration of the projections; we shouldn’t change it to use d3.geoClipAntimeridian if the default configuration is to use d3.geoClipPolygon. But it seems that d3.geoClipPolygon isn’t quite ready for use yet because of the equator issue?

[Fil]

Indeed this is to make sure the test runs with the default configuration, which is still to use d3.geoClipAntimeridian.

But when d3-geo-polygon is available[1], d3.geoPolyhedral switches to "experimental" mode and uses it, and that's not what we want to test here. However, as we must to list the optional dependency d3-geo-polygon in d3-geo-projection/package.json (otherwise the code simply doesn't "compile"), when we run the tests the plugin kicks in, and I have to explicitly disable it.

As discussed in #129, we could duplicate geoPolyhedral to d3-geo-polygon and not have to disable clipPolygon when we run the tests. But it would carry a lot of code with it, so not a good idea.

Is d3.geoClipPolygon ready to use? I would say yes: it already allows so many new maps that were simply not possible before. Lee tetrahedron, Dymaxion, etc., run with no issue. Cahill-Keyes has the equator problem too, but it can be solved temporarily by adding a small gamma rotation.

It just happens that one of these cases where d3-geo-polygon gets lost, is when everything is perfectly aligned, ie the default [0,0] aspect of geoPolyhedralWaterman and the like. Frustrating but IMV not blocking. Especially since nothing changes at all (results and API) when d3-geo-polygon is not explicitly added by the user.

[1] My first implementation added a parameter to the polyhedral() function that would explicitely ask for clipPolygon: useless bloat.

[Fil]

If we asked to explicitly set a global flag (in whatever form we want) for when people want to use the experimental feature, the default tests would run without anything specific. Would this be better?

[Fil]

It took me many hours of debugging, and the fix was so tiny. Good that we're not paid by the line.

“This branch cannot be rebased due to conflicts” => I've created a new one at #132