[BioC] Gviz AlignmentTrack - Consistent y-scales

[Lance Parsons]

Thanks Aliaksei.  This in fact does work, though it took a bit of 
tweaking.  There are some constant size portions of the coverage track, 
even when no reads are plotted.  This means that I had to add a constant 
to the sizes in addition to a variable value based on the ylim.  Took a 
bit of work, but I seem to have it fixed, at least for my single case.

Lance

Aliaksei Holik wrote:
> Hi Lance,
>
> I wonder if the 'sizes' parameter in the plotTracks might be useful. 
> This would allow you to set the track height to be proportional to the 
> scale. E.g. if your first track's ylim=c(0, 3) and the second tracks's 
> ylim=c(0, 5), set the sizes=c(3, 5). I've only tried it plotting 
> DataTracks, but since it's passed to the plotTracks I can't see why it 
> shouldn't work with AlignmentTrack. Sorry if I'm stating the obvious 
> or missing the point again.
>
> Hope it helps,
>
> Aliaksei.
>
>
> On 2/05/14 12:14 AM, Lance Parsons wrote:
>> Thanks for you help, you are correct that the ylim parameter works as
>> expected with a DataTrack.  However, my issue is actually with the
>> AlignmentTrack (my apologies for the confusion). With an AlignmentTrack
>> (which looks much better when plotting coverage data, at least the way
>> I'm using them), the scale is adjusted when setting a ylim, but the data
>> is plotted according the automatically calculated ylim.
>>
>> However, I still have an issue with plotting consistent scales, but
>> different heights.  What I would like is for the scale on all of the
>> graphs the same, in other words, the same number of pixels represents a
>> consistent value (say 50 pixels equals a y-value of 50).  However, I
>> would like some data tracks to be from 0-100 and others to be from
>> 0-200.  Is that possible?
>>
>> Thanks for your help.
>>
>> Aliaksei Holik wrote:
>>> Hi Lance,
>>>
>>> I'm relatively new to Gviz myself, but I believe there might be a
>>> simple solution to your problem. I'm not sure, why the thread has
>>> AnnotationTrack - your problem doesn't seem to have anything to do
>>> with the annotation. If I understand correctly, you would like to
>>> ensure consistent y axis for your DataTracks between plots, while
>>> allowing DataTracks of different height within each plot. You can do
>>> so by passing ylim parameter to individual DataTrack commands, the
>>> same way I imagine you're passing the bam file, the col.histogram and
>>> fill.histogram parameters.
>>>
>>> I've just checked and it seems to work ok in Gviz_1.7.10, and 
>>> Gviz_1.8.0.
>>>
>>> I hope it helps,
>>>
>>> Aliaksei.
>>>
>>> P.S. I'm not sure, why you needed a patch, if ylim is a standard
>>> parameter in Gviz. Apologies for possible confusion.
>>>
>>> On 1/05/14 5:39 AM, Lance Parsons wrote:
>>>> I've been using Gviz (1.8.0) to generate some figures using the
>>>> AnnotationTrack feature.  Generally, things have worked quite 
>>>> well.  I'd
>>>> like to plot a number of different coverage plots on the same 
>>>> figure and
>>>> the coverage graphs have rather different heights.  I'd like to use a
>>>> consistent sized Y-scale between each plot, which led to my writing a
>>>> patch regarding an issue setting the ylim on those plots (submitted on
>>>> bioc-devel list).  The patch I provided allows me to do that, but in
>>>> order to ensure the scale are the same, I need to set the height of 
>>>> each
>>>> graph the same.  This leads to a lot of wasted space in the figure for
>>>> those plots with lower coverage.  Does anyone have any suggestions for
>>>> how I might be able to ensure a consistent y-scale between the plots,
>>>> but also allow some plots to be shorter than others, thus eliminating
>>>> (or at least reducing) the wasted space?  Thanks in advance for any
>>>> advice.
>>>>
>>>> Example plotting graphs without setting ylim (not the scales for each
>>>> are different): http://i.imgur.com/68xObgx.png
>>>> Example of patched code with ylim set (now the ylim is used properly):
>>>> http://i.imgur.com/EXlrkqa.png
>>>>
>>>> I hope this helps to resolve what I think is an unintended bug.
>>>>
>>

-- 
Lance Parsons - Scientific Programmer
134 Carl C. Icahn Laboratory
Lewis-Sigler Institute for Integrative Genomics
Princeton University