nxviz <> grave

[ericmjl]

Friends! I noticed this pop up as I was browsing around GitHub.

I've been developing a package since 2016 (after I met @hagberg at SciPy 2016). It's called nxviz, and it's designed to provide a declarative (i.e. seaborn-style) API to draw graphs in a rational fashion. Included at the moment are ArcPlots, MatrixPlots and CircosPlots.

I'm hoping to not have duplicated efforts in any place, and I'd love to see how we could work together. Please let me know!

[tacaswell]

Hey @ericmjl ! From a quick glance it does not look like we have too much overlap of functionality yet.

Do you have thoughts on https://github.com/networkx/grave/blob/master/doc/developer/notes.rst ?

Poking around nxviz I am encouraged by some of the convergent design (expecting style information to be stashed someplace on the input graph).

One thing I really like about grave (and I am definitely biased here) is that there is an Artist sub-class

grave/grave/grave.py

Line 221 in af475f0

class NXArtist(Artist):

that gives some very nice interactivity out of the box (see https://github.com/networkx/grave/blob/master/examples/node_picking.py), dynamic updates, and an easy path to composition (just put two of the artists in the same Axes).

[ericmjl]

@tacaswell nice to know you're working with the grave project! I am curious, though how did the name get chosen? It possess quite a bit of, err, gravity. 😄

One of the things that I had aspired with nxviz was that users needn't explicitly specify what exact styling went with each node and/or edge. Rather, it was inferred from the data types (for which I have to admit, I only have some heuristics encoded to detect these data types automatically). Is this something that grave has enabled?

As for the thoughts on notes:

• I WANT ARTISTS!!!!!! 😄 I need you to teach me, Master Caswell.
• definitely agree with 'seaborn for networks'!
• I already have adjacency matrices (MatrixPlots) implemented (they were the easiest to get going). Auto-ordering by cluster is not implemented, though it's accessible if the user pre-clusters the graph and annotates cluster ID on the nodes.
• node and edge styling - should be done declaratively. I've accepted PRs into nxviz that provide this functionality + labelling for CircosPlots, and I'm looking to port it over to other plots as well.
• I've been avoiding trees, but mostly out of practicality. Tree layouts "seem" tough (but I might not have given this enough thought). The biggest use case I can think of is phylogenetics, which I did before (but not longer dabble in).

[jarrodmillman]

They started from the fact that mathematicians usually refer to a graph as G = (V, E). Grave contained those letters and was short, available, and easy to remember.

[tacaswell]

Doing a composite artist was not too bad, the biggest issue was sorting out which of the artist methods need to be forwarded directly and which need to be intercepted and managed.

I am less than fully sold on declarative styling. When it works, I can see it works well, but in general it requires having too much understanding of the input data that is available. There are a couple of examples doing interesting coloring / scaling based on computed graph properties (centrality, degree, etc) or based on being in the dominating set. I guess you could push everything back to two data frames(one for edges and their properties and one for edges an fall back to a declarative grammer for data frames? I suspect building a declarative API on top of grave would not be that hard.

One nice thing of the approach in grave is trees are (to first order) graphs with a different layout engine.