Parsing additional query parameters

[alexpreynolds]

In addition to the config parameter, would it be possible to add functionality to parse positional data from the query string?

&uid=<viewconfuid>
&view_uid=<viewinviewconf>
&assembly=<assembly>
&chr1=<start chrom>
&start1=<start1>
&end1=<end1>
&chr2=<start chrom>
&start2=<start1>
&end2=<end1>

Perhaps some parameters are optional:

The assembly key (hg38, etc.) would be used to look up chromosome sizes, to map coordinates to higlass space. If this key is not specified, it would be extracted from the default or specified viewconf.

If uid is not specified, it may be useful to extract the default viewconf for the first view_uid key. Or, if uid is specified and view_uid is not, parse the viewconf for the first key in its view ID array.

If chr2/start2/stop2 are not specified, then they could be copied from chr1/start1/stop1.

[flekschas]

Thanks for bringing this up. There are some things to keep in mind that, which could get hairy:

1. If no assembly is specified, getting the default, requires us to define how the default is defined. Should it be the first centered heatmap? Or simply the first HeatmapTrack instances? Which view should the define the default default assembly? What shall we do when different assemblies are used in different views? HiGlass doesn't really warn about things like these.

   As a first step I could imagine just enforcing the assembly parameter and showing a message if it's missing. The second step would require some new API endpoints on the hglib side.

2. Instead of start1, end1, start2, end2 quadruples I personally find triples (pos1, pos2, zoomlevel) easier to handle, where the center is set to pos1, pos2, zoomlevel. Isn't it often more about the zoom level and less about the absolute extent of a location?

3. Right now what you propose as uid is the same as config if I understand correctly? I don't mind changing the name but I personally hate the word uid with a passion 😇 because throughout the HiGlass infrastructure we're using uid and uuid for the same thing and I never know which one to use. Also, I understood, from a user perspective, why I have to type 3 or even 4 characters when id is clear enough. Hence, I would propose calling it id 🤓. Any objections? Things I am missing / not considering?
   Could you elaborate a bit more on what <viewinviewconf> is suppose to be. Are you envisioning to be able to specify the location of several views within a viewconf at once?

[alexpreynolds]

Mainly, the motivation behind this request is to expose the functionality of the zoomTo() function via query parameters.

Instead of requiring the user to set up a higlass container object and send a zoomTo() call via Javascript, the idea is for this to be opened up via the URL.

I think the absolute genomic extent of the view is more useful for jumping to a location via the URL. The zoom level is, I think, more of a JSON property that I don't think translates to a genome range directly, or would be difficult for the end user to translate by hand. I may misunderstand what the zoom level is used for or how it translates to an extent, however.

To answer item 3, the zoomTo() call targets a specific subview of the parent view. If a parent view contains multiple views which are chained together by location and/or zoom, then the zoomTo call would only operate on one subview (if I understand correctly). So the terminology I'm using here aims to repeat the terms used in the JSON object, since that is what we are customizing (for epilogos and other multivec tracks).

[flekschas]

The motivation makes total sense but I would not replicate the functionality of zoomTo() 1-to-1. For example, I am not sure view-independent zooming via URL params are user friendly. How do I find out about the view_uid without knowing the underlying viewconf? Also, the number of parameters to parse in the URL could be pretty high. E.g., imagine a 3x2 view with 8 params each. :)

I would keep it simple and only allow setting the location for all views at once. For more advanced use cases one can use the JS API. Or simply create a viewconf that already contains the locations for every view. I chatted with Pete about this a few days ago and we looked into Google Maps which provides 3 parameters for setting a specific location: longitude, latitude, and zoomlevel (https://www.google.com/maps/@42.3765752,-71.1196475,16.27z). To me this makes a lot of sense because when I look at a loop for example and want to send its location to my friends, specifying the x-y extent can dramatically change the zoom level depending on their screen size (e.g., 27" vs a tablet) and they might not see the same pattern as I do until they adjust the zoom level.

@pkerpedjiev That makes me wonder: should update zoomTo to support centering all views to at a specific location and zoom level?

Either way, feel free to object to my ideas :)

[pkerpedjiev]

If all views are zoomed to the specified position and zoom level, then two level context-overview views would get clobbered. You would lose the differential zoom.

You're right about the view ids though. Maybe we can do something like specify the index of the view in the viewconf? So one could effectively say something like "move the 2nd view to this position". Of course we have no way of keeping track of the order of the views but it would be easier to try indexes like 0, 1, or 2 rather than uuids. The downside is that that may cause confusion with view_uuids.