Fixes#428. This is built on top of existing tick support for linear scales: for
small intervals, a linear scale computes ticks based on milliseconds; for large
intervals, a linear scale computes ticks based on fractional years. This commit
also extends the time scale's formatter to display milliseconds.
There's an edge condition which is not discussed in the original algorithm
("Visualization of Large Hierarchical Data by Circle Packing", Wang et. al):
what happens if the first intersecting circle C_j is equidistant from C_m and
C_n? In other words, it is both after C_n on the front-chain, and before C_m.
The correct answer is that you should splice the smaller of the two circles. If
C_m is smaller than C_n, then splice from C_j to C_n and set C_m to C_j;
otherwise, splice from C_m to C_j, and set C_n to C_j.
Now if you add an "svg" element, we automatically infer the namespace because
there is an "svg" namespace prefix. In conjunction with inheriting the namespace
from the parent element, this means that namespaces are almost optional!
Previously, each listener function had a private _on property which recorded
whether the listener was enabled; this was set to false when the listener was
removed. (This is necessary because of the copy-on-write semantics when the
array of listeners is modified while events are being dispatched.) If the
listener was registered for multiple event types ("foo" and "bar") then removing
the listener for any type would disable it for all types.
The fix is to wrap the listener in an object. This also has better encapsulation
since the state is kept private.
This required changing assert.length to assert.lengthOf in tests, due to
a Vows.js change to be compatible with Node.js v0.6.x. For further
details:
https://github.com/cloudhead/vows/pull/141
Using d3.range with a floating point step is a bit sketchy, because there's a
chance that too many or too few elements could be generated. Instead, we now we
generate an integer range and scale it accordingly.
Due to the ordering in which the prototypes are defined, it was still undefined!
Also, the empty method depends on the node method being defined. Added a test.
It was previously possible for small differences in the reference time for
subtransitions. This could lead to tearing with expensive transitions, as some
transitions would have slightly different reference times than the others. This
is fixed by passing the reference time along explicitly when deriving a new
transition, either by the transition or selection operators.
The d3.time.format.iso is designed to be compatible with the default JSON
serialization of dates, which includes milliseconds. So, d3.time.format now
supports the %L directive for formatting and parsing milliseconds. This commit
also changes d3.time.format.iso to use native ISO date methods, if available.
This simplifies the implementation and fixes a few bugs. The si prefix format
("s") now supports variable precision; in fact, you are strongly recommended to
specify a precision, such as ".3s".
You can now change the orientation and the axis will redraw correctly. When an
axis is applied by a transition, the subtransitions will properly inherit the
transition id, allowing transitions on reselected elements to continue.
d3.geom.polygon(…).area() assumes screen pixel coordinates with (0, 0)
at the top left, and y increasing going downwards. This results in a
positive area for counterclockwise coordinates. Howver, the default
centroid calculation was assuming "usual" Cartesian coordinates with y
increasing going upwards, hence the centroid coordinates were
incorrectly multiplied by -1.
This fix won't affect d3.geo.path(…).centroid() as it passes a constant
to d3.geom.centroid.
This occurs on Linux, where the directory listing order is different
from OS X and so other tests leave data bound to the "body" element.
This data is then propagated when new elements are appended, and thus
mess up some of the tests!
When computing the reversed baseline, we need to switch between step-before and
step-after, since the points are in reverse order. Otherwise, we're effectively
filling the gap between step-before and step-after.
This also tweaks the array conversion slightly so that it is called by
selection.selectAll rather than d3_selectAll; this guarantees that the selection
groups are always arrays, even when a function selector is used.
The greatArc class is the new name for greatCircle, which actually represents
great arcs. Meanwhile, a new greatCircle class is for great circles. The new
greatCircle class replaces the old clip class, providing clipping and resampling
functionality (using greatArc internally). This isn't backwards-compatible, but
I may forgo the major version number bump in light of the fact that greatCircle
was just added, and not used in any (official) examples or documented.
Note that the Werner projection is a special case with standard parallel
at 90°N, and the Sinusoidal projection is also a special case with
standard parallel at 0°N.
This adds support for filtering the log ticks, such that fewer ticks can be
generated to fit in a small space. This can be used in conjunction with a
custom tick format as well. This commit also changes the default log tick format
to be exponential rather than precision, for consistency.
This test makes sure NaN doesn't creep in due to Math.acos being called
on numbers like +/- 1.000000000004, so it's more descriptive to check
isNaN rather than the exact numerical results.
This can be used to process output from d3.geo.clip to ensure clipped
polygons are correctly curved.
The "n" option has been replaced with precision, which denotes the
approximate angular length of great-circle segments. This is much
faster than using a fixed number of segments, particularly when
processing a large number of polygons, only a few of which may have
edges long enough to warrant being converted into a geodesic.
This can be used with d3.geo.path.clip to clip the input coordinates of
geographical shapes using a given origin and angular radius, e.g. for
hemispherical or near-hemispherical views. Geodesics are inserted as
necessary.
This also includes a minor bugfix and test for d3.geo.path: the last
coordinate of Polygon features was being included unnecessarily
(MultiPolygon already handled this correctly).
Rather than have a treshold in transitions, we now clamp the easing functions.
This guarantees that when the transition ends, the tweens will be called with
t=1, and produce clean output values. Previously, that was not the case for
certain easing functions, such as exp-out and elastic.
Higher-order programming! This makes it more akin to d3.svg.chord i.e.
it can take "d" and "i" arguments. Thanks for the suggestion, Mike!
Also made "n" and "radius" configurable, too.
IE9 does not string-coerce values, instead throwing an error. We now wrap IE9's
implementation to force string coercion. While it would be simpler to turn on
string-coercion for all browsers inside D3's style operator, this approach
avoids penalizing standards-compliant browsers.
This commit also moves language-compatibility code to a separate directory, and
deletes the obsolete Object.create polyfill, which is no longer needed by D3.
Fixes#274. String coerce for uniqueness, but store the original input types in
the domain for subsequent retrieval. This way, you can more easily use
non-strings as domain values (such as dates or numbers).
Can be used to generate great circle paths. Similar to R's
geosphere.gcIntermediate (in which I discovered a bug, while writing the
test case for this!)
Includes d3.geo.greatcircle().distance for computing the shortest geo
path distance using the Haversine formula.
For a tutorial on using great circles, see:
http://flowingdata.com/2011/05/11/how-to-map-connections-with-great-circles/
As of 2.0.0, it's possible to have multiple transitions running concurrently
with the same id. Thus, it is no longer sufficient to check the transition id
to decide whether to delete the transition lock. We now use reference counting
to determine the number of transitions that are scheduled on a given element;
when that number drops to zero, we can delete the transition lock.
They weren't being invoked with the correct syntax (being passed the data and
index, with the current node as the context). This commit also removes the
d3_array wrapper, which does not appear to be necessary; I've forgotten why it
was there in the first place.
I'm including the axis component in the core build because it should be useful
in many different visualization types, similar to the other svg components. The
chart module contains a hodgepodge of more obscure visualization types, and
there's no reason to pull those in for more common visualizations. Perhaps most
importantly, the axis component isn't a chart type!