Extend explore with automatic zoom to extent

[mtoernerh]

Use case

When exploring new datasets, jupytergis_lab.explore is an obvious and useful tool, but currently a GISDocument is opened viewing the whole world. You then need to manually find where the dataset is located, which makes it less attractive for a quick view of the dataset or sharing it with others.

As such, it would be a great feature to have the option to automatically zoom to the dataset. Since explore already returns a GISDocument, and latitude, longitude and zoom are input variables, it would be feasible to add this option.

Preferred solution

No response

Alternative solutions

No response

[mfisher87]

Excellent request, thank you! This could be a good feature to establish a pattern for calling out to "commands" defined in JavaScript from the Python API. Right now we don't have a good example of how to do that. @martinRenou would you recommend using jupyterlab-commands-toolkit for this or rolling our own?

[martinRenou]

I'd love that!

@martinRenou would you recommend using jupyterlab-commands-toolkit for this or rolling our own?

jupyterlab-commands-toolkit is a server extension, so it would not work in JupyterLite. Also, the Python kernel will not be able to communicate with that extension (due to the server/kernel split).

More generally, I'd like more bi-directional communication between the Python API and the front-end. The way to do this should be through Comms (the communication channel from the kernel to the front-end, it's the communication channel that ipywidgets uses a lot). e.g. we could have the front-end communicate some UI interactions as well like mouse selections.

See https://jupyter-notebook.readthedocs.io/en/4.x/comms.html, that link is quite outdated documentation but it still stands.

Note that we already use kernel comms in JupyterGIS to have Python communicate changes to the document.

[martinRenou]

This would work as follows:

1. the kernel sends a comm doc._comm.send({'type': 'gis-command', 'command': 'zoom-to-layer', 'parameters': { 'layer': layer_id }}) (doc being the GISDocument)
2. the front-end handles the comm comm.onMessage((msg) => { if (msg.type === 'gis-command') executeCommand(msg) }) (pseudo-code I don't remember the exact APIs)

The problem I see is that we don't seem to have access to the comm on the front-end easily, we may need to modify yjs-widgets https://github.com/QuantStack/yjs-widgets/blob/3e891f117969b54d15a343c64840bc4f78a35111/src/notebookrenderer/widgetManager.ts#L68 to pass the comm to the widget model. @davidbrochart what do you think?

[davidbrochart]

We handle Comm messages unconditionally if they have binary buffers, so maybe we could register message handlers and dispatch messages to these handlers based on a message type?

[martinRenou]

We handle Comm messages unconditionally if they have binary buffers

Ah, probably that it should be conditionally then. Something like msg: {'type': 'ydoc'}, buffers so that we scope the ydoc messages. Then the widget model could have access to the Comm and add any messaging on top of it.

We could get closer to ipywidgets by allowing "custom" messages: https://github.com/jupyter-widgets/ipywidgets/blob/fbc0d6e9cd63727b5951f2bf559f1a5769e4455d/python/ipywidgets/ipywidgets/widgets/widget.py#L667. These messages are not handled by the widget-state handling logic.