I am using go js to draw diagrams by drag and drop , i want to draw a network diagram for that I used GO js and used ForceDirectedLayout , but the problem is my nodes are overlapping on each other but i dont want that. is there any way to dont allow to overlap nodes on each other in ForceDirectedLayout.
It is impossible for ForceDirectedLayout to guarantee that no nodes overlap each other, but in order to decrease the chance of overlaps, you could increase its values of maxIterations and defaultElectricalCharge.
https://gojs.net/latest/api/symbols/ForceDirectedLayout.html#maxIterations
https://gojs.net/latest/api/symbols/ForceDirectedLayout.html#defaultElectricalCharge
If your nodes are unusually large, you might also want to increase the value of defaultSpringLength.
https://gojs.net/latest/api/symbols/ForceDirectedLayout.html#defaultSpringLength
Related
I'm making a network visualization with NodeXL. My graph includes several nodes that have no edges but that I would still like to display- but it doesn't appear that these nodes show up when I show the graph. Does anyone know how to include these 'isolated' nodes in the visualization?
I've run into this problem as well and have not found a "built-in" solution that exists inside NodeXL. One (poor) solution is, when you import or add your edges to NodeXL, add one additional row to your edgelist for each isolated node you wish to appear, with the two values (2,2) for example, if you wish to force NodeXL to show unconnected node 2 in your network graph. This node WILL appear in your network image, albeit with a circular "loop" from that node to itself.
I've spent hours searching for an answer to this, but in most cases either the
question is about plots/charts (rather than graphs as in "control flow graph"),
or the answer "just use graphviz" is a valid answer.
However I have some constraints and requirements that make "just use graphviz" a
non-answer.
The full graph is large enough that it's not possible to generate a graphviz
for all of it.
Nodes and edges will be dynamically added and removed.
Nodes have lots of information that will be hidden by default and will be
expanded on request (imagine every node as a table with expandable rows/cols)
I want to be able to show only a subset of the graph on request, e.g. for
features like "only show reachable part of the graph from this node" or "show
all simple paths from this node to this node".
Basically I want to be able to start drawing nodes and edges on a 2D plane, and
add new nodes and edges dynamically. It's fine if nodes/edges move around as new
stuff is added. While I don't yet have hard requirements for this, it'd be good
if it looked "nice" -- for example if a node has lots of incoming edges (this is
a directed graph) ideally it'd be in a central place on the plane with all other
nodes around it etc.
Anything that gets me going would be helpful. Thanks.
(I don't know what label to add to this, adding "graph-theory" because I don't know what else to add)
I'm using the Overpass API to query Open Street Maps for nearby road segments. I am pretty sure that my query is returning all of the nodes of the nearby way... but I only want nearby nodes of the nearby way.
In the documentation it references this problem:
In general, you will be rather interested in complete data than just
elements of a single type. First, there are several valid definitions
of what "complete map data" means. The first unclear topic is what to
do with nodes outside the bounding box which are members of ways that
lie partly inside the bounding box.
The same question repeats for relations. If you wait for a turn
restriction, you may prefer to get all elements of the relation
included. If your bounding box hits for example the border of Russia,
you likely don't want to download ten thousands kilometers of boundary
around half the world.
But I looked at the subsequent examples and didn't see the solution.
Basically, in their example, how would I restrict the elements returned to those strictly in the bounding box (rather than returning the whole boundary of Russia)?
My current query is
way (around:100,50.746,7.154) [highway~"^(secondary|tertiary)$"];
>;
out ids geom;
I'm thinking maybe I need to change it to node (around:...) and then recurse upwards to the way to query for the highway tag but I'm not sure if I am even on the right track.
Actually, it's even a bit more complicated, as you need the set intersection of all nodes in a 100m distance and those nodes belonging to one of the relevant ways. Here's how your query should look like: Adjust distance, tags for ways as needed.
Note that depending on the tagging, there's no guarantee that you will find a node in a certain distance, especially if roads tend to be rather straight and longish. This for sure will impact your results, so a bit experimenting with a suitable radius is probably needed.
// Find nodes up to 100m around center point
// (center is overpass turbo specific for center point lat/lon in current map view)
node(around:100,{{center}})->.aroundnodes;
// recurse up to ways with highway = secondary/tertiary
way(bn.aroundnodes)[highway~"^(secondary|tertiary)$"]->.allways;
// determine nodes belonging to found ways
node(w.allways)->.waynodes;
(
// determine intersection of all ways' nodes and nodes around center point
node.waynodes.aroundnodes;
// and return ways (intersection is just a workaround for a bug)
way.allways.allways;
);
out;
check it out in overpass turbo: http://overpass-turbo.eu/s/hPV
Why preformance is droping down when I load for example a 4900 of nodes to scene? If there a 125 it's ok, 200 still ok, but if there are more of them rendering framerate is droping dramaticaly? Root node contains childs that contains (model (in 3ds) + texture + some science calculation) and all created in cylce from 0 to 4899. I have tried to use osgUtil::Optimizer on root after all childs where in place but still no improvments. Tried to put all nodes in one geode but it didn't help too. How can I achieve balance between performance and number of nodes?
4900 nodes seems an awful lot of nodes!
You should start reading about LOD and PagedLOD.
PageLOD will improve the performance. The idea is like this (imagine that the first image is a lot farther):
Since you are far far away, you don't want a lot of detail. But when you zoom in, you want to see those details. You'll have to specify what models go in each LOD level and how you want to activate them. That's the tricky part.
Also, check if you can share nodes. For example, instead of having 4 different wheels, you just create one wheel. Then, add 4 PositionAttitudeTransform/MatrixTransform and add the wheel node to each of them.
The same goes for StateAttributes, share them when possible!
Finally, if you have a lot of repeated geoms, take a look at geometry instancing.
My algorithm is processing DEMs. a DEM (Digital Elevation Model) is a representations of ground topography where elevation is known at grid nodes.
My problem can be summarized as follows:
Q is a queue containing nodes to visit.
at start, the boundary of the grid is pushed in Q.
while Q is not empty, do
remove Node N from the top of Q
if N was never visited then do
consider the 8 neighbors of N
among them select the unvisited ones
among them select those with a higher elevation than N's
push these at Q's tail
mark N as visited
done
done
As described, the algorithm will mark as 'visited' every node that can be reached from the border by a continuously ascendant path. It is worth noticing that the order of processing the nodes in the queue is unimportant. Note also that some points may request a tortuous ascendant path to be reached from the border. Think for example to a cone with a furrow spiraling around it. The ridge of the furrow is such a unique and tortuous path capable of reaching the top of the cone without never descending into the furrow.
Anyway, I want to mutithread this algorithm. I am still in the first step of wondering which is the best organization of data and threads in order to have as least pain as possible at debugging the beast when it is written.
My first thought is to divide the grid into tiles and split the Queue in as many tiles as there is in the grid. The tiles are piled in a work-list. A few threads are parsing the work-list and grab any tile where something can be done at the moment.
Working on a specific tile will firstly need that the tile's queue is not empty. I may also need that the neighboring tiles can be locked if the walker's tile has to visit a node at the edge of the tile.
I am thinking that when a walker cannot lock a neighboring tile while it needs to, then it can skip to the next node in the local queue, or even the thread itself can release the tile to the work-list and seek for another tile to work on.
My actual experience of multi-thread programming is good enough to understand that this lovely description is very likely to turn into a nightmare when I will debug it. However I am not experienced enough to evaluate the various possibilities of programming the algorithm and make a good decision, having in mind that I will not be given a month to debug a spaghetti dish.
Thanks for reading :)