fossasia / visdom

A flexible tool for creating, organizing, and sharing visualizations of live, rich data. Supports Torch and Numpy.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

NetworkX/Graphviz/DOT integration

dizcza opened this issue · comments

Is your feature request related to a problem? Please describe.
I'd like to visualize a (NetworkX) graph in Visdom.

Describe the solution you'd like
A function vis.graph that takes a NetworkX graph or a more abstract structure as a dict of nodes and edges and plots it.

Describe alternatives you've considered

  • graphviz graph rendered in a SVG string (it works, this is my current but lengthy and non-interactive approach; visdom strikes for interaction!):
    graph = graphviz.Graph()
    svg = graph.pipe(format='svg').decode('utf-8')
    viz.svg(svgstr=svg)
  • pyvis is integrated with NetworkX (link) and it's html-friendly, and perhaps it can be rewritten to plotly commands without headache.
  • Visualizing a NetworkX graph with D3.js. Step "5" contains a JavaScript snippet required to plot a NetworkX graph.

Hi dizca, I like to contribute to this issue. Can you please guide me through this issue!

@pulkit10251 glad to see that someone is willing to work on it.

Regarding the Javascript part

The best approach, as for me, is the last one with the link to an example with D3.js. If I knew Javascript, I'd implement it already. If you implement the basics like the core Javascript/D3.js code to plot a graph in visdom, I can contribute as well with a peer review, etc.

You can google for more snippets of Javascript-like implementations to plot an interactive graph. I encourage you to have a look at pyvis package to see how it implements an interactive visualization of NetworkX graphs in HTML.

Regarding the Python part

It's better not to exploit an example I showed with graphviz and rendering to an SVG string - Visdom strikes for interactability, and it's not possible to interact with SVG plots in Visdom.

The API of vis.graph or whatever you name it should accept either

  1. a dict of nodes as keys and edges as values. Edges themselves, as in NetworkX API, could be a list or a tuple of dictionaries that contains additional information like the weight, etc. Does not depend on NetworkX library.
  2. a NetworkX graph. Requires NetworkX library to be installed, which is extra functional.

The first approach is simple to start with. Consider this example of an undirected graph

graph_dict = {0: (1, 2, 3), 2: (3,)}
vis.graph(graph_dict)

However, dict of nodes and edges lacks information whether it's directed or undirected and other niceties that a NetworkX graph has. Therefore, the users need to pass all extra information in **kwargs of vis.graph, but I already see how quickly the list of optional arguments grows with future user requests to include this and that... it's bad.

The second approach allows you to exploit the attributes of a NetworkX graph. If a new feature is added in NetworkX, you'll be able to extract it from the graph itself without changing the API of vis.graph. Moreover, you can make the API as much similar to the networkx.draw function - it's a good practice to reuse API that has been proven to be great for years with thousands of starts on GitHub. I'd vote for this approach.

Or any other approach that you think is suited. In any case, I suggest you start with the first approach, make the first draft, and then reconsider what API is the "best".

Hi @dizcza, I have created the first draft of the code. I have already created pull request #814 .
you can check this PR.
Also, I want to put forward some problems/requirements regarding this PR :

  1. It is interactive, But still needs to add functionality to zoom and other useful functions.
  2. The python code still needs some changes related to "update" and "env". I hope you will help 👍 .
  3. Still scope to add further functionality where users have control over the size of node, and size of links.

Please review the code, and if it reaches your expectations, then please merge the changes.

Thanks

The first draft has been accepted. Other networkx-related feature requests should be raised in separate issues.