I want to divide the nodes in cytoscape graph into several sections in time order, eg. spring summer autumn winter from left to right, using vertical dividing lines. I couldn't find useful information in documentation. https://js.cytoscape.org/
I found some examples on codesandbox: https://codesandbox.io/s/happy-zhukovsky-rouic?file=/src/index.js , where the author use 'parents' to cover nodes of same category. But its position is not by order I think.
Related
I have a graph made in cytoscape.js, using the dagre extension, that looks like this:
Graph
How can I get the parent nodes to line up vertically? Since applying a separate layout to only parent nodes does not work (it applies to all nodes), I am stumped.
Unfortunately they are all poorly maintained visualization algorithms, so they don't have as many features.
I suggest you to open an issue in the algorithm repository where you explain how it can be improved.
In this case you would like to have a better aspect of the visualization.
https://github.com/cytoscape/cytoscape.js-dagre
You can also contribute to the dagre project adding this aesthetic criteria on to the graph.
At the end if you would like to have a better aspect you can apply a tweek to the graph after the layout execution.
So you can think to an algorithm for making parent nodes line up vertically and then apply in the code.
For example something you can do for having nodes nearest to their father and also a good aspect ratio you can sort nodes in the level n + 1 in the barycenter of their father in the lever n.
(let me know if I have made it clear)
I saw from the photo that you have groups, and the nodes within the group have different fathers, so if you put the nodes aligned with their fathers then you could have
Nodes that are overlapping
overlapping groups
groups with too large a width
(let me know if I have made the problem clear)
I remember you how to position nodes in cytoscape.js
cyGraph.startBatch(); // for bach the differences and apply only once at the end
// random layout. you have to use yours
cyGraph.nodes().positions(( node, i ) => {
return {
x: Math.random() * cyGraph.width(),
y: Math.random() * cyGraph.height(),
};
});
cyGraph.endBatch();
I am currently creating a feature and patterning it across a flat plane to get the maximum number of features to fit on the plane. I do this frequently enough to warrant building some sort of marcro for this if possible. The issue that I run into is I still have to manually set the spacing between the parts. I want to be able to create a feature and have it determine "best" fit spacing given an area while avoiding overlaps. I have had very little luck finding any resources describing this. Any information or links to potentially helpful resources on this would be much appreciated!
Thank you.
Before, you start the linear pattern bit:
Select the face2 of that feature2, get the outer most loop2 of edges. You can test for that using loop2.IsOuter.
Now:
if the loop has one edge: that means it's a circle and the spacing must superior to the circle's radius
if the loop has more that one edge, that you need to calculate all the distances between the vertices and assume that the largest distance is the safest spacing.
NOTA: If one of the edges is a spline, then you need a different strategy:
You would need to convert the face into a sketch and finds the coordinates of that spline to calculate the highest distances.
Example: The distance between the edges is lower than the distance between summit of the splines. If the linear pattern has the a vertical direction, then spacing has to be superior to the distance between the summit.
When I say distance, I mean the distance projected on the linear pattern direction.
I have some Kinect data of somebody standing (reasonably) still and performing sets of punches. I am given it in the format of an x,y,z co-ordinate for each joint of which they are 20, so I have 60 data points per frame.
I'm trying to perform a classification task on the punches however I'm having some problems normalising my data. As you can see from the graph there are sections with much higher 'amplitude' than the others, my belief is that this is due to how close that person was to the kinect sensor when the readings were taken. (The graph is actually the first principal coefficient obtained by PCA for each frame, multiple sequences of the same punch are strung together in this graph)
Looking back at the data files it looks like those that are 'out' have a z co-ordinate (depth from sensor) of ~2.7 where as the others tent to hover around 3.3-3.6.
How can I perform a normalization with the depth values to make them closer to each other for each sequence? I've already tried differentiation to get the velocity, although it helps to normalise the output actually ends up too similar and makes it very hard to classify.
Edit: I should mention I am already using a normalization method by subtracting the hip position from each joint in an attempt to make the co-ordinates relative.
The Kinect can output some strange values when the person that is tracked is standing near the edges of the view of the Kinect. I would either completly ignore these data or just replace the data with an average of the previous 2 and next 2.
For example:
1,2,1,12,1,2,3
Replace 12 with (2 + 1 + 1 + 2) / 4 = 1.5
You can basically do this with the whole array of values you have, this way you have a more normalised line/graph.
You can also use the clippedEdges value to determine if one or more joints is outside the view.
I'm having some spatial data that has all of its coordinates as lat/lon pairs (with about 10 digits decimal precision), it's stored in a database as WGS84 data.Some of the data is represented as polygons which are the resulting union of some smaller polygons whose boundaries are stored.Then I'm having a number of points from which I build a linesegments (just 2 points in each segment) which I use later for intersection tests with the polygons.
I'm using a SpatialIndex to improve my queries so I insert the envelopes of all polygons in a tree (tested with both QuadTree and STRtree).Then, I connect two points into a linesegment and I'm using its envelope to query the tree for possible intersections.The problem is that I get pretty much all the polygons as a result which is clearly wrong.. To give you some idea about the real scale of my data, I have about 100 polygons that cover the whole North america, each line covers a very very small part of a single polygon.Ideally, i would expect no more than 2 polygons as a result.
I'm using JTS to do this calculation and I'm aware that it's not really suited for spherical data so can you suggest me another library/tool to achieve the desired behaviour or possible a workaround (for example, projecting before using JTS)?
If you only have north america, just rotate earth by 90 degrees so that Alaska is no longer on the far east. (Fun fact: Alaska is both the most northern, western and eastern state of the U.S.) Then your rectangles should be okay.
There are a number of non-trivial cases though when working with spherical data. Depending on how your data is defined, your polygon borders may actually be bent lines, instead of straight lines. Consider this screenshot of Google Ingress: https://lh4.ggpht.com/S_9jrMqf08JfIbr7DgUDH96rvXMK4wOGtaSKYPGCruXv2HE4oeRuEaQIDIywMgH4198=h900
I read somewhere that the mismatch of the "fog" texture and the green line visible in the left field is due to the two drawing functions using different approximations. One is always a straight line, whereas the other follows the curvature of the earth. If you have a large field (polygon!), the error becomes worse.
"Intersection" becomes a tricky term when your data consists of non-straight lines on the surface of a sphere, unfortunately; and a "straight" line on the surface of earth will often yield an arctan type curve in latlon coordinates.
Projections: these can help, but mostly when your data is local. UTM projections are pretty good, but you need at least 9 UTM zones to cover north america without Alaska. As long as your data is within one UTM zone, projecting the data into this zone and then working with 2D euclidean space should work good. But if it gets lager than this, you may need to stitch different projections, and that is really messy, too.
I want to layer (superimpose) one column graph on another in Excel. So it would be like a stacked column graph, except that each column for a given category on the x-axis would have its origin at 0 on the y-axis. My data are before and after scores. By layering the columns instead of putting them side-by-side, it would be easier to visualize the magnitude and direction of the difference between the two scores. I've seen this done with R, but can't find examples in Excel. Anyone ever attempted this?
I tried the 3D suggestion and it worked. But the other answer I discovered was to choose a Clustered Column graph and click 'Format Data Series' and change the 'overlap' percentage to 100%. I'm using a Mac so it's slightly different, but the person who helped me with this was on a PC and I've used PC's mainly. What I ended up discovering is that using 90% looked quite nice, but 100% will achieve what you're looking for.
I did the same thing for my thesis presentation. It's a little tricky and I made it by myself. To do it, you have to create a 3D bar graph (not a stacked one), in which your columns are put in front of each other. You have to make sure that all the taller columns in each X cell are behind the shorter columns in that cell on the X axis.
Once you created that graph, you can rotate the 3D graph in a way that it looks like a 2D graph (by resetting the axes values to zero). Now you have a bar graph, in which every bar has different columns and all of the columns start at zero. ;)
Short answer: Change the post score to (post - pre), then you can proceed with making the stacked bar chart.
Long and correct answer: DO NOT DO THIS. Clustered bar chart is much better because:
The visual line for comparison is the same line anyway, you're not facilitating the understanding in any means.
Any kind of overlapping of the bars conceals the area of the post-score, which induces visual distortion. A pre-score of 10 and a post score of 20 should have a column area ratio of 1:2. But if you completely overlap them, it'd be reduced to 1:1. Partial overlapping is equally problematic.