This repository has been archived by the owner on Sep 12, 2018. It is now read-only.
Colorize nodes based on repeats #165
Assignees
Labels
Comments
fedarko
added a commit
that referenced
this issue
Jun 1, 2017
This should be extensible in the future for colorizing other data than G/C content, e.g. repeats (#165). Furthermore, displaying multiple scaffolds at once (#185) should eventually be done using colorization: and I suspect that having explicit colorization control options would be helpful for that. (We'd probably need to first change node colors to "none" before performing scaffold colorization, though.)
fedarko
added a commit
that referenced
this issue
Aug 2, 2017
fedarko
added a commit
that referenced
this issue
Aug 3, 2017
For both nodes and singlenodes, so the colorization here should work fine in the SPQR modes as well. This also stores a field called "repeats_given" in the assembly table, which functions similarly to "dna_given" for GC content. The is_repeat value in the database can be either 0 (False), 1 (True), or NULL (the NULL is given if no annotation was given for the node in question). Anyway, all that's left for #165 is to make use of this data in renderNodeObject()
|
Oh, I should probably also display "Is repeat" or something as a column for nodes when |
fedarko
added a commit
that referenced
this issue
Aug 3, 2017
Still a few more things I'd like to address: -Test that withholding repeat data from certain nodes still lets this work (and that the nodes with no data are just colored the default node color). -Remove the |V| calls to getNodeColorization() for repeat colorization. We should be able to just get the hex string colors for MAX_RGB and MIN_RGB, store those as globals, and then just use those. That'd be faster than the current approach. -Add a column to the nodes table when DNA_INFO_AVAILABLE = true. In addSelectedNodeInfo() we'd add to that column to say either True, False, or N/A for input vals. of 1, 0, or null respectively.
fedarko
added a commit
that referenced
this issue
Aug 3, 2017
This was causing repeat colorization to use the old extreme values.
|
Did some testing, verified that undefined repeat data is processed correctly. All the TODOs for this are taken care of; closing. |
fedarko
changed the title
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
There's prior work in the lab on repeat detection that we could use to identify nodes to colorize/etc.
The text was updated successfully, but these errors were encountered: