Open everbeek opened 10 years ago
These two use too much force. I also think they are only using forces to position things, which is odd.
http://mbostock.github.io/d3/talk/20110921/parent-foci.html http://mbostock.github.io/d3/talk/20110921/depth-foci.html http://bl.ocks.org/mbostock/1138500
I am going to step back and see if perhaps all the hard work around the force layout can simply be shoved into these other layouts. Could it be as simple as having several initializations for different layouts, and providing the same data and function bindings?
Doesn't seem like it. I also realized that for the DAGs we get from Bioportal, the D3 tree layout might be inappropriate. Seeing if I can find an example of DAGs with that layout. We might really need to use a different implementation for the tree layouts...
Also see: http://stackoverflow.com/questions/9712516/how-can-i-construct-a-tree-using-d3 http://stackoverflow.com/questions/11053511/how-to-layout-a-non-tree-hierarchy-with-d3 http://bl.ocks.org/GerHobbelt/3683278 http://bl.ocks.org/GerHobbelt/3669455
Likely we will use our own code adapted from Choosel Biomixer.
The menu we want to replicate can be seen in the old Choosel view. It can be used with code that creates the menu for the new ontology view. The new ontology view has the central node circle layout implemented in a hard coded fashion (find where the nodes are first created to see how). The node .x and .y attributes are already mapped to positions for D3, so changing those should change node position. To turn off the force layout, see how it is manipulated in the ontology view, which subverted it entirely. Our priorities are circle/central circle layout, tree layouts, a decent force layout parameter set, and then maybe the radial layouts. Node collision should probably be worked on too, and it might help all layouts, so maybe work on that first so that you can be familiar with it when it needs adjustment in later layouts.
Dev URLs: Choosel: http://127.0.0.1:8888/?mode=embed&embed_mode=paths_to_root&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F82968002&userapikey=
New D3 Concept View: http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=NCIT&full_concept_id=http%3A%2F%2Fncicb.nci.nih.gov%2Fxml%2Fowl%2FEVS%2FThesaurus.owl%23C14787 http://127.0.0.1:8888/conceptPathToRoot.html?gwt.codesvr=127.0.0.1:9997&initial_vis=term_neighborhood&ontology_acronym=SNOMEDCT&full_concept_id=http%3A%2F%2Fpurl.bioontology.org%2Fontology%2FSNOMEDCT%2F82968002
New D3 Ontology View: http://127.0.0.1:8888/ontologyMappingOverview.html?gwt.codesvr=127.0.0.1:9997&ontology_acronym=NMR
If we are moving to D3, we need a tree layout. I do not mean the one created with d3.layout.tree() though: http://bl.ocks.org/mbostock/4339083
We want it to stay within the force layout from d3, so we will need to use initialization and layout parameter modifications. The worst case scenario is to turn off all force related parameters and have custom time step code. Bets case is to leave parameters on, and to be able to compute the layout in one single-run function, and set the force layout to be completed.
I am checking for existing code for this. I will also look for and radial tree layouts (like d3.layout.cluster(). The code in Biomixer could be used for this with adaptation; it is all in Java, but the math stays the same. It's likely that I could run the d3.layout.tree to get positions in the background, and grab those for the main graph.