d3 / d3-shape Goto Github PK
View Code? Open in Web Editor NEWGraphical primitives for visualization, such as lines and areas.
Home Page: https://d3js.org/d3-shape
License: ISC License
Graphical primitives for visualization, such as lines and areas.
Home Page: https://d3js.org/d3-shape
License: ISC License
This:
a -= halfPi, this._curve.point(r * Math.cos(a), r * Math.sin(a));
Could be this:
this._curve.point(r * Math.sin(a), r * -Math.cos(a));
I’d like to add Catmull–Rom spline interpolation, in particular the uniform (α = 0), centripetal (α = 0.5) and chordal (α = 1) variants. Note that interpolate("catmull-rom", 0)
would be equivalent to interpolate("cardinal", 0)
, since both result in a uniform Catmull–Rom spline.
See also On the Parameterization of Catmull–Rom Curves by Yuksel et al.
d3-shape examples at bl.ocks.org are blurry
It can be easily fixed by using getRetinaRatio()
from this block: http://bl.ocks.org/devgru/a9428ebd6e11353785f2
// TODO Check if n or m is zero, and avoid NaN.
// n is zero if (x0,y0) and (x1,y1) are coincident.
// m is zero if (x2,y2) and (x3,y3) are coincident.
For consistency with d3/d3-ease@f0ea8b5 (though the ease.ease part was later reverted) and d3/d3-interpolate@70ebb63, curves should also use named parameters rather than binding optional parameters in line.curve and area.curve. Specifically, code like this:
var line = d3.line().curve(d3.curveCardinal, 0.5);
Should be replaced with:
var line = d3.line().curve(d3.curveCardinal.tension(0.5));
Do you have any plan to support line generator of data which is sorted by y-value ?
Just a heads up that the project isn't available in the npm registry.
In cases where an accessor is invoked only once, I think it still needs to propagate the this
context and additional arguments. This is to maximize compatibility with selection methods (such as selection.attr), in case you want to customize the behavior of the generator using, say, parent data or indices. For example, in the arc shape, when we compute the innerRadius and outerRadius, we shouldn’t assume that the only arguments are d and i.
In contrast, if the accessor is evaluated multiple times, then we should apply the convention from d3-arrays and array.forEach, namely d, i and array. So that should be used for line.x, line.y, line.defined, etc.
From d3/d3#2832: if the y-value is NaN, we can still extend the line using the previous x-value. But we’d have to make sure that it’s symmetric for x and y rather than only supporting undefined y. This would be an alternative to using line.defined and area.defined for missing data.
Presumably we’d only want to extend the previous value for a single data point, however? Like if you get two points in a row with NaN y, you’d want to extend a horizontal line from the previous x to the first x with undefined y, but not the second x.
I think it is best suited for this repo given its close relationship with the arc shape.
The pie layout benefits significantly from accessors because the returned objects retain their links to the original data, so you can then bind these objects to the DOM, use them to render arcs, and then access other fields to apply other encodings (e.g., color). This argument applies to any layout.
But what about shapes? Shapes don’t return objects: they render them, either to a 2D context or by returning a path data string. If there’s no returned object, there’s no concept of retaining the association with the input data.
So, should arc, line, area et al. use accessors? It certainly feels more convenient than using array.map. And it’s probably more efficient since you don’t need to materialize the copies (especially now that line and area stream). But in other cases, like the new hull in d3-polygon, it seemed superfluous to retain the x- and y-accessors. After all, we don’t support x- and y-accessors for computing polygon area or centroid, so why do that for the hulls? On the other hand, because of the benefit of retaining association with input data, it is useful to have accessors for computing a Voronoi diagram.
I guess it’d be nice to articulate some guidelines about what things should have accessors, and why.
Seems like it could fit in this repo.
It’s quite likely we actually want to call this a radial link (shape) and put it in the d3-hierarchy module, since this shape is typically used to represent links in hierarchical visualizations.
I just noticed that passing a string to specify a symbol type doesn't work anymore in d3 v4.
import { symbol } from 'd3-shape';
let theSymbol = symbol().type('diamond');
console.log(theSymbol());
Results in the following error:
d3-shape.js?77ca:733 Uncaught TypeError: type.apply(...).draw is not a function
Was this intentional? If so, it'd be great if the docs for v4 stated so. :-)
I can workaround this by passing in the appropriate symbol object from the symbols folder (https://github.com/d3/d3-shape/tree/master/src/symbol)
But having some kind of string mapping like in the old code would be great! (https://github.com/mbostock/d3/blob/master/src/svg/symbol.js)
I love the work you're doing on d3 v4 by the way, I'm finding it really easy to use without selections in a React app I'm building.
Related #49.
Most of the embedded images link to static images rather than live code examples, and the few that are live code examples use the 3.x API. It’d be nice to have some standalone examples of just d3-shape, even if that means making simpler examples that don’t use other D3 features (such as axes and selections).
For example:
As suggested in https://twitter.com/edouard_lopez/status/682140701707010048.
It might be interesting to think about a better default for stack.keys, too. The current default (empty) is safe, but perhaps this usage pattern suggests a different default expectation for the data and keys.
It’s just dividing a range proportionally by value. It happens that the default range is [0, τ], but you could also use the pie generator to compute normalized stacked bars, for example. Related #7.
Steps:
d3_shape.line().curve(d3_shape.basisOpen)([[0,0], [0,10]])
d3-shape.v0.2.js:1024 Uncaught TypeError: Cannot read property 'path' of undefined(…)
(It would also be awesome if there were bl.ocks samples for the images provided in the documentation, it seems quite hard to figure out how to generate them at the moment?)
We don’t currently have a way of passing in a custom interpolator. The problem is the old API uses string concatenation, whereas the new API streams to an output context (which may buffer to a string internally, or not).
Currently we use strict equality on the specified values. This makes sense for constants, but it seems a bit surprising if the x0 and x1 accessor are specified as functions.
Perhaps we should have a more explicit way of specifying when the baseline (x0 or y0) reuses the topline (x1 or x1, respectively) value? Perhaps this is what the value null
should signify?
(Related #23, especially if we auto-promote constants to functions, in which case the same value won’t result in the same function, and we’ll evaluate the function twice; although, since the function returns a constant value, this won’t do any harm.)
Related d3/d3#2385.
For properties that we allow to be defined either as constants or as functions (such as area.y0), we currently maintain the passed-in value for the accessor, even though the code internally always uses a function.
Is it right to do this? Or should we always promote (box) constant values to functions, and then just return the function from the accessor? Taking the later approach is similar to type coercion: we’re effectively coercing a constant value to a function (that returns this constant value). Then area.y0()
would always return a function, even if it was set to a constant.
Certainly we should be consistent (and document whatever we decide to do), but I don’t see that we must preserve the passed-in value. Note that this decision should apply to other D3 modules that provide similar APIs, such as layouts.
Maybe it should be more like transition.ease parameters, where you might say line.interpolate("cardinal", 0.5)
. Note this means that line.interpolate()
should return the interpolation function, then…
This might not be a great fit with the new stream interpolators since it requires knowing the first and last point: it won’t be able to output anything until the line is ended, and so the points must be buffered.
It’s quite likely we actually want to call this a link (shape) and put it in the d3-hierarchy module, since this shape is typically used to represent links in hierarchical visualizations.
The current definition does not propagate the prototype to the factory method, so instanceof d3.curveLinear
and the like do not work.
The current definition obliterates the constructor
property.
I’m not 100% sure this belongs as a curve (or as a data transformation), but it seems like a reasonable place to put it. In theory if you used a smooth curve, the input data array to the line or area generator wouldn’t even need to be sorted by x-value: the smoother could buffer all the points and then compute the smooth curve on lineEnd.
Hi,
I think the main
config of package.json
has a problem. The main used to CommonJS export, and this main is contain the umd package. Than, It is hard to load d3 modules on required which could make the application package smaller.
That is react-router config. It is distinguishing the umd/ lib/ and es6/, and it could be provided three kinds export methods.
So "main": "build/d3-shape.js", "jsnext:main": "index",
to "main": "lib/index", "jsnext:main": "es6/index",
It could be compatibled with normal CommonJS export and es6/es2015 export, and umd file could be exported to npmcdn or other cdn.
Shape loop all the data. Can it provide an API that specifying a range? ex:
area(data, 5000, 6000);
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.