QuantitativeTrack crashing with "TypeError: this.ranges.map is not a function"

[lyijin]

uh this is a stranger bug. i have methylation data displayed on a QuantitativeTrack. for chr1, zooming into smaller subsections work as expected.

for any other non-chr1 chromosome, the track crashes with a TypeError on the second zoom. see video below.
screencast.webm

the same error is produced when i manually type a chr:start..end coordinate range in the search box (not shown in video).

i suspect it's due to the indexing and sorting of chromosome annotations. annotations of my genome and bedGraph (which generated the bigWig) are sorted in numerical order, i.e., chr1, chr2, ..., chr10, chr11, ..., chr20, chr21, ...

i'm not sure whether bigWig/bedGraph wants chromosomes to be sorted in alphabetical order (chr1, chr10, chr11, ..., chr2, chr20, chr21, ...). could this be why things are crashing? cheers

[lyijin]

just to provide additional background: this QuantitativeTrack is reading off a bigWig file via a symlink (jbrowse add-track --load symlink).

bigWig file was created from a bedGraph file, using UCSC's bedGraphToBigWig.

[lyijin]

sorry, i found the answer. i'll keep my question & answer up just in case others run into the same problem.

my suspicion was correct, the ordering of chromosomes was the problem (biggest hint was chr1 working but anything after that didn't). to solve this: EVERYTHING has to be alphabetically sorted (not numerical sorted).

1. genome has to be alphabetically sorted.

$ grep '^>' grch38p13_lambda_puc.fa
>chr1
>chr10
>chr11
>chr12
>chr13
>chr14
>chr15
>chr16
>chr17
>chr18
>chr19
>chr2
>chr20
>chr21
>chr22
>chr3
>chr4
>chr5
>chr6
>chr7
>chr8
>chr9
>chrM
>chrX
>chrY
>lambda
>pUC19

2. bigWigs are internally alphabetically sorted in column 1, but numerically sorted in columns 2, 3. if you convert a bigWig back into bedGraph, and check chromosome order, you get this.

$ ~/tools/ucsc_binaries/bigWigToBedGraph N01.filt.bw N01.bedgraph
$ cut -f 1 N01.bedgraph | uniq -c
1376548 chr1
 858521 chr10
 756010 chr11
 716258 chr12
 459602 chr13
 484205 chr14
 527620 chr15
 693329 chr16
 753032 chr17
 371210 chr18
 643347 chr19
1242327 chr2
 523145 chr20
 218337 chr21
 361033 chr22
 906786 chr3
 640107 chr4
 767375 chr5
 870673 chr6
 949635 chr7
 775661 chr8
 655276 chr9
    435 chrM
    543 chrX
   1674 chrY
   2992 lambda
    162 pUC19

to create the correctly ordered bigWigs with bedGraphToBigWigs, the chrom.sizes file also has to be sorted alphabetically. i still had errors when this file was sorted numerically. had i RTFM earlier, i would've found out that the bedGraph files have to be generated with sort -k1,1 -k2,2n (see below)

 ~/tools/ucsc_binaries/bedGraphToBigWig
bedGraphToBigWig v 2.10 - Convert a bedGraph file to bigWig format (bbi version: 4).
usage:
   bedGraphToBigWig in.bedGraph chrom.sizes out.bw
where in.bedGraph is a four column file in the format:
      <chrom> <start> <end> <value>
and chrom.sizes is a two-column file/URL: <chromosome name> <size in bases>
and out.bw is the output indexed big wig file.
If the assembly <db> is hosted by UCSC, chrom.sizes can be a URL like
  http://hgdownload.soe.ucsc.edu/goldenPath/<db>/bigZips/<db>.chrom.sizes
or you may use the script fetchChromSizes to download the chrom.sizes file.
If not hosted by UCSC, a chrom.sizes file can be generated by running
twoBitInfo on the assembly .2bit file.
The input bedGraph file must be sorted, use the unix sort command:
  LC_ALL=C sort -k1,1 -k2,2n unsorted.bedGraph > sorted.bedGraph
The LC_ALL=C variable activates case-sensitive sorting.
options:
   -blockSize=N - Number of items to bundle in r-tree.  Default 256
   -itemsPerSlot=N - Number of data points bundled at lowest level. Default 1024
   -sizesIsBb  -- If set, the chrom.sizes file is assumed to be a bigBed file.
   -unc - If set, do not use compression.

once that's done, the bigWig file is zoomable in chr2 and chr4 (which failed previously).
screencast.webm

PS also discovered that the TypeError isn't trigged by the second zoom, it's triggered when the genome view is smaller than a certain size (that is somewhat proportional to browser window length). it was about 8 mil bp when my browser was about 1000 px across.

[cmdcolin]

that is a interesting error. I am glad you found the workaround. might be worth investigating for me still...currently attending PAG conference, but thanks for the detailed report

[lyijin]

all good, no rush, thanks for looking into this. and just to clarify--only the bigWig-related tracks (QuantitativeTrack and MultiQuantitativeTrack) show this odd behaviour. the GFF3 track (AnnotationTrack) was fine regardless of how the genome was ordered.

[cmdcolin]

@lyijin we managed to find a fix for the this.ranges.map bug that you saw, it was released in jbrowse v2.10.3 (was also reported by another user here GMOD/bbi-js#59)

[cmdcolin]

thanks again for the detailed report :)