When you have a ranking within a subset, you can also use a pagination-like approach to flip through to lower-scoring elements in the topological subset (e.g. N hops away from a chosen node), using some score or ordinal ranking to cut down that topological set to a reasonable size.
Another useful metric is topology combined with score: You can select a subset based on the graph topology relative to a chosen locus (e.g. For example, we have a tool called HiView that uses this subset approach with an ontology level selection metric. We are actively exploring solutions to this problem. The problem, then, is to filter the elements to show only a relevant subset of the graph that a user could easily parse - and to allow the user easy navigation from one chosen subset to another one. Large, highly-connected graphs tend to be more or less a hairball regardless of choice of layout. Choice of layout can help with that issue to some degree. Even assuming that you never have performance issues with large graphs and that you make an ideal choice of layout, large graphs usually just become visual noise. The root issue with large graphs is that it is difficult for a person to visually parse so many data points at once. A layout is just a function of node to position, and layout is one of many considerations in designing for a good user experience with large graphs. fCoSE is a new layout that is faster than traditional force-directed layouts. The main recommendation I can give you for large graphs is to use fCoSE if you want to use a force-directed layout (n-body physics simulation).
One important consideration, as you mentioned, is the overall number of elements. There are several different types of layouts, and in our experience you really have to experiment with different layouts and different layout options to see which combination works best for your particular data. Here's an excerpt of an email I wrote to someone else on the same topic: Each layout has a demo that you can easily use to experiment with your data. Layout quality and performance are a function of your data, your choice of layout, and how well you tailor the layout options to your specific dataset. That's a matter of layout rather than rendering performance.
0 kommentar(er)
