Bring more consistency to the API about d3-geo-projection

[mbostock]

The problem with named parameters is that it’s kind of a pain to implement the raw projections that way. Also, since we already released the raw projections in d3-geo 1.1 and d3 4.1, it’d have to wait until D3 5.0 anyway. So, I think I’m going to close this. Unlike d3-ease and d3-interpolate I don’t intend the raw projections to be used unless you are defining a custom projection, which should be quite rare (as compared to configuring an existing projection).

[mbostock]

There’s a big reason not to define the raw projections as a property of the (non-raw) projection which is that it makes it impossible to import just the raw projection definition: you end up pulling the whole projection pipeline in, including clipping and resampling, which is comparatively huge. Of course in the vast majority of cases this wouldn’t actually matter since you are probably going to need that any if you are working with projections… but still, it’s cleaner if it’s a separate symbol.

As for discoverability, the main thought that comes to mind is using named parameters as we do for d3-ease and d3-interpolate. For example, instead of this:

var bonne = d3.geoBonneRaw(Math.PI / 3);

You’d say this:

var bonne = d3.geoBonneRaw.parallel(Math.PI / 3);

It makes the parameters more discoverable, forces all parameters to have defaults, and eliminates the distinction between parameterizable projections and non-parameterizable projections. Of course it’s still a bit awkward to have the inconsistency between radians and degrees… and the necessary duplicate API in the non-raw projections where some parameters have side-effects like setting a rotation.

[Fil]

+1 for named parameters; also there seems to be some need for a generic function that would help change a parameter (like parallel1).