We Keep Coding

D3js force simulation with specific targeted destination

I'm trying to render a d3js force simulation but I'd like to ensure my nodes don't relay false information.
With the following code used to display the nodes but due to the dynamic nature of force layouts, it occasionally pushes some nodes out of its appropriate x-coordinate location.
inOrder(){
this.simulation
.force("x", d3.forceX(d => this.xScale(d.value)))
.force("y", d3.forceY(this.height / 2))
.alpha(1).restart();
},
Here is an egregious example of this happening:
The numbers should be in order from left to right.
I made an attempt to use the fx property on a node to lock the position in place:
inOrder(){
this.releases.forEach(x => {
x.fx = this.xScale(x.value)
})
this.simulation
.force("x", d3.forceX(d => this.xScale(d.value)))
.force("y", d3.forceY(this.height / 2))
.alpha(1).restart();
},
This works as intended for preserving the x position but when the inOrder method is called, the nodes instantly jump to their final x position. This ruins the fluid and dynamic nature of the force simulation.
Is there a way to get the best of both worlds? Perhaps by using the .on("end", () => {}) or the .on("tick", () => {})? event handlers?
Mike Bostock (https://stackoverflow.com/users/365814/mbostock) and Shan Carter created some of the work that serves as the inspiration to what I'm trying to do here:
Click between the Changes and Department totals tabs
https://archive.nytimes.com/www.nytimes.com/interactive/2012/02/13/us/politics/2013-budget-proposal-graphic.html?hp
Click betweeen The Overall Picture and the View By Industry tabs
https://archive.nytimes.com/www.nytimes.com/interactive/2013/05/25/sunday-review/corporate-taxes.html

I may be missing something here, but tinkering with the strength of the x positioning force (and the y) can help ensure that your ordering is completed properly. The default strength of forceX or forceY is 0.1, the strength is implemented as follows:
a value of 0.1 indicates that the node should move a tenth of the way from its current x-position to the target x-position with each application. Higher values moves nodes more quickly to the target position, often at the expense of other forces or constraints. A value outside the range [0,1] is not recommended. (docs)
So we could increase the forceX strength, and to allow freer movement of nodes on the x axis we could decrease the forceY - allowing nodes to hop over each other with greater ease - decreasing the collision strength could help too.
I don't label the circle below (instead they are sequentially shaded), but I do run a check to see if they are in order (logs to console on end of simulation), the below snippet modifies only the x and y forces (not the collision force):
var height = 300;
var width = 500;
var data = d3.range(30).map(function(d,i) {
return { size: Math.random()+1, index: i}
});
var svg = d3.select("body")
.append("svg")
.attr("width",width)
.attr("height",height);
var x = d3.scaleLinear()
.domain([1,30])
.range([50,width-50]);
var color = d3.scaleLinear()
.domain([0,29])
.range(["#ccc","#000"])
var simulation = d3.forceSimulation()
.force("x", d3.forceX(d => x(d.index)).strength(0.20))
.force("y", d3.forceY(height / 2).strength(0.05))
.force("collide", d3.forceCollide().radius(d=> d.size*10))
.alpha(1).restart();
var circles = svg.selectAll(null)
.data(data)
.enter()
.append("circle")
.attr("r", function(d) { return d.size * 10; })
.attr("fill", function(d,i) { return color(i); })
simulation.nodes(data)
.on("tick",tick)
.on("end",verify);
function tick() {
circles
.attr("cx", function(d) { return d.x; })
.attr("cy", function(d) { return d.y; })
}
function verify() {
var n = 0;
for(var i = 0; i < data.length - 1; i++) {
if(data[i].x > data[i+1].x) n++;
}
console.log(n + " out of place");
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/5.7.0/d3.min.js"></script>
The snippet places 30 circles in a 500x300 area without much issue: I've tested a handful of times with 0 out of place. Placing 100 circles in here will cause issues: the circles will not be able to change places in such a cramped area: further modification of the forces might be required, but a larger size plot might be preferential (as opposed to a tiny snippet view) too.
Another option would be to modify forces throughout the maturation of the simulation: start with strong x force strength and low collision force strength, then dial up collision slowly so that subsequent jostling is minimized. Here's an example of modifying the forces in the tick function - though, this example is for link length rather than placement on the x - but adaptation shouldn't be too hard.
Yet another possibility would be to keep alpha high until all circles are properly ordered on the x axis and then begin to cool down, again this would have to occur in the tick function.

How is the number of ticks on an axis defined?

I'm new to d3 and have the following code for creating the x-axis on my graph:
export const drawXAxis = (svg, timestamps, chartWidth, chartHeight) => {
console.log(chartWidth); // 885
console.log(timestamps.length); // 310
const xScale = d3.scaleLinear()
.domain([-1, timestamps.length])
.range([0, chartWidth]);
const xBand = d3.scaleBand()
.domain(
d3.range(-1, timestamps.length))
.range([0, chartWidth])
.padding(0.3);
const xAxis = d3.axisBottom()
.scale(xScale)
.tickFormat(function(d) {
const ts = moment.utc(timestamps[d]);
return ts.format('HH') + 'h';
});
const gX = svg.append("g")
.attr("class", "axis x-axis")
.attr("transform", "translate(0," + chartHeight + ")")
.call(xAxis);
return [xScale, xBand, xAxis, gX];
};
As I understand it, d3 decides on the number of ticks that appears on the X-axis.
In order to gain more control over the values appearing on the X-axis for zooming purposes, I would like to understand how d3 determines that - in this case - I have 16 ticks.
What If I want to space the ticks more evenly, for example, I want to see a tick on every 12 or 6 hours? My data contains 0 -> 23 hour values per day consistently, but d3 displays random hours on my graph.

I'm gonna answer just the question in the title ("how is the number of ticks on an axis defined?"), not the one you made at the end ("What If I want to space the ticks more evenly, for example, I want to see a tick on every 12 or 6 hours?"), which is not related and quite simple to fix (and, besides that, it's certainly a duplicate).
Your question demands a detective work. Our journey starts, of course, at d3.axisBottom(). If you look at the source code, you'll see that the number of ticks in the enter selection...
tick = selection.selectAll(".tick").data(values, scale).order()
...depends on values, which is:
var values = tickValues == null ? (scale.ticks ? scale.ticks.apply(scale, tickArguments) : scale.domain()) : tickValues
What this line tells us is that, if tickValues is null (no tickValues used), the code should use scale.ticks for scales that have a ticks method (continuous), our just the scale's domain for ordinal scales.
That leads us to the continuous scales. There, using a linear scale (which is the one you're using), we can see at the source code that scale.ticks returns this:
scale.ticks = function(count) {
var d = domain();
return ticks(d[0], d[d.length - 1], count == null ? 10 : count);
};
However, since ticks is imported from d3.array, we have to go there for seeing how the ticks are calculated. Also, since we didn't pass anything as count, count defaults to 10.
So, finally, we arrive at this:
start = Math.ceil(start / step);
stop = Math.floor(stop / step);
ticks = new Array(n = Math.ceil(stop - start + 1));
while (++i < n) ticks[i] = (start + i) * step;
Or this:
start = Math.floor(start * step);
stop = Math.ceil(stop * step);
ticks = new Array(n = Math.ceil(start - stop + 1));
while (++i < n) ticks[i] = (start - i) / step;
Depending on the value of steps. If you look at the tickIncrement function below, you can see that steps can only be 1, 2, 5 or 10 (and their negatives).
And that's all you need to know the length of the array in the variable ticks above. Depending on the start and stop values (i.e., depending on the domain), sometimes we have more than 10 ticks (16 in your case), sometimes we have less than 10, even if the default count is 10. Have a look here:
const s = d3.scaleLinear();
console.log(s.domain([1,12]).ticks().length);
console.log(s.domain([100,240]).ticks().length);
console.log(s.domain([10,10]).ticks().length);
console.log(s.domain([2,10]).ticks().length);
console.log(s.domain([1,4]).ticks().length);
<script src="https://cdnjs.cloudflare.com/ajax/libs/d3/5.7.0/d3.min.js"></script>
The last example, as you can see, gives us 16 ticks.

How to rotate d3.js nodes around a foci?

I've been using force layout as a sort of physic's engine for board game i'm making, and it's been working pretty well. However, I've been trying to figure out if it is possible to rotate nodes around a specific foci. Consider this codepen. I would like to make the 3 green nodes in the codepen rotate around the foci in a uniform fashion. In the tick() function I do the following:
var k = .1 * e.alpha;
// Push nodes toward their designated focus.
nodes.forEach(function(o, i) {
o.y += (foci[o.id].y - o.y) * k;
o.x += (foci[o.id].x - o.x) * k;
});
In the same way that I push nodes toward a foci, I'd like to make all nodes designated to a foci rotate around said foci. Is there any way to accomplish this by manipulating the o.y and o.x variables within the tick() function? I've tried to manually set the x and y values using this formula however I think possibly the charge and gravity of the force layout are messing it up. Any ideas?
I know i'm using force layout for something it's not quite intended to do, but any help would be appreciated.

I have messed around with your code to get a basic movement around a point.
I changed the foci var to an object which is just two points :
foci = {
x: 300,
y: 100
};
Ive added to the data you have to give each node a start point :
nodes.push({
id: 0,
x:20,
y:30
});
nodes.push({
id: 0,
x:40,
y:60
});
nodes.push({
id: 0,
x:80,
y:10
});
I have added an angle to each node so you can use these independently later:
.attr("cx", function(d) {
d.angle = 0; //added
return d.x;
})
And changed the tick so each node moves around the focal point. As said before I added an angle as these points will move around different circles with different sized radius as they will be different distances from the foci point. If you use one angle then all the nodes will move ontop of each other which is pointless :
Formula for point on a circle :
//c = centre point, r = radius, a = angle
x = cx + r * cos(a)
y = cy + r * sin(a)
Use this in tick :
var radius = 100; //made up radius
node
.attr("cx", function(d) {
if(d.angle>(2*Math.PI)){ restart at full circle
d.angle=0;
}
d.x = foci.x + radius *Math.cos(d.angle) //move x
return d.x;
})
.attr("cy", function(d) {
d.y = foci.y + radius *Math.sin(d.angle) //move y
return d.y;
});
Updated fiddle : https://jsfiddle.net/reko91/yg0rs4xc/7/
This should be simple to implement to change from circle movement to elliptical :))
Looking at this again, this only moves around half way. This is due to the tick function only lasting a couple of seconds. If you click one of the nodes, it will continue around the circle. If you want this to happen continuously, you'll have to set up a timer function so it runs around the circle non stop, but that should be easily implemented.
Instead of tick function just make another function with the timer inside, call it on load and it will run continuously :)

