igvteam/igv.js

Question about tracks loaded with the reference genome

Closed this issue · 4 comments

We're setting up IGV.js with a track to load alongside the reference genome, as described in the wiki. The extra track is in genepred format and is indexed. Our config looks roughly like this (with some additional non-reference tracks):

{
    "reference": {
        "id": "hg19",
        "name": "hg19",
        "fastaURL": "/hg19.fa",
        "indexURL": "/hg19.fa.fai",
        "tracks": [
            {
                "name": "RefGene",
                "format": "refgene",
                "url": "/stuff.genepred.gz",
                "indexURL": "/stuff.genepred.gz.tbi",
                "displayMode": "EXPANDED",
                "order": 1
            }
        ]
    }
}

When we set up the IGV.js browser with a specific locus, it looks like it uses the indexes to load data just within some window around that locus, e.g. just for the requested gene. If, once the browser is loaded with that context, I then scroll far enough upstream or downstream from that locus, or if I search to a completely different location and zoom in far enough to see the little color bar for the reference track, it looks like IGV.js makes a new request for a different section of the reference genome in order to show the correct data for the new location. However, it doesn't seem to do this for the track I've loaded under the "reference" object in the config; if I scroll to either side of the initial locus, the track labeled "RefGene" in this example is just blank, i.e. it doesn't get updated/reloaded with data for the new window. I'm just stuck with whatever data was loaded based on the initial context I provided.

Is this the intended behavior? Assuming the reference-associated track is indexed like the reference itself, is there a way to get it to update the same way as the actual reference when I move to a different locus? In my case, the genepred file isn't huge, so I could probably omit the index from the config and just have it load the whole track to work around this, but that's not ideal.

That would be a bug, but I can't reproduce it. There is nothing special about tracks defined for the reference. If you can zip up a reproducible test case I will look into it. Do no need the fasta file just your "stuff.genepred.gz" and index file.

I can't say I've ever tried tabix indexing a genepred / refgene file but there is no reason it should not work.

You haven't set a visibilityWindow, I think it will default to -1 (load a chromosome at a time) but am not sure, but it is best to set it explicitly. This won't affect the issue you are reporting however.

Also be sure, of course, there is actually data (features) where you see the blank space.

Thanks - I'll try to put together a test case with data I can share here. And yeah, there are definitely supposed to be features in the spaces, because I can see them if I leave out the index and make it load the whole track.

sorry i never followed up on this. it appears to be fixed in 3.0, without any changes to our browser/track configuration.