Hi Michael,
Thanks, using 'GenomicRangesList' instead of 'GRangesList' essentially
solves my issues. Could you please add a small note to the
documentation that mentions the different behaviors for the two classes?
Best wishes
Julian
On 09/03/2013 03:34 PM, Michael Lawrence wrote:
If the number of GRanges is small (not thousands), and you don't need the
semantic of treating each GRanges as a "compound range", then use
GenomicRangesList(). It's a SimpleList, so metadata should be preserved.
It's the data structure for storing per-sample GRanges.
Michael
On Tue, Sep 3, 2013 at 2:39 AM, Julian Gehring <julian.gehr...@embl.de>wrote:
Hi Michael,
The use case is storing experimental metadata togther with a GRanges
object that does not fit the tabular structure of a GRange. And at a later
stage, storing multiple of these annotated GRanges objects together as a
list/GRangesList.
Best wishes
Julian
This second case is exactly what happens to the individual GRanges that
constitute the list. They are concatenated to form a single GRanges, which
is stored along side a partitioning that defines the individual elements.
There is no longer two separate GRanges objects, so there is no easy way
to
keep the metadata around. It's unfortunate that an implementation detail
is
exposed in this way, but it would take some effort to support this
feature.
This is a property of all CompressedList derivatives. What's the use case?
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
