Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Ability to link web visualization to QGIS application in JupyterHub #2985

Closed
freitagb opened this issue Aug 15, 2023 · 7 comments

Comments

@freitagb
Copy link
Contributor

Context

@yuvipanda a while back we discussed a use case for VEDA/GHG where a user may be exploring data in the visualization dashboard and open that layer up in QGIS on a JupyterHub instance. This would be a really nice feature for GHG stakeholders who are more familiar with GIS applications for data exploration and it would provide a seamless transition from the GHG/VEDA dashboard into a JupyterHub instance of QGIS. For now I think we should prioritize this feature in the nasa-ghg-center JupyterHub deployment. I think this may require some coordination with the data services team here at NASA IMPACT so i've added them to the ticket for visibility and coordination .cc @j08lue @anayeaye

Proposal

No response

Updates and actions

No response

@j08lue
Copy link
Contributor

j08lue commented Aug 18, 2023

I saw the blog post on the CryoCloud solution.

I am curious to see whether we can get remote-desktop QGIS to load specific resources - either specified from the outside (JupyterHub / URL parameters like nbgitpuller) or static when QGIS loads (e.g. loading the VEDA STAC in a QGIS STAC browser plugin).

@yuvipanda
Copy link
Member

So, to generalize, the request here is two fold:

  1. Make a commandline to launch qgis that will open the appropriate visualization. This can be tested on anyone's laptop with qgis installed. I don't know qgis well enough to know if this is possible, but someone more familiar should be able to figure this out fairly easily.
  2. Add a feature to https://github.com/jupyterhub/jupyter-remote-desktop-proxy to allow running that command from a URL parameter. So the visualization can construct a URL that sends people to the JupyterHub, and eventually makes its way to this jupyter server plugin. There would need to be UI to allow the user to confirm they want to run the command (to prevent security issues), and then the backend python can simply execute that command. This would have the exact same effect as you typing the qgis command into a terminal on your laptop, and the appropriate qgis window will open up if the command is right.

This needs some but not an inordinate amount of dev work. Someone more familiar with qgis will need to figure out (1). We can help get someone up to speed on (2) and help upstream that.

@j08lue
Copy link
Contributor

j08lue commented Aug 24, 2023

Right, passing a file and, say, a map extent to QGIS should work out of the box: https://gis.stackexchange.com/a/210880

qgis FILE --extent xmin,ymin,xmax,ymax 

Not sure whether FILE can be a WMTS service (which is probably what we would like users to open), though, but perhaps one could generate a layer / project file from templates (for example like this) and somehow download that into the container and open it... 🤷

You can also execute code in QGIS Python upon load - you can probably do anything with that...

qgis --code "import something ; something.load_wmts($WMTS_URL)"

So I would agree that this is probably really simple, @yuvipanda, and maybe even a natural extension to a QGIS remote desktop proxy to expose some of the command line parameters QGIS offers?

@yuvipanda
Copy link
Member

@j08lue yeah, I think making a qgis specific proxy that works alongside https://github.com/jupyterhub/jupyter-remote-desktop-proxy is absolutely the way to go. Lets you easily add qgis specific features as we go along. I think that's better than adding a generic command execution feature to remote-desktop-proxy.

@batpad
Copy link
Contributor

batpad commented Aug 31, 2023

Trying to think about this one, and I have some broad questions before delving into specifics of implementation -

If we go with this approach, which if I roughly understand is: send the WMTS layer / data to be loaded as well as any QGIS config params as query parameters to a URL within JupyterHub. This triggers creating a container for a "desktop proxy running QGIS", starts QGIS with the user supplied parameters, and loads a webpage with Javascript to access the desktop proxy via WebVNC.

How do we handle the case of a user clicking on multiple links? I.e. I can imagine a user browsing the VEDA dashboard, and clicking on links to open them in QGIS multiple times. What happens when a user clicks a link but already has an existing QGIS session running? Do we create a new container for each time the user clicks a link? Do we need to load the dataset into the existing running QGIS session? @yuvipanda do you have thoughts here / how you see this working?

In general, am leaning toward recommending just providing good clear documentation showing a user how they can open a dataset in QGIS - so allow them to Copy the WMTS layer link, and show how one opens that in QGIS. Then it's up to the user to open that in QGIS inside JupyterHub, or a local QGIS.

Having a direct link to "Open in QGIS" that spins up a QGIS in the cloud that is right next to your data and has the data pre-loaded does sound very cool, but just want to think through potentially thorny issues here before we jump in, especially as the alternative of just providing a WMTS layer / other copy-pastable data source that users can drop into QGIS does not sound too bad to me.

Having said that, if we were to do this:

@yuvipanda could you give an example of what the URL with some parameters could look like and where one would process those parameters in the code to construct the command line parameters to send to QGIS?

I think making a qgis specific proxy that works alongside https://github.com/jupyterhub/jupyter-remote-desktop-proxy is absolutely the way to go.

Could you outline a bit more what this would involve? Creating like a jupyter-remote-qgis-proxy that is similar to jupyter-remote-desktop-proxy but specific to running QGIS?

Thanks so much for helping outline how one might implement this @yuvipanda !

@j08lue
Copy link
Contributor

j08lue commented Aug 31, 2023

Very helpful discussion of caveats and alternatives, @batpad.

In general, I am leaning toward recommending just providing good clear documentation showing a user how they can open a dataset in QGIS - so allow them to Copy the WMTS layer link, and show how one opens that in QGIS.

I generally agree. I went through the flow of opening QGIS and copy-pasting WMTS inside. It takes only a few minutes if you have done that in QGIS before - and you figured out how to copy-paste text into the VNC container via the clipboard feature. Still quite technical, but if you can work QGIS, you can probably also follow these few steps, if they are well documented.

An alternative to the parameterized launch would be to make the VEDA resources more easily available from inside QGIS. For example by installing the STAC API Browser plugin by default with the project (GHG) STAC pre-configured. Or some way to expose the available WMTS sources.

I think the direct launch of resources in virtualized QGIS would not be a power feature (for real workflows) but more of a gimmick / demo that encourages more novice users to try out loading project data in QGIS. That could still be worth the effort, of course - but we would not have to worry about "thorny issues" like how it would work when you already a QGIS container running.

@yuvipanda
Copy link
Member

Going to close this as it's tracked in the veda-jupyterhub issue (NASA-IMPACT/veda-jupyterhub#2) now. Thanks @batpad

@github-project-automation github-project-automation bot moved this from Needs Shaping / Refinement to Complete in DEPRECATED Engineering and Product Backlog Apr 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
No open projects
Development

No branches or pull requests

4 participants