-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Filter or sort by score #511
Comments
This feature request was a result of JBrowse being rolled out at WormBase: |
Colin, I was thinking of having it do the filtering within Apollo, but was not sure if this was a “JBrowse” or an “Apollo” feature. Nathan On Sep 15, 2014, at 12:31 PM, Scott Cain notifications@github.com wrote:
|
Filtering is definitely provided by JBrowse (FilterFeatureMixin). It can also be both global or on a track-specific basis. This means that, for example, you can either call browser.setFeatureFilter or track.setFeatureFilter to perform filtering. Or you can use addFeatureFilter/removeFeatureFilter to create a chain of them. Here's a simple plugin for filtering that I refactored out of webapollo:
I think the plugin framework is probably the best place to "put" the feature filters for now though, although someone really clever might find a different place to implement them (i.e. they could be loaded via right click menus, or something like that) As for changing the "layout" or sorting algorithm, that is more tricky, but something that webapollo also plans to do. |
Colin's right, this is definitely JBrowse (another one of those cases where It also relates to the issue of piling up of features (track height, issue -S On Tue, Jan 27, 2015 at 7:15 AM, Colin Diesh notifications@github.com
|
It would be really great to be able to sort and/or filter by feature score, regardless of the track type. While BAM and VCF data can be filtered in some ways, a fundamental option would be to allow a user-configurable cutoff score.
A potentially more difficult option would be to allow features to be sorted by score. This would keep a multitude of poorly scoring features from pushing the good scoring features of the bottom of the "max height reached" bottom.
The text was updated successfully, but these errors were encountered: