You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currently, the pan-view uses the old strategy from basic view whereby every track extent is determined exclusively by "num neighbors"; when some tracks have internal gene PAVs (as is typically the case) this creates "ragged" track alignment edges. This can give the false impression
that tracks are lacking the genes on the edges when in fact they simply fell outside the num neighbors bounds. One approach, though perhaps not the most "performant" would be to do a two-pass track definition. In the first pass, we would determine a gene family set using the num neighbors approach across all the given gene foci. Then, after this gene family set had been established, we could requery for tracks, using essentially (if not exactly) the same method that is
used for the search view track retrieval (ie for the sought tracks, not the query track). If it weren't for federated mode, this could probably be accomplished in one server request, but as it stands it
seems like it will have to be two. Other ideas welcome...
The text was updated successfully, but these errors were encountered:
thinking about this a bit more; I think it's a good idea, but one thought that just occurred to me to consider a bit further:
depending on how it was implemented, it could end up pulling in tracks that don't have a gene in the initial specified list (ie if the second pass simply looks for any contexts with similar content without restricting it to extending the initial given contexts; each behavior might be appropriate in certain circumstances, so this could be considered a parameter- although I suppose that one could argue that any new tracks pulled in this way would extend the set of families to consider and force another iteration with a wider net
currently, the pan-view uses the old strategy from basic view whereby every track extent is determined exclusively by "num neighbors"; when some tracks have internal gene PAVs (as is typically the case) this creates "ragged" track alignment edges. This can give the false impression
that tracks are lacking the genes on the edges when in fact they simply fell outside the num neighbors bounds. One approach, though perhaps not the most "performant" would be to do a two-pass track definition. In the first pass, we would determine a gene family set using the num neighbors approach across all the given gene foci. Then, after this gene family set had been established, we could requery for tracks, using essentially (if not exactly) the same method that is
used for the search view track retrieval (ie for the sought tracks, not the query track). If it weren't for federated mode, this could probably be accomplished in one server request, but as it stands it
seems like it will have to be two. Other ideas welcome...
The text was updated successfully, but these errors were encountered: