[Bioc-devel] 'GRangesList' does not keep metadata of items

Julian Gehring julian.gehring at embl.de
Tue Sep 3 15:47:43 CEST 2013

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

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.gehring at 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?

More information about the Bioc-devel mailing list