Easiest way to support non-human/mouse assemblies for zoomToGene functionality

[adkinsrs]

Hello. Thanks for the awesome package. I am currently sandboxing with Gosling.js as a replacement for a now-defunct epigenome browser on our web portal. Mostly we have mouse datasets as well as human, but do have some datasets for other organisms such as chicken and zebrafish.

One of the functions that collaborators are requesting is to search our web portal by gene and have the genome browser center on that gene, which the API zoomToGene call is great for. However, from looking at the code it seems that this is only possible with human or mouse assemblies that are found on the gosling server (per https://github.com/gosling-lang/gosling.js/blob/main/src/core/utils/assembly.ts).

I was reading the HiGlass documentation on how to create gene-annotation datatypes, and have an idea or where the necessary files can be found in UCSC's download page (and it may not even be necessary since the extra assemblies appear to be supported in the negspy package, as per HiGlass documentation). But I am unsure the best way, if there is a way, to point Gosling to these files. Should i fork the code, add the assembly info to https://github.com/gosling-lang/gosling.js/blob/main/src/core/utils/assembly.ts and build a custom Gosling.js package? Would I need to start a separate HiGlass server for this? Am I overthinking the whole thing?

Thanks for the assistance
Shaun

[sehilyi]

Hi Shaun,

These are some of the options you have:

1. If you know the list of genes and their genomic ranges, you can instead use zoomTo function (Docs).

2. If you plan to set up your own HiGlass server, you can put gene annotation data into your server. While Gosling currently does not expose a user API to point to the gene annotation data (autocompleteServer and autocompleteId), we can patch Gosling to support it. In this way, you will be able to use zoomToGene functions for any assemblies that you might use.

Let me know what you think!

[adkinsrs]

Hi @sehilyi

For option 1, I do have the ability to cross-reference our own database for coordinates, so this is feasible and a good suggestion. However, I also believe that others in the future besides myself may also request option 2 for their own work, so it could be wise to add support for HiGlass servers and assemblies beyond the paths hard-coded in the aforementioned assembly.ts script. Maybe a "load assembly URL" API call with relevant autocomplete serve and id params could be sufficient? For now, I can pivot to option 1, but option 2 could be a low-priority or nice-to-have