Details
-
Type:
New Feature
-
Status: Closed (View Workflow)
-
Priority:
Major
-
Resolution: Done
-
Affects Version/s: None
-
Fix Version/s: 10.0.0 Major Release
-
Labels:
-
Story Points:5
-
Epic Link:
-
Sprint:Fall 1 - Sep 5, Fall 2 2023 Sep 17
Description
Situation: A user inquired as to whether there was a way for IGB to indicate which exon had been selected. For example, many studies report mutations by which exon they affect (i.e. the mutation is found on the eleventh exon). Currently IGB does not provide this information. Counting exons visually can be quite challenging, especially in humans where exons are very small relative to introns, and can be separated by hundreds of thousands of base pairs.
Task: Investigate the IGB codebase to determine if there would be a relatively simple way to add the exon number to the tooltip or selection info. For example, if a user selects the second exon of a gene model, the tooltip or selection info tab would have a property titled "exon" and the value would be an integer representing the exon's number.
Attachments
Activity
- Implemented a feature that shows block number of a selected gene model in selection info.
- pull and checkout to this branch.
- added comments for each code change.
Testing Instructions: - select the single genome, click on the selection info and check for a property named "block number".
- Hover on single genome model and look for the property called "block number".
- The block number represents the sequence number or position of the block.
Testing on Mac:
- Default data from IGB Quickload shows block number correctly for +/- strands.
- ncbiRefSeqCurated in the hg38 human genome does not show the block number (I think these DAS files load as bigBed, which IGB cannot currently fully parse).
- Local bed file shows block number correctly for +/- strands.
- Narrowpeak and broadpeak files do not show block number (this is the correct behavior).
- Local GFF3 file (from smoketesting) does not show block number (correct behavior), but does show a "rank" property that seems to correlate with exon number, so no need to implement this feature for GFF3?
- Local GTF file (from smoketesting) does not show block number (correct behavior), but does have a "exon_number" property, so no need to implement the feature for GTF.
- Local bigbed file (see
IGBF-2978) shows block number correctly for +/- strands. - A FindJunctions file is showing the block number. This isn't exactly correct as the block number for findJunctions is always going to be 1 - 2 and will not change based on the exons associated with the junction. Odd that the findJunctions file is being parsed as a ucscBedSym, but I think it should be fine assuming we leave the property as "Block number" instead of exon, which could be confusing.
Everything seems to be working well. GFF/GTF already seem to implement the exon number, so we have now added bed/bigBed files. It's odd that the UCSC DAS files are not showing the block number, but I have a few theories (I will make a new ticket).
One quirk is that the first and last "thick" exons when overlapping a "thin" UTR will not show the block number. This is because the "thin" UTR is the actual child sym that the block number appears in, the thick part is drawn over top of it, and it is unclear where that sym is coming from.
Ready for pull request.
new pull request submitted after rebasing branch with main-JDK8.
PR is merged and main-JDK8 branch installers are newly built and ready for testing in the Downloads section of the team repo as usual: https://bitbucket.org/lorainelab/integrated-genome-browser/downloads/
Tested main-JDK8 installer on Mac.
Block number is working correctly, no errors in the log.
Closing ticket.
Bed file format: https://genome.ucsc.edu/FAQ/FAQformat.html#format1