incorrect parsing of (big)bed format -- with patch

[brentp]

after getting the hg18 xenoRefGene table from UCSC downloaded as an extended bed (12) file, i do the following

wget http://hgdownload.cse.ucsc.edu/admin/exe/linux.x86_64/bedToBigBed
chmod +x bedToBigBed

wget  http://hgdownload.cse.ucsc.edu/admin/exe/linux.x86_64/fetchChromSizes
chmod +x fetchChromSizes

./fetchChromSizes hg18 > hg18.chrom.sizes
sort -k1,1 -k2,2n $BED > $BED.sorted
./bedToBigBed $BED.sorted hg18.chrom.sizes $BED.bb

to get a bigBed format. then i add:

{name:                 'xenoRef',
bwgURI:               '/dalliance/xenoRefGene.gene.hg18.bed.bb',
collapseSuperGroups:  true}

to the test.html it appears to be loading features (the track has a height greater than the minimum and if i zoom out far, it gives the message about > 25 features), but they are not drawn.

when i wget one of the .bb files from the example test.html and then update test.html it to point to that local .bb, everything works fine. am i doing something wrong in the creation of the bigbed?

[brentp]

i think i see the problem. if i run bigBedToBed, on the example .bb from test.html, it looks like the blockStarts in column 12 are not relative to the feature start (they are global positions). instead they should be relative to the start in column 2. http://genome.ucsc.edu/goldenPath/help/customTrack.html#BED

[brentp]

patch to fix this here: https://gist.github.com/902550

it will break your example for the .bed you have, but works for normal beds.

[dasmoth]

Thanks, you're quite right. I'd been working off a file of Ensembl data which looked like BED12 but wasn't quite standard. I've applied your fix now and it should be in the next release.

I'd better build a fixed version of the demo file!

[brentp]

thanks, if you download the ensGene table from ucsc in bed format, then follow the steps i put above, it should give you a correct bigbed.