Indicate potential ORFs

[nathandunn]

Indicate a potential ORFs. From: http://gmod.827538.n3.nabble.com/ORF-viewer-track-td4059022.html

This is the artemis view:

In JBrowse there is this view:

with #1852, we are starting to get the JBrowse view again. However, unsure if we should show a different view when zoomed or, or provide a separate track.

[hexylena]

My old boss wanted this since forever and complained loudly that it wasn't available. I'd love it if it used the same view as the sequence track, and as you zoomed out just stop displaying letters and only display the start/stop (if enabled.) cc @moffmade

[nathandunn]

We’ll see what’s possible. I like having both solutions. Just realized (after saying its impossible) that we can fairly easily color the start and stop codons: https://github.com/GMOD/Apollo/pull/1852 https://github.com/GMOD/Apollo/pull/1852

I think the larger issue is calculating all of the start / stop codons in view for larger organisms when zoomed out.

On Jan 21, 2018, at 12:00 AM, E. Rasche notifications@github.com wrote:

My old boss wanted this since forever and complained loudly that it wasn't available. I'd love it if it used the same view as the sequence track, and as you zoomed out just stop displaying letters and only display the start/stop (if enabled.)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/GMOD/Apollo/issues/1853#issuecomment-359230860, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt2qgDzHwarvfyoh5kJnWzdBLrPkY4Aks5tMu6qgaJpZM4RlGOk.

[hexylena]

Cool! Looking forward to it. Yep, understand, do whatever is performant.

[nathandunn]

From https://github.com/GMOD/Apollo/pull/1855#issuecomment-359969192

I don't know if there is something explicitly written for it, but you're just looking for triplets. I don't think that JBrowse handles anything but the standard table.

For Apollo, the easiest would be to create a REST track and then add an adapter over the sequence table to return JSON. This could be cached or run in the background.

For JBrowse, you would need a way to call "prepareRefSeq.pl" and indicate the translation table: https://www.ncbi.nlm.nih.gov/Taxonomy/Utils/wprintgc.cgi producing the appropriate JSON file. You would need a custom view and store and some way to handle it over 3 frames. Needs more thought.

Waiting to get @rbuels thoughts, but we can take a shot at the Apollo version using a glorified REST track to do the same.

[nathandunn]

• [ ] create PR for the REST-track method
  • [ ] add a limited cache
  • [ ] limit zoom out level

[rbuels]

I'd say ORFs are best implemented as just a separate annotation track that is pre-generated. Run some tool that makes GFF3 that shows where the ORFs are, or something like that. It's a little hard to do on the fly because the start codons could be too far off the side of the screen to always detect, especially if the ORFs are long.

Maybe add something to the Apollo workflow that just makes some GFF3 showing where the ORFs are?

[nathandunn]

If its useful to JBrowse, than I would advocate that. I want to ping @selewis and try to get an idea of how useful it would be outside of annotation.

[hexylena]

just a thought I had - calculating the complete frame, sure, expensive. We always did that out-of-process due to the concerns mentioned by @rbuels. But showing the start/stop codons should be comparatively quite cheap and much easier to implement. People can create/load a track with all ORFs from a bunch of different tools, no need to re-implement in jbrowse.

[nathandunn]

Did you implement it in JBrowse then?

I think the implementation your are suggestion is FASTA / seq -> ORF (JSON) and then you write a new custom store / view track to view the 3 frames in both directions. It could histograms when zoomed out, potentially (or just disappear).

On Jan 23, 2018, at 9:46 PM, E. Rasche notifications@github.com wrote:

just a thought I had - calculating the complete frame, sure, expensive. We always did that out-of-process due to the concerns mentioned by @rbuels https://github.com/rbuels. But showing the start/stop codons should be comparatively quite cheap and much easier to implement. People can create/load a track with all ORFs from a bunch of different tools, no need to re-implement in jbrowse.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/GMOD/Apollo/issues/1853#issuecomment-360027568, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt2qiN1jw5ksZjKd-9yNBZiPnawgzgDks5tNsOggaJpZM4RlGOk.

[hexylena]

No, we didn't... that was the whole point, we didn't want to implement such a feature in JBrowse when there were many existing ways to do it without writing new code.

Not quite the implementation I'm suggesting. I'm suggesting:

• fasta file → gff3 / bed / etc ORF file (using an existing tool)
• that to json (flatfile to json.pl)
• using htmlfeatures/canvasfeatures to display them. This doesn't retain the three-frame separation in display but eventually my boss got over that.

This way no new code would have to be written. The histogram display is already implemented for those tracks, no?

Then all that's left is continue displaying the start/stop codons when zoomed out.