Converting Gff To Bed With Bedtools?

Question

[user]

I use bedtools's sortBed utility to sort BED files for various operations. It takes as input GFF files as well. However, when I feed it a GFF file as in:

sortBed -i myfile.gff

it outputs it as GFF, not BED. Is there a way to make bedtools sort and then convert the result to BED? Many bedtools utilities have a -bed flag. Do I need to use a different subutility of [bedtools to achieve this? thanks.

[Gjain]

try this: http://code.google.com/p/bedops/wiki/gff2bed#Dependencies

Answer 1

[brentp]

If the problem is with sortBed, just use linux sort

sort -k1,1 -k4,4n input.gff > output.gff

[Konrad Rudolph]

OP wants the opposite. I.e. input GFF, output BED.

[brentp]

Oh. I completely misread that!

Answer 2

[Alex Reynolds]

Why not just pipe it into a conversion script? For example:

$ sortBed -i myfile.gff | gff2bed > my_sorted_file.bed

You can also skip sortBed altogether, as gff2bed uses BEDOPS sort-bed internally:

$ gff2bed < myfile.gff > my_sorted_file.bed

In practice, sort-bed tool is faster than GNU sort and sortBed and is non-lossy *shrug*.

[user]

yes, you are right, I was just hoping to do it within bedtools for uniformity and not relying on more scripts (since I already use bedtools intersect and sorting features), so was curious if there was some undocumented trick perhaps to make bedtools do it.

[Ann]

This conversion script doesn't build the subfeature structure - all it does is convert line by line and doesn't appear to construct actual gene models. Maybe I am not using it correctly?

[Ann]

OK I looked at the documentation. Should have done that first! Anyway, looks like gff2bed doesn't build the BED structure with exon starts, exon lengths, thickStart, thickStop and so on.

I guess this is pretty hard to make work, since different groups write out GFF data in different ways. Despite the very nice description on the Sequence Ontology Web site, there is still no consensus on how to write GFF.

To get an idea of the sheer diversity of GFF3 variants that all organize gene models in different ways, see:

• Physcomitrella patens: https://www.cosmoss.org/physcome_project/linked_stuff/Annotation/V1.6/P.patens.V6_filtered_cosmoss_genes.gff.gz
• Physcomitrella patens non-coding: https://www.cosmoss.org/physcome_project/linked_stuff/Annotation/V1.6/ncRNA.combined.public_release.gff.gz
• Tomato: ftp://ftp.solgenomics.net/genomes/Solanum_lycopersicum/annotation/ITAG2.4_release/ITAG2.4_gene_models.gff3
• japonica Rice, MSU7 annotations: ftp://ftp.plantbiology.msu.edu/pub/data/Eukaryotic_Projects/o_sativa/annotation_dbs/pseudomolecules/version_7.0/all.dir/all.gff3
• Phytozome.net reinterpretation of Physcomitrella patens: ftp://ftp.jgi-psf.org/pub/compgen/phytozome/v9.0/Ppatens_v1.6/annotation/Ppatens_152_gene_exons.gff3.gz
• My beloved Arabidopsis: ftp://ftp.arabidopsis.org/home/tair/Genes/TAIR10_genome_release/TAIR10_gff3/TAIR10_GFF3_genes_transposons.gff
• japonica rice, RAP-DB annotations: http://rapdb.dna.affrc.go.jp/download/archive/irgsp1/IRGSP-1.0_predicted_2014-03-05.tar.gz

Does anyone know of a tool that can handle all these variations?????

[Alex Reynolds]

If you have any thoughts on strategies for working with variants in conversion tools, please let me know.

It seems like something that is not easy to solve without some heavy research project-specific customization that I'd otherwise steer clear of with a generic toolkit.

I've also noticed that the TAIR10 set now seems to follow correct GFF formatting, which is a nice change.

But overall, it can be a tough problem to abstract.