Dynamic track API via genomic range (ie. skip index lookup)

[bartgrantham]

Would it be possible for igv.js to request track data based on a genomic coordinate range instead of a file's bytes range? To support this a webservice would have to synthesize and serve the gzipped track contents on the fly, as if it were an HTTP range query generated from an index lookup.

Conceptually this would actually be less work for igv.js as it's short-circuiting across the index lookup. Instead of consulting the tbi/bai/csi first to translate the genomic coordinates to a range of bytes it just calls a webservice directly with the genomic range as query parameters. The returned data would be track contents in the same form as usual (gtf/gff lines, bcf records, bam records, etc.) covering that range, and it would be the responsibility of the web service to provide the data so that it could be transparently consumed by igv.js' track drawing routines as if it had come from an HTTP range query.

An example use case for this would be an annotation track that could be configured to show or hide features dynamically, but it seems like it could be useful for any indexed track.

[jrobinso]

This is already supported, see examples/custom-webservice.html.

[bartgrantham]

Excellent! I'll take a look at that. Does it only support application/json for the contentType parameter, or can we return bcf records, bam records, etc.?

[jrobinso]

You'l have to look at the code or wait until I have time to, its all very flexible being javascript. Also look at the "custom reader" example, it is even more flexible.

[bartgrantham]

Thanks, one last question: is the JSON schema for the various track types documented somewhere? I can look in the code if necessary, but I'd prefer docs.

[jrobinso]

No they are not, and technically this is not a json schema, although simple features can be mapped directly to a flat JSON structure many are too complex for that. If you have questions about specific track types I will try to answer them here.

[bartgrantham]

I think the only ones that I'd need for now are: annotation, alignment, and variant. Thank you!

[jrobinso]

First I think I've thrown us off on a tangent, your original request to return data in a standard format is the most flexible and should be supported, surprisingly it doesn't seem to be, with the exception of the htsget protocol for bam and vcf formats. This won't be hard to implement when I find time to do so, so leave this open. I think that is the way to go.

Having said that, for annotations you can see the expected properties from the parsers in js/feature/decode, especially the "bed" parser in ucsc.js. Basic properties are

• chr
• start -- 0 based UCSC style convention
• end
• name
• strand -- optional, either - or +