This might work, but it seems like an expensive optimization in that it changes a lot of the API. If someone cannot make a single copy of the data, it's unlikely that they're even going to be able to get to GenomicData() or manipulate it later. Perhaps the coercion function needs some simple tweaks? The filter support would definitely help. I'd rather keep things simple and return a single type, and GRanges sounds most appropriate.
But I'm open to suggestions and further argument. Michael On Wed, Aug 4, 2010 at 2:05 PM, Patrick Aboyoun <[email protected]> wrote: > Michael, > How integrated would you like to see the GRanges class in rtracklayer? The > rtracklayer::GenomicData constructor is the master instantiator. I would > like to add an asRangedData = TRUE (default) argument to the GenomicData > function and push it all the way up through the import functions where when > the user sets asRangedData = FALSE, the GenomicData function would create a > GRanges object. This is what we did with the > {matchPWM,vmatchPattern,vmatchPDict},BSgenome-methods in the BSgenome > package and it as good a solution as any. This is a straight-forward change > and wouldn't take too long to complete. > > > Patrick > > > > On 8/4/10 12:56 PM, Michael Lawrence wrote: > >> GRanges support is definitely on the TODO list. Filters are a good idea >> and >> also on the TODO list, possibly with a chunk size parameter to enable >> chunk >> processing. >> >> I'd love to have the GRanges stuff at least done by the next release. >> Patches welcome, of course :) >> >> Michael >> >> On Wed, Aug 4, 2010 at 8:08 AM, Ivan Gregoretti<[email protected]> >> wrote: >> >> >> >>> Hello Michael and everyone, >>> >>> Would you please consider adding to import() the capacity to generate >>> a GRanges object rather than the default RangedData object? >>> >>> Also, >>> >>> Wouldn't it be great to be able to import() with filters just like >>> with readAligned()? >>> >>> >>> >>> Justification >>> >>> GRanges is a biology-aware container. When importing large BEDs into >>> R, the current workflow involves creating RangedData first and then >>> converting to GRanges. >>> >>> If the BEDs are really big, holding both objects in memory at any >>> point in time is a hardware challenge. >>> >>> The capacity to filter the input would help in this case and in >>> general it would provide an increase in efficiency. >>> >>> >>> Thank you, >>> >>> Ivan >>> >>> >>> >>> >>> Ivan Gregoretti, PhD >>> National Institute of Diabetes and Digestive and Kidney Diseases >>> National Institutes of Health >>> 5 Memorial Dr, Building 5, Room 205. >>> Bethesda, MD 20892. USA. >>> Phone: 1-301-496-1016 and 1-301-496-1592 >>> Fax: 1-301-496-9878 >>> >>> _______________________________________________ >>> Bioc-sig-sequencing mailing list >>> [email protected] >>> https://stat.ethz.ch/mailman/listinfo/bioc-sig-sequencing >>> >>> >>> >> [[alternative HTML version deleted]] >> >> >> _______________________________________________ >> Bioc-sig-sequencing mailing list >> [email protected] >> https://stat.ethz.ch/mailman/listinfo/bioc-sig-sequencing >> >> > > [[alternative HTML version deleted]] _______________________________________________ Bioc-sig-sequencing mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/bioc-sig-sequencing
