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?
>>
>
>
>
[[alternative HTML version deleted]]
_______________________________________________
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel
