Hi GRangers,
I'll add this to GenomicRanges. Hope you don't mind if I rename
it makeGRangesFromDataFrame(). This is more consistent
with the current naming scheme for specialized constructors
e.g.:
makeTranscriptDbFrom*()
makeGRangesListFromFeatureFragments()
readGAlignment*FromBam()
GRs are a great data structure. But, standard bioinformatic file formats
(BED, WIG, BAM) don't always fit 1:1 with the organic beginnings of some
projects. The GenomicRanges infrastructure isn't on the radar of every R
developer, and some useful data can be found in ugly formats. Wouldn't it
be
+1
On Sun, Oct 6, 2013 at 9:28 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
bsseq::data.frame2GRanges does the obvious step of converting a data.frame
to GRanges. It has a couple of bells and whistles where strand can be
ignored and additional columns (apart from genomic
+1
--t
On Oct 6, 2013, at 6:28 AM, Kasper Daniel Hansen
kasperdanielhan...@gmail.com wrote:
bsseq::data.frame2GRanges does the obvious step of converting a data.frame
to GRanges. It has a couple of bells and whistles where strand can be
ignored and additional columns (apart from genomic
For any tabular data structure with chr[om] and one or more of starts, ends,
widths, and strands, there _is_ an obvious mapping, though! And I personally
always have an optional argument to keep the rest as mcols(). It just seems so
straightforward.
The generic granges() method also suggests
This is a convenience function, which provably has saved tons of time for
me and others. I get lots of data from various excel/cvs files lying
around various places, and these files _always_ have a clear path to a
GRanges. Perhaps you never have to deal with this kind of data, but we are
a few