d3.js spreading labels for pie charts

I'm using d3.js - I have a pie chart here. The problem though is when the slices are small - the labels overlap. What is the best way of spreading out the labels.
http://jsfiddle.net/BxLHd/16/
Here is the code for the labels. I am curious - is it possible to mock a 3d pie chart with d3?
//draw labels
valueLabels = label_group.selectAll("text.value").data(filteredData)
valueLabels.enter().append("svg:text")
.attr("class", "value")
.attr("transform", function(d) {
return "translate(" + Math.cos(((d.startAngle+d.endAngle - Math.PI)/2)) * (that.r + that.textOffset) + "," + Math.sin((d.startAngle+d.endAngle - Math.PI)/2) * (that.r + that.textOffset) + ")";
})
.attr("dy", function(d){
if ((d.startAngle+d.endAngle)/2 > Math.PI/2 && (d.startAngle+d.endAngle)/2 < Math.PI*1.5 ) {
return 5;
} else {
return -7;
}
})
.attr("text-anchor", function(d){
if ( (d.startAngle+d.endAngle)/2 < Math.PI ){
return "beginning";
} else {
return "end";
}
}).text(function(d){
//if value is greater than threshold show percentage
if(d.value > threshold){
var percentage = (d.value/that.totalOctets)*100;
return percentage.toFixed(2)+"%";
}
});
valueLabels.transition().duration(this.tweenDuration).attrTween("transform", this.textTween);
valueLabels.exit().remove();

As #The Old County discovered, the previous answer I posted fails in firefox because it relies on the SVG method .getIntersectionList() to find conflicts, and that method hasn't been implemented yet in Firefox.
That just means we have to keep track of label positions and test for conflicts ourselves. With d3, the most efficient way to check for layout conflicts involves using a quadtree data structure to store positions, that way you don't have to check every label for overlap, just those in a similar area of the visualization.
The second part of the code from the previous answer gets replaced with:
/* check whether the default position
overlaps any other labels*/
var conflicts = [];
labelLayout.visit(function(node, x1, y1, x2, y2){
//recurse down the tree, adding any overlapping labels
//to the conflicts array
//node is the node in the quadtree,
//node.point is the value that we added to the tree
//x1,y1,x2,y2 are the bounds of the rectangle that
//this node covers
if ( (x1 > d.r + maxLabelWidth/2)
//left edge of node is to the right of right edge of label
||(x2 < d.l - maxLabelWidth/2)
//right edge of node is to the left of left edge of label
||(y1 > d.b + maxLabelHeight/2)
//top (minY) edge of node is greater than the bottom of label
||(y2 < d.t - maxLabelHeight/2 ) )
//bottom (maxY) edge of node is less than the top of label
return true; //don't bother visiting children or checking this node
var p = node.point;
var v = false, h = false;
if ( p ) { //p is defined, i.e., there is a value stored in this node
h = ( ((p.l > d.l) && (p.l <= d.r))
|| ((p.r > d.l) && (p.r <= d.r))
|| ((p.l < d.l)&&(p.r >=d.r) ) ); //horizontal conflict
v = ( ((p.t > d.t) && (p.t <= d.b))
|| ((p.b > d.t) && (p.b <= d.b))
|| ((p.t < d.t)&&(p.b >=d.b) ) ); //vertical conflict
if (h&&v)
conflicts.push(p); //add to conflict list
}
});
if (conflicts.length) {
console.log(d, " conflicts with ", conflicts);
var rightEdge = d3.max(conflicts, function(d2) {
return d2.r;
});
d.l = rightEdge;
d.x = d.l + bbox.width / 2 + 5;
d.r = d.l + bbox.width + 10;
}
else console.log("no conflicts for ", d);
/* add this label to the quadtree, so it will show up as a conflict
for future labels. */
labelLayout.add( d );
var maxLabelWidth = Math.max(maxLabelWidth, bbox.width+10);
var maxLabelHeight = Math.max(maxLabelHeight, bbox.height+10);
Note that I've changed the parameter names for the edges of the label to l/r/b/t (left/right/bottom/top) to keep everything logical in my mind.
Live fiddle here: http://jsfiddle.net/Qh9X5/1249/
An added benefit of doing it this way is that you can check for conflicts based on the final position of the labels, before actually setting the position. Which means that you can use transitions for moving the labels into position after figuring out the positions for all the labels.

Should be possible to do. How exactly you want to do it will depend on what you want to do with spacing out the labels. There is not, however, a built in way of doing this.
The main problem with the labels is that, in your example, they rely on the same data for positioning that you are using for the slices of your pie chart. If you want them to space out more like excel does (i.e. give them room), you'll have to get creative. The information you have is their starting position, their height, and their width.
A really fun (my definition of fun) way to go about solving this would be to create a stochastic solver for an optimal arrangement of labels. You could do this with an energy-based method. Define an energy function where energy increases based on two criteria: distance from start point and overlap with nearby labels. You can do simple gradient descent based on that energy criteria to find a locally optimal solution with regards to your total energy, which would result in your labels being as close as possible to their original points without a significant amount of overlap, and without pushing more points away from their original points.
How much overlap is tolerable would depend on the energy function you specify, which should be tunable to give a good looking distribution of points. Similarly, how much you're willing to budge on point closeness would depend on the shape of your energy increase function for distance from the original point. (A linear energy increase will result in closer points, but greater outliers. A quadratic or a cubic will have greater average distance, but smaller outliers.)
There might also be an analytical way of solving for the minima, but that would be harder. You could probably develop a heuristic for positioning things, which is probably what excel does, but that would be less fun.

One way to check for conflicts is to use the <svg> element's getIntersectionList() method. That method requires you to pass in an SVGRect object (which is different from a <rect> element!), such as the object returned by a graphical element's .getBBox() method.
With those two methods, you can figure out where a label is within the screen and if it overlaps anything. However, one complication is that the rectangle coordinates passed to getIntersectionList are interpretted within the root SVG's coordinates, while the coordinates returned by getBBox are in the local coordinate system. So you also need the method getCTM() (get cumulative transformation matrix) to convert between the two.
I started with the example from Lars Khottof that #TheOldCounty had posted in a comment, as it already included lines between the arc segments and the labels. I did a little re-organization to put the labels, lines and arc segments in separate <g> elements. That avoids strange overlaps (arcs drawn on top of pointer lines) on update, and it also makes it easy to define which elements we're worried about overlapping -- other labels only, not the pointer lines or arcs -- by passing the parent <g> element as the second parameter to getIntersectionList.
The labels are positioned one at a time using an each function, and they have to be actually positioned (i.e., the attribute set to its final value, no transitions) at the time the position is calculated, so that they are in place when getIntersectionList is called for the next label's default position.
The decision of where to move a label if it overlaps a previous label is a complex one, as #ckersch's answer outlines. I keep it simple and just move it to the right of all the overlapped elements. This could cause a problem at the top of the pie, where labels from the last segments could be moved so that they overlap labels from the first segments, but that's unlikely if the pie chart is sorted by segment size.
Here's the key code:
labels.text(function (d) {
// Set the text *first*, so we can query the size
// of the label with .getBBox()
return d.value;
})
.each(function (d, i) {
// Move all calculations into the each function.
// Position values are stored in the data object
// so can be accessed later when drawing the line
/* calculate the position of the center marker */
var a = (d.startAngle + d.endAngle) / 2 ;
//trig functions adjusted to use the angle relative
//to the "12 o'clock" vector:
d.cx = Math.sin(a) * (that.radius - 75);
d.cy = -Math.cos(a) * (that.radius - 75);
/* calculate the default position for the label,
so that the middle of the label is centered in the arc*/
var bbox = this.getBBox();
//bbox.width and bbox.height will
//describe the size of the label text
var labelRadius = that.radius - 20;
d.x = Math.sin(a) * (labelRadius);
d.sx = d.x - bbox.width / 2 - 2;
d.ox = d.x + bbox.width / 2 + 2;
d.y = -Math.cos(a) * (that.radius - 20);
d.sy = d.oy = d.y + 5;
/* check whether the default position
overlaps any other labels*/
//adjust the bbox according to the default position
//AND the transform in effect
var matrix = this.getCTM();
bbox.x = d.x + matrix.e;
bbox.y = d.y + matrix.f;
var conflicts = this.ownerSVGElement
.getIntersectionList(bbox, this.parentNode);
/* clear conflicts */
if (conflicts.length) {
console.log("Conflict for ", d.data, conflicts);
var maxX = d3.max(conflicts, function(node) {
var bb = node.getBBox();
return bb.x + bb.width;
})
d.x = maxX + 13;
d.sx = d.x - bbox.width / 2 - 2;
d.ox = d.x + bbox.width / 2 + 2;
}
/* position this label, so it will show up as a conflict
for future labels. (Unfortunately, you can't use transitions.) */
d3.select(this)
.attr("x", function (d) {
return d.x;
})
.attr("y", function (d) {
return d.y;
});
});
And here's the working fiddle: http://jsfiddle.net/Qh9X5/1237/

Better way to scale d3 time axis

I'm trying to draw a line using D3.js. They are samples taken at intervals over a period of time. I want to draw them with a time axis for x. Each point of data is just an index in an array and I can't figure out how to set up my axis in such a way that I don't have to manually re-scale the axis before calling d3.time.scale.
Does anyone know how to clean up the scale?
Snippets out of my code. My actual code downloads the data and draws a lot of lines over different time periods with different offsets translated in the graph.
// input data
var start_time = 1352684763;
var end_time = 1352771163;
// data is exactly 100 samples taken between start_time and end_time
var data = [140,141,140,140,139,140,140,140,140,141,139,140,54,0,0,0,0,0,0,0,0,0...]
var y_max = d3.max(data);
// graph
var scale_x = d3.time.scale().domain([start_time, end_time]).range([0, 100]);
var scale_y = d3.scale.linear().domain([0, y_max]).range([height, 0]);
var step = (end_time - start_time)/100;
function re_scale(x) { return start_time + x*step; }
// for x, rescale i (0..99) into a timestamp between start_time and end_time before returning it and letting scale_x scale it to a local position. Awkward.
var line = d3.svg.line()
.x(function(d, i) { return scale_x(re_scale(i)); })
.y(scale_y)
.interpolate('basis')
var g = graph.selectAll("g")
.append('svg:path')
.attr('d', function(d) { return line(data); })
// also draw axis here...

The "domain" should refer to the span in the data, and the "range" should refer to the span on the screen.
At the moment it would be interpreting .range([0, 100]) on scale_x as a number of pixels. If you change this to .range([0, width]) it should work without needing to re-scale.
d3.time.scale() only needs to know the start and end points to produce a good axis. However if you do want a tick for every data point there are options do do this in the docs.