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

'LeafletMap' object has no attribute 'base_url' in JupyterLab #42

Closed
gjoseph92 opened this issue Mar 20, 2021 · 6 comments
Closed

'LeafletMap' object has no attribute 'base_url' in JupyterLab #42

gjoseph92 opened this issue Mar 20, 2021 · 6 comments

Comments

@gjoseph92
Copy link

It seems that inferring the base URL is failing for me in JupyterLab 3.0.12.

The .window_url of my map is 'http://localhost:8888/lab/workspaces/auto-s/tree/nb/leaflet.ipynb', which doesn't match the .endswith("lab") logic trying to identify JupyterLab. Maybe the URL scheme has changed recently?

I'm imagine missing something here, but is the goal of the "find the base URL" logic to figure out the URL of the Jupyter server? In that case, would something like

url = urllib.parse.urlparse(m.window_url)
self.base_url = f"{url.scheme}://{url.netloc}"

work for all the cases in general?

@peterhob
Copy link

Following @gjoseph92 's suggestion, I changed the relevant code in the xarray_leaflet.py and it is now finally working in my Jupyterlab (3.0.16).
Thank you @gjoseph92. Saved my day trying to figure out what went wrong in my conda environment.

@davidbrochart
Copy link
Collaborator

I'm imagine missing something here, but is the goal of the "find the base URL" logic to figure out the URL of the Jupyter server? In that case, would something like

url = urllib.parse.urlparse(m.window_url)
self.base_url = f"{url.scheme}://{url.netloc}"

work for all the cases in general?

Sorry for not replying earlier @gjoseph92, in your particular case self.base_url would be http://localhost:8888 if I use your logic. What we need is the Jupyter Server base URL, because the tiles are served by the Server. So your suggestion wouldn't work when used through Binder for instance, because it adds a prefix to the URL.

The current implementation is wrong, but I couldn't come up with an acceptable solution yet. If you have ideas, please don't hesitate to share.

@gjoseph92
Copy link
Author

Correct, what I posted doesn't work in generality (particularly Binder). For stackstac, I ended up going with this regex which works fine, though I don't love that it's specific to lab/notebook/voila. Seems like the most correct approach would be to pull it from the NotebookApp.base_config option, or from the frontend.

Also @davidbrochart you might be interested in stackstac.show. I took a bit of inspiration from xarray-leaflet, though the implementation is more optimized for concurrency with dask. At some point I'd like to pull this into a separate package and maybe combine with xarray-leaflet, but that's not realistic until there's some package to put common xarray geospatial operations in (xref gjoseph92/stackstac#50, maybe geoxarray someday)—currently, there's too much shared code between stackstac.show and core stackstac to really pull it out.

@davidbrochart
Copy link
Collaborator

Thanks for sharing your work on stackstac, it looks interesting!
Looking at the limitations about visualization, I can see that "resolution doesn’t change as you zoom in or out". I'm not sure what this means, isn't the data somehow aggregated, as it is in xarray-leaflet?

@gjoseph92
Copy link
Author

Ah no, all I meant is that

zooming in and out will not load underlying data at different resolutions. Assets will be loaded at whatever resolution you initially got from stack. If your array is large and high-resolution, zooming out could trigger very slow (and expensive) computations.
https://stackstac.readthedocs.io/en/latest/api/main.html#visualization

This is a limitation of xarray-leaflet as well. It should be possible to get around with some clever dask graph rewriting, but I won't get to that for a while.

@davidbrochart
Copy link
Collaborator

See #45

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants