ExonMostlyDesignMeeting 11-19-14

left whiteboard

right whiteboard

Galt's drawing of alt-in-the-middle example

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

1. Experiment with database layer: multiple small vs. one large vs. a few large queries
2. 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.
3. 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.

1. small regionList: 3 regions, alt in the middle, view all of all 3 regions
2. larger regionList: all exons of a titin exoform of your choice