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

[gjoseph92]

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]

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]

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]

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 https://github.com/gjoseph92/stackstac/issues/50, maybe geoxarray someday)—currently, there's too much shared code between stackstac.show and core stackstac to really pull it out.

[davidbrochart]

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]

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]

See #45