ExonMostlyDesignMeeting 11-19-14
Options for how many features to support
Only parts from one range
"exon mostly"
Allow mult chromosome pieces and ordering, all same strand
Then we could also display:
- patches }
- alt haplotypes } Navigation & chromosome position box has relatively obvious solution
- gene families (more work)
Either strand, display right to left
Much more dev & QA work, but would buy us
- cancer fusion genes
- gene families, all displayed 5' to 3' left to right
Discussion
b0b: multiple ideograms for multiple chroms? Jim: maybe repurpose the ideogram area... say something about a gene family if that's what you're viewing? Or a mode indicator. b0b: replace with "multiple chromosomes" text?
Galt: Ensembl shows patch locations on their ideograms; green highlight in background of patch location
Clicking around Ensembl's browser... there is a second ideogram to show only the patch being viewed; also two browser views, one on reference and one on patch, w/lines to show join points.
Jim: we have no annotations for patches.
Suggested choice for feature
Limit it to cutting out regions of one chrom or putting an alt haplotype in place
Implementation
Database/file query side
- make multiple queries, one for each region
- optimize somehow to gang up queries... good to get some datapoints
- Galt tests these alternatives
- mysql tracks (could be remote for GBiB)
- big* tracks (local and remote)
- MAFs
- custom tracks
Graphics side
A. Horizontal option: Keep logic very similar to now
Render each item once as we do now, and graphics code somehow figures out how to split. (See right whiteboard photo "drawBox chr1:x-y")
- ~25 functions for graphics need tweaking
- Track drawing funtions may need a region loop
- Angie thinks graphics layer could handle this
- Jim points out that now drawing code passes in chromosome as well as genomic start & end; graphics knows whole region list
- would mostly be removing stuff from track drawing code, maybe easier than changing
B. Vertical repeat drawing hack:
Call drawImage once for each region. Pros:
- simple
Cons:
- slow if long setup time
- labels difficult
Genome to pixel coordinate hack
Modify drawing routines (tracks' drawItemAt) to use new function
Assuming we only support exon view (not patches etc):
function genomeRangeToPixelRange(start, end, chromSize, pixWidth) returns {x1,x2}
- strict exon-mostly adds region list, still returns {x1,x2}, or null if entirely in intron (or x1==x2): draw one box across all pixel ranges. Labels are already drawn in pixel space not genome space, so they're already special-cased in code.
Recommendations
- Experiment with database layer: multiple small vs. one large vs. a few large queries
- On graphics side: make horizontal line & box functions and function to draw label to left of genomic coordinate that take a new structure and work in genome x coords. Need name for the new struct -- slicedGfx. It would have list of region, each w/chromosome range and pixel range; pointer to underlying image struct.
- Make linkedFeaturesDrawAt use slicedGfx.
Galt is least busy -- all 3 to Galt for now.
void slicedGfxNew(struct hGvfx *hgvfx, struct bed3 *regionList, uint pixWidth) void slicedGfxBox(struct slicedGfx *g, chrom, start, end, color)
Performance... maybe rangeTree for faster translation of genomic coords to pixel coords
Test cases
For starters, make little BED3 file (or customTrack?) and read regions from that.
- small regionList: 3 regions, alt in the middle, view all of all 3 regions
- larger regionList: all exons of a titin exoform of your choice