Comments (14)
Definitely, let's hack then!
from nxviz.
I like the idea of a declarative API (and discussing the API from the start!). From what I understand a declarative API means the user writes code describing what they want, rather than how to do it (imperative). Thus I think it would work out best if we start with a clear path between basic declarations and what they mean. Are there any common practices out there?
Building on your BasePlot
snippet, maybe it makes sense to use key_name
to define groupings and separate them from the corresponding visual component (color, linewidth, etc.). Then the user could say "I want my node groups to be different colors and my edge groups to be different linewidths" like so:
b = BasePlot(G, node_grouping=('key_name', 'color'), edge_grouping=('key_name', 'linewidth'))
We could use matplotlib's cycler
API under the hood.
I also agree this could get messy too. We'd need a way to determine if the values under the keyed attribute are compatible with the visual element being styled (e.g. a continuous-valued attribute is compatible with a sequential colormap but not a linestyle).
from nxviz.
Those are great thoughts, @jonchar.
Do you think a declarative API can be implemented alongside an imperative API? I'm struggling to figure out how that might work. Right now, the current APIs of the old Circos and Hive Plots, which I'm right now copying over as a first step, are imperative APIs.
from nxviz.
@ericmjl I could see having both if declarative API calls map directly to imperative calls that use defaults we choose. Optional imperative statements could also be specified that would then override our defaults (e.g. by adding node_cmap='cmap'
to the above call). Perhaps we could start with this kind of approach?
My instinct is to think of declarative APIs as balancing out flexibility. Finding the right balance will probably become apparent over time.
from nxviz.
@jonchar Those look like great ideas!
Right now, the BasePlot implementation provides a way for uniformly colouring all nodes and all edges (the node/edgeprops
) and a way for colouring individual nodes and edges (the node/edgecolors
). I have a hunch that the declarative API might look different for different kinds of plots, but I'm not quite sure; it might need a whiteboard session to figure this out.
Will you be at the next Boston Python project night? Let's hack on this then?
from nxviz.
Not a contributor yet, but plan to be. I hope it's OK to chip in.
A declarative interface sounds interesting and something I would be looking forward to implementing. However, if the end goal is to have nxviz
merged into NetworkX, it might be good to check out NetworkX's api and try to mirror it, so as to have better integration.
from nxviz.
@leotorr welcome aboard! I'd love to see some PRs from your side as this visualization package progresses, and if they are looking good, I'd be happy to add you as a direct collaborator later on.
On the NetworkX API side, there's a bit of a back story. I had a chat with Aric Hagberg (lead developer of NetworkX) at SciPy 2016 about integrating some visualizations. I think he approves of the "plotting object" design as it stands right now, so what might happen is that we end up passing in a Graph Object into a Plotting Object, and let the user use a "delcarative" approach. This is all up for re-designing nonetheless; the goal is to easily enable users to create fancier network plots beyond mushed up hairballs.
from nxviz.
@ericmjl thanks!
I see what you are saying, and I agree that it's best to separate the graph topology code and the graph visualization code. I guess what I'm saying is that, if users of NetworkX are used to an imperative grammar with nx's Graph objects, would it be natural to expect them to use a different philosophy for the Plot object? Again, I'm all for trying that myself, but I can't speak for anybody else.
What @jonchar says is true though, if there is a mapping from declarative to imperative methods, then this should be less of a problem.
(Also, btw, I'll be moving to Boston this Fall, would love to meet up my if I get around to contributing more to this project.)
from nxviz.
@leotorr welcome to Boston! Yes, we'd love to hack with you on this. What will you be doing in the Boston area, btw?
from nxviz.
Network Science PhD. That would explain my interest in this project.
from nxviz.
Cool stuff. Welcome to Boston, and hope you can join us at the Boston
Python meetups (they're usually near the MIT campus) to hack on nxviz!
On Thu, Jul 28, 2016 at 8:59 AM Leonardo [email protected] wrote:
Network Science PhD http://www.networkscienceinstitute.org/. That would
explain my interest in this project.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#2 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACgnjvl99buhucL67z-mfTfBrU67X0WHks5qaKefgaJpZM4JOVRw
.
from nxviz.
I gave this issue of a declarative API a bit more thought.
I think the key thing I noticed here is that there are key parameters in rational network viz that can be controlled, and that they should map onto some kind of data. Building off @jonchar's API spec, if we go by some key, then it would make sense to do some data checking. For the distribution of data keyed by that key, here's what I think would make most sense for data checking:
node_order
: something sortable (e.g. quantitative, ordinal, or categorical by alphabet)node_size
: quantitative data onlynode_grouping
: 'discretely' separable data, so categorical or ordinal are both good.node_colour
:- quantitative:
- divergent
- sequential
- categorical - up to 12 bins (as done by colorbrewer)
- quantitative:
edge_width
: quantitative only, it's a size mapping.edge_colour
: as pernode_colour
, both quantitative and categorical data are usable here.
I based these ideas mostly off this Points of View column series by Bang Wong (Broad Institute) & Martin Krzywinski (BC Cancer Research Centre), but if I'm missing something, please post!
from nxviz.
After talking with @jonchar, in order for the API design to be of the form:
c = CircosPlot(graph=G, node_order='kw1', node_size='kw2', node_grouping='kw3', node_colour='kw4', edge_width='kw5', edge_colour='kw6', data_properties=some_dictionary)
the data has to be checked first to make sure that the data keyed by the node and edge metadata keywords (kwX
) fit the type of data that can be expressed by the drawing property (order, size, grouping, as per above's comment). Probably best to implement the data checking functionality on the BasePlot()
object so that it's available for all children instantiated. These data checks should also be stored as an attribute, so that they can be passed to other plotting objects if needed.
The structure of the plot.data_properties
attribute could be a dictionary of dictionaries:
{node_kw:{kw1:'categorical', kw2:'quantitative', kw3:'ordinal',... },...}
Providing the data_properties
keyword argument will allow the end user to provide this up-front, thus allowing us to bypass the checks, and raise loud errors if they don't turn out to match.
from nxviz.
Hey guys, I'm going to start a fork that implements this new API, as it turns out I'm going to begin using nxviz for a DataCamp contribution I'm making. Just wanted to let everybody know about it!
from nxviz.
Related Issues (20)
- I have vertex.txt and triangle.txt, how to create a networkx graph? HOT 2
- Is it possible to make arcplot directional? HOT 2
- Downgrading pandas, matplotlib, networkx packages when installing nxviz HOT 4
- Broken example in new API documentation
- version mismatch on packages distributed by conda and pypi HOT 3
- Not an issue but a veli easy question
- Having trouble re-creating graph HOT 1
- Feature Request: Edge direction by source or target node colors. HOT 6
- Feature Request: Node label layout for circus plot HOT 2
- Question regarding parameters when creating MatrixPlot or CircosPlot HOT 6
- Changing the default node colors in Circosplot
- 'LinearSegmentedColormap' object has no attribute 'colors' with divergent network edges HOT 1
- draw() thakes 0 positional arguments but 1 was given HOT 6
- Module nxviz has no attribute 'annotate'
- Annotate node_colormapping legend_kwargs are not applied
- Error importing and executing Circosplot. HOT 1
- Matrix Plot Overlay Bug
- Customize node size and colormap in circosplot
- how show the node_labels on nxviz version:0.7.4 HOT 2
- ImportError: cannot import name 'CircosPlot' from 'nxviz.plots HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from nxviz.