This commit changes the albersUsa projection so that it uses a custom projection
stream rather than a custom projection function. The projection stream passes
geometry to all three constituent projections, which are then clipped to their
respective viewports. The result is that geometry that appears in multiple
projections (such as a graticule) is now rendered correctly in each, with
clipping! In addition, the inverse projection is much easier to compute because
the viewport regions of each projection are explicitly defined.
This removes the use of interpolateString if the start and end values passed to
d3.interpolate are different types; the interpolation behavior should be based
solely on the end value. Now if you interpolate an undefined attribute (the
empty string) to a number, it will use number interpolation as expected.
This also fixes interpolateString such that it always returns a string, even if
both the start and end value are coercible to numbers.
Fixes#1241. With d3.scale.pow, d3.scale.sqrt and d3.scale.log, the underlying
implementation is a linear scale. Due to the transformation a linear domain and
the limits of floating-point precision, the reported domain could differ
slightly from what was set. Now, the set domain is preserved exactly.
Since tests are now run in their own sandbox, assert.deepEqual was not
properly testing the returned Date objects for equality, as they weren't
instances of the same Date class used by the test itself, causing type
inference to fail. It was always returning true, even for different
dates.
The behaviour of d3.geo.bounds has been modified slightly, such that the
minimum and maximum longitudes denote minimum and maximum meridians when
going from left to right in a standard equirectangular projection.
If the maximum longitude is in fact numerically smaller than the
meridian, this simply means that the bounds cross the antimeridian.
This fixes several issues:
* The bounding box is now a true minimum-width bounding box.
* Line segments that cross the antimeridian are now correctly handled.
* Similarly, polygons that cross the antimeridian are now correctly
handled.
Secondly, inflection points are now detected, so that the latitudinal
range is extended in the case where the great arc contains the great
circle’s inflection point.
Lastly, support for polygons has been improved, e.g. those that wind
around the poles, and those that have a counter-clockwise winding order.
Note that as part of the winding order detection, the performance of
d3.geo.area had to be reduced somewhat (by as much as 25%). This is
because the trick to avoid atan2 calls fails for winding order detection
in the case where a counter-clockwise area strays into a positive
quadrant. We can reinstate the trick for area-only calculations in
future; I think correct winding order detection is more important at the
moment.
See #1154.
This commit fixes d3.select so that it no longer propagates data from the
document element to the selected node when a selector is used. This commit also
fixes d3.select and d3.selectAll such that the returned selection’s group’s
parent node is set to the document element.
In HSL space, grayscale colors can now have undefined hue rather than assuming a
hue of 0°; likewise black and white can have undefined saturation rather than
assuming 0%. In HCL space, black can now have undefined hue and chroma. (For
non-black grayscale colors, including white, hue and chroma are implied by the
D65 standard referent.)
When interpolating between colors with undefined hue, saturation or chroma, the
defined value is used when available. For example, when interpolating from black
to blue in HCL space, the intermediate colors are now dark blues (#241178)
rather than dark purples (#600054).
Fixes#833.
Data-in and data-out. Although I could see it being useful to access the
computed coordinates, but I think in the common case, these will be implemented
as simple accessors.
Since smash.load uses a separate context, any exceptions it throws use a
different Error class, and thus the assert.throws fails. So, instead, just allow
any exception type to be thrown.
This corrects the handling of lines that are long enough to have two
visible or invisible endpoints, but still cross the small circle and
thus have an invisible or visible intermediate segment.
Fixes#1127.
You can now pass a format specifier to scale.tickFormat (for linear, pow and
identity scales). If the format specifier doesn't have a defined precision, the
precision will be set automatically by the scale, returning the appropriate
format. This provides a convenient, declarative way of specifying a format whose
precision will be automatically set by the scale.
This works with axes, too! For example, `axis.ticks(10, "%")` will now use a
percentage format rather than the default format, while still computing the
appropriate precision.
This commit also includes a fix to make d3.format more robust when unreasonable
precisions are specified. Rather than throwing an error, the nearest reasonable
value is used instead.
Fixes#912.
This adds d3.geo.transverseMercator and removes the custom default scales from
the mercator and equirectangular projections. Also, this commit removes the
built-in 2π scale factor from the mercator projection, simplifying the
implementation and making it consistent with transverseMercator and GDAL. This
is a partial fix for #1133; see also d3/d3-plugins#55.
Previous versions of JSDOM erroneously returned null rather than the empty
string, but this has now been fixed. Note: this depends on tmpvar/jsdom#582
which has not yet been merged to master.
The previous implementation of format, which only supported arrays as input, is
retained as d3_dsv.formatRows; for backwards-compatibility, d3_dsv.format allows
both arrays and objects as input (to be removed in 4.0). This change makes
format and formatRows symmetric with parse and parseRows, respectively.
To compute the set of fields from all objects, two passes are required. Fields
are listed in discovery order, so that in the common case where all fields are
defined on all objects, the order of columns in the generated DSV will match the
property iteration order of the first object.
This supersedes #1106 and fixes#509; thank you to @smcgivern and @hammer for
suggesting this feature.