Jupyter Blog - Martin Renou

JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more

2026-08-24T16:09:00+00:00

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

Earlier this year, we introduced STAC browsing and Story Maps in JupyterGIS, making it easier to discover geospatial datasets and communicate results without leaving Jupyter.

JupyterGIS 0.16 continues in the same direction. This release adds support for new geospatial formats, tighter integration with the scientific Python ecosystem, a redesigned Story Map editor, and a more expressive way to style geographic data.

Story Maps are getting a new look!

Story Maps in JupyterGIS let you build a scrollable presentation around your map. A Story Map is made up of a sequence of segments that can combine Markdown content with map views, so you can guide the reader through a geographic story as they scroll.

Each segment can define its own map state, including the current map location, visible layers, and layer styling. This means that the map can change as the reader moves through the story: layers can appear or disappear, the view can move to a new location, and symbology can change to highlight different aspects of the data.

Story Maps have received a significant update in this release.

Read this article in Notebook.link, as a live story-map! https://notebook.link/@martinRenou/jupytergis-announcement

The Story-map associated to this release annoucement. It contains Text, images, and map views with associated layer states.

A better Story Maps editing experience

We’ve also made substantial improvements to the Story Map editing experience.

The editor has been redesigned around Jupyter’s real-time collaboration infrastructure, allowing multiple people to edit the same Story Map simultaneously. Changes appear immediately for everyone, making it much easier to prepare presentations, reports, or educational material as a team.

Collaboratively edit the Story Map markdown.

The editor now gives you a much better sense of what the final story will look like while you are working on it. Markdown sections can be previewed directly in the editor, and a new Story Map preview makes it possible to see the complete presentation without leaving the editing workflow. This makes it easier to write, arrange, and refine a story while keeping an eye on the final result. We’ve also introduced a new layout that is better suited for long-form content. In addition to guided geographic narratives, Story Maps can now be used to create richer articles combining text, maps, images, and other interactive content.

New Story Map editor: Set story segment viewport, preview markdown, set layers properties for the story segment.

OpenEO layers

More and more geospatial workflows rely on remote processing instead of downloading datasets locally. openEO provides a common API to describe these processing pipelines as process graphs that are executed by a backend.

JupyterGIS can now display openEO process graphs directly as map layers. Instead of exporting intermediate results before visualizing them, you can connect an openEO backend and inspect the output of your processing pipeline directly in the map.

The visualization is tile-based and lazy: JupyterGIS only requests the data needed for the current map view and zoom level. This makes it possible to explore large remote sensing workflows interactively, without materializing the full result locally.

JupyterGIS can make use of any openEO server that supports tiling, such as titiler-openeo

import openeo
from jupytergis import GISDocument
from openeo.processes import process

connection = openeo.connect(SERVER_URL)
connection.authenticate_basic(username=BASIC_AUTH, password=BASIC_AUTH)

cube = connection.load_collection(
    "sentinel-2-global-mosaics",
    bands=["B03", "B08"],
    temporal_extent=["2022-04-15", "2022-12-31"],
)

cube = cube.reduce_dimension(
    dimension="t",
    reducer="first",
)

cube = cube / 10000.0

# NDWI = (GREEN - NIR) / (GREEN + NIR)
ndwi = cube.ndvi(nir="0", red="1")

ndwi_vis = (ndwi + 1) / 2

ndwi_png = ndwi_vis.linear_scale_range(
    input_min=0,
    input_max=1,
    output_min=0,
    output_max=255,
)

result = ndwi_png.save_result(format="PNG")

doc = GISDocument(latitude=40.75, longitude=-73.95, zoom=12)
await doc.ready()
doc.add_openeo_tile_layer(result)
doc

Define a process graph to compute a NDWI, using the Python API of OpenEO and JupyterGIS. It is then lazily evaluated on a per-tile basis while the user pans/zooms on the map.

In addition to defining openEO process graphs from the scripting Python API, JupyterGIS provides an advanced openEO process graph editor, allowing you to:

connect to an openEO tile server
define the graph graphically, with boxes and arrows
load data collections and define processes with a drag-and-drop UI
directly edit the JSON content

Editing an openEO process graph from the JupyterGIS front-end

Another interesting aspect of openEO is that process graphs have a well-defined, declarative JSON representation. Because of this structured format, they are a natural target for LLM-assisted workflows. Users can describe the analysis they want in natural language, have an LLM generate or refine the corresponding process graph (e.g. using jupyterlite-ai), and immediately visualize the result in JupyterGIS. Combined with the lazy, tile-based rendering, this makes it possible to quickly iterate on processing pipelines without waiting for complete datasets to be exported or downloaded.

Lazy visualization of Xarray datasets with jupyter-tiler

JupyterGIS now integrates with the new jupyter-tiler package, making it straightforward to visualize Xarray datasets from Python.

Datasets can come from anywhere: they may already exist in your notebook, or they can be loaded on demand from a STAC catalog using stackstac. Once you have an Xarray object, JupyterGIS can display it in the map without requiring an export to another format.

Rendering happens lazily, generating only the tiles needed for the current view. This makes it possible to explore datasets that are much larger than memory while keeping navigation responsive.

The result is a smoother workflow from data loading, to analysis, to visualization, all within the same notebook.

await doc.add_data_array_layer(
    name="NDSI Layer",
    data_array=ndsi,
    colormap_name="viridis",
    colormap_range=(-1, 1),
)

Visualizing an Xarray dataset in JupyterGIS.

This feature requires the optional dependency jupyter-tiler to be installed.

pip install jupyter-tiler

A more expressive symbology model

Styling geographic data often requires combining multiple visual properties to communicate patterns effectively.

JupyterGIS 0.16 introduces a new symbology model inspired by the Grammar of Graphics. Instead of relying on a fixed set of styling options, visual properties such as color, size, and opacity can be defined in a more flexible and composable way.

This makes it easier to build everything from simple thematic maps to more advanced visualizations while keeping styling definitions consistent and reproducible.

A symbology example: apply a Viridis color map to the circle colors, a linear scale to the radius of circles, and a fixed stroke color.

GeoZarr and GeoPackage support

This release also expands the range of formats that JupyterGIS can open directly.

Support for GeoZarr makes it possible to work with cloud-native multidimensional geospatial datasets, while GeoPackage support improves interoperability with existing GIS software and common data exchange workflows.

New Collaborative Editing Capabilities

JupyterGIS 0.16 also brings collaborative editing to vector layers. When working on a shared JupyterGIS document, multiple users can now edit the same vector data at the same time.

Features can be created, moved, and edited collaboratively, with changes synchronized in real time between users. This makes it possible to work together on tasks such as digitizing features, annotating a map, or refining a dataset without having to exchange files or manually merge changes.

Combined with the collaborative Story Map editor, this makes collaboration a more integral part of JupyterGIS: users can work together on the data itself, and then use the same shared document to explore and communicate their results.

A new R API

JupyterGIS 0.16 also introduces an R client, bringing JupyterGIS to R users through the new r-jupytergis package. The R client provides bindings for interacting with JupyterGIS widgets from an R notebook, using the same JavaScript front-end as the Python client.

The main interface is the GISDocument widget, which can be used to create and manipulate JupyterGIS documents directly from R. This makes it possible to build geospatial workflows in R while using the same interactive map interface available to Python users.

The R client also uses the same underlying collaborative infrastructure as the Python client, including the Yrs CRDT library. This means that R users can participate in the same collaborative JupyterGIS workflows rather than working in a separate environment.

doc <- GISDocument$new("france_hiking.jGIS")
layer <- doc$add_raster_layer(
    url = "https://mt1.google.com/vt/lyrs=y&x={x}&y={y}&z={z}",
    name = "Google Satellite",
    attribution = "Google",
    opacity = 0.6
)

Bug fixes and performance improvements

As usual, this release also includes many smaller improvements throughout the project.

We’ve fixed a number of bugs, improved performance in several parts of the application, and continued polishing both the user interface and the Python API.

JupyterGIS continues to evolve as a collaborative GIS environment that fits naturally within the Jupyter ecosystem. Whether your workflow starts from a notebook, a STAC catalog, an openEO backend, or a local dataset, the goal remains the same: make it easier to move between analysis, visualization, and communication without switching tools.

Acknowledgements

This work on JupyterGIS by QuantStack was funded by the European Space Agency (ESA) for the Story-maps development, the R API, openEO layers support and the collaborative labelling. Additionally, QuantStack was funded by the French National Centre for Space Studies (CNES) for the lazy visualization of xarray datasets.

Contributors to this release

By order of number of contributions:

Arjun Verma is a Developer at QuantStack. He worked on the server-side geoprocessing infrastructure and on the openEO editor in the JupyterGIS front-end.

Martin Renou is a Technical Director at QuantStack and a maintainer of JupyterGIS. For this release, Martin coordinated and guided much of the development, and worked on the integration of openEO layers.

Gregory Mooney is a Developer at QuantStack and a long-time contributor to JupyterGIS. He led much of the work on the new Story Map editor and its collaborative editing capabilities.

Matthias Meschede is Chief Operating Officer at QuantStack. He introduced the new Grammar of Graphics-inspired symbology model, bringing a more expressive and composable approach to styling geographic data.

Matt Fisher is the Community Manager of GeoJupyter. He contributed to many of the discussions around the release and helped shape several of the design decisions across the project.

Nakul Verma is an open-source contributor to JupyterGIS. He contributed numerous bug fixes and improvements throughout the release, and introduced support for Vega expressions in the new symbology system.

Antoine Prouvost is a Developer at QuantStack. He led the initial work on the R API for JupyterGIS, building its first skeleton and establishing the foundations for the r-jupytergis package.

Sandrine Pataut is a Developer at QuantStack. She worked on bringing many of JupyterGIS’s features to the R API, helping make the new client more complete and useful for R users.

We are grateful to everyone who contributed code, reviews, ideas, discussions, and feedback to this release. JupyterGIS continues to benefit from an increasingly diverse community of contributors, and we look forward to seeing what comes next!

Collaborative editing for GIS workflows with Jupyter and QGIS

2025-02-26T18:50:00+00:00

The QGIS open-source project is a cornerstone in the geosciences ecosystem, providing robust tools for spatial data analysis and visualisation. While QGIS excels in empowering researchers and engineers, the evolving landscape of geospatial research demands enhanced collaboration and accessibility, prompting a shift towards web-based technologies.

Collaboration in Jupyter

Collaboration has long been a key requirement for data science and scientific computing workflows, but Jupyter Notebooks historically lacked built-in real-time collaboration features.

To bridge this gap, the jupyter-collaboration project has focused on integrating multi-user editing capabilities directly into JupyterLab and Jupyter Notebook. This effort builds on foundational work in conflict-free replicated data types (CRDTs), leveraging technologies like Yjs, and required integration into the Notebook document model and WebSocket-based architecture.

Making Notebook code suggestions in collaboration mode with https://github.com/jupyterlab-contrib/jupyter-suggestions

This approach did not only enable collaborative editing of notebooks, but also opened the door for collaboration on other editing UIs. This was done e.g. in JupyterCAD, a 3D parametric modeler that allows multiple users to collaboratively design and manipulate CAD models within JupyterLab.

Read more about JupyterCAD here https://blog.jupyter.org/announcing-jupytercad-3-0-d8f4b7b0a719

Collaboration in JupyterCAD

Introducing JupyterGIS

Today, we are excited to announce JupyterGIS, a web-based, collaborative, and extensible interface for GIS, leveraging the JupyterLab application framework and integrating seamlessly with the Jupyter notebook interface.

JupyterGIS provides the following key features:

a JupyterLab extension for collaborative editing of geospatial data files: with COG, Shapefile, GeoJSON data source support,
support for importing, exporting and collaborating with QGIS files,
advanced analysis and editing features with an identify tool and a symbology panel approaching what QGIS provides,
easily share and deploy GIS projects using JupyterLite.

Note: JupyterGIS is not an official Jupyter subproject.

GIS features

Raster and vector layers

JupyterGIS allows you to create multiple types of raster and vector layers, including local or remote GeoTIFFs, GeoJSON, shapefiles, and tile services.

You can select from a set of pre-defined tile services in our gallery, or you can provide your own source.

Identify tool and filtering

Akin to QGIS, we provide an identify tool and filtering capabilities, helping you to inspect your datasource.

Symbology

The symbology of a layer refers to its visual representation on the map, helping you to analyze your data comfortably. JupyterGIS provides a similar feature for its raster and vector layers.

Spatio-temporal data

You can easily animate and analyze your spatio-temporal data.

Python API

Even though you can do most operations from the UI, JupyterGIS also provides a Python API enabling scripting capabilities, which can be used to process data and operate on JupyterGIS documents programmatically from a Jupyter notebook.

Collaborative features

Building upon our previous work to enable collaborative editing in JupyterCAD, we developed a shared document model to support multi-user workflows in JupyterGIS.

Everything is shared between collaborators, from layers data to symbology and filtering rules.

We also provide some collaboration features like the ability to see other collaborators’ cursors, follow collaborators’ viewports, add geolocated Google Docs-like comment conversations, and see what layer features collaborators are identifying.

Try it!

You can directly try JupyterGIS in your browser, without installing anything, thanks to JupyterLite:

https://jupytergis.readthedocs.io/en/latest/lite/lab/index.html

Documentation

Check out the Python API reference and tutorials on how to get started in our documentation:

https://jupytergis.readthedocs.io

What’s next?

We are excited to welcome new contributors and see the JupyterGIS community grow. Here are some exciting developments on our radar for the future:

Support for more data source types.
Processing tools,
Support for suggestions by collaborators, similar to the inline suggestions feature of JupyterCAD,
An improved and more featureful Python API,
A better coverage of QGIS features.

How can you support our work?

Your support is important, if you would like to help us build more exciting tools around JupyterGIS, do not hesitate to contact us on the public geojupyter Zulip channel!

Additionally, you can join us for the bi-weekly GeoJupyter hackathon on Wednesday https://geojupyter.org/calendar.html

Acknowledgments

This work on JupyterGIS by QuantStack and Simula Research Lab (Simula) was funded by the European Space Agency (ESA) for our proposal “Real-time collaboration and collaborative editing for GIS workflows with Jupyter and QGIS.”

We are also grateful to The Eric and Wendy Schmidt Center for Data Science & Environment (DSE) at UC Berkeley for funding the work of Matt Fisher on the project.

Finally, this wouldn’t have been possible without the foundational work on JupyterCAD initiated by Duc Trung Le.

About the JupyterGIS contributors

Meriem Ben Ismail is a Scientific Software Developer at QuantStack. She just completed her Software Engineering degree at INSAT (National Institute of Applied Sciences and Technology in Tunisia) and her six-month internship as an open-source scientific software engineer at QuantStack.

Nicolas Brichet is a Scientific Software Developer at QuantStack. He holds a master’s degree in robotics from the University of Montpellier. Prior to joining Quantstack, Nicolas worked for almost fourteen years in French research institutes (INRAE and CNRS), as software developer for scientific research. He also worked on different parts of the data lifecycle, such as data acquisition, analysis, and storage.

David Brochart is a Technical Director at QuantStack. David used to work in the semiconductor industry as a digital circuit designer, mostly using FPGAs. He studied telecommunications at the French “Telecom Bretagne” engineering school, with major in digital circuit design. David also worked as a researcher in hydrology at Irstea, a French scientific research institute, where he heavily used the Python scientific stack.

Matt Fisher is a Research Software Engineer and Community Manager at Schmidt Center for Data Science & Environment. Matt is passionate about open science, community-owned software, teaching and learning, accessibility, and inclusion. It is his treasured privilege to support researchers and educators in their missions by working on projects like QGreenland and JupyterGIS!

Anne Fouilloux, a Senior Research Engineer, specializes in Open Science, FAIR data, and Big Data analytics. With a PhD in Atmospheric Physics, she has contributed to Pangeo and EOSC (European Open Science Cloud), focusing on data management, Earth system modeling, and scalable computing. A strong advocate for Open Science, she advances data accessibility and interoperability to drive scientific innovation.

Greg Mooney is a Scientific Computing Developer at QuantStack. He received a Bachelors degree in Software Engineering from Arizona State University (ASU). Before joining QuantStack, he worked as an Aegis Computer Network Technician, working on the network infrastructure connecting various sensor systems onboard naval vessels.

Martin Renou is a Technical Director at QuantStack and a maintainer of Project Jupyter. Among other projects Martin is a core team member of the ipywidgets project and maintains many Jupyter widget packages such as ipyleaflet, ipydatagrid, ipygany, ipycanvas, and bqplot. He is a co-creator of the Voilà dashboarding system, and the xeus-python kernel.

Arjun Verma is a Scientific Software Development Intern at QuantStack. He is also a final year undergraduate student at Cluster Innovation Centre, University of Delhi. He loves 3D & GIS and also contributes to JupyterCAD and is one of the maintainers of PyBaMM where he has also been GSoC contributor and mentor.

Inspector JupyterLab

2022-04-11T11:50:00+00:00

JupyterLab provides multiple ways to improve your coding workflow: code highlighting, code completion, theming, debugger with rich variable rendering and more.

The JupyterLab inspector

The JupyterLab inspector is one of the ways to enhance your coding experience, it is a UI panel that provides contextual help while you are typing:

You can open the inspector using the Ctrl + I shortcut (or ⌘ + I on Mac).

With the Python kernel (ipykernel or xeus-python), this contextual help normally contains a text representation generated using the inspect Python module and the docstrings associated to an object. But there is a way to make it much nicer!

Go-Go-Gadget Docrepr

Docrepr is a Python package which renders docstrings into HTML using Sphinx, maintained by the Spyder team. IPython allows to use docrepr for code inspection, making it the perfect combination for a nice rendering of the contextual help in the inspector!

Thanks to the recent work on the jupyterlab-pygments extension, the docrepr output even respect the current JupyterLab theme for syntax highlighting!

Installation

First you will need to install the package (either with pip or mamba)

pip install docrepr jupyterlab_pygments

Or:

mamba install -c conda-forge docrepr jupyterlab_pygments

In order for IPython to use docrepr, you will need to execute the following in your Notebook (e.g. in the first cell):

ip = get_ipython()
ip.sphinxify_docstring = True
ip.enable_html_pager = True

This also can be set in your IPython configuration file located in ~/.ipython/profile_default/ipython_config.py:

c = get_config()

c.InteractiveShell.sphinxify_docstring = True
c.InteractiveShell.enable_html_pager = True

You are all set! The JupyterLab inspector will now render HTML representations of the contextual help.

Acknowledgments

Docrepr has a long history, it originates from the Sphinxify tool of the Sage project that was created back in 2009 by Tim Dumol. In 2010 Carlos Córdoba used it to power Spyder’s help pane and in 2015 he extracted that code and created the docrepr Python package, so that other projects could benefit from it. It was later integrated in IPython by Sylvain Corlay. In 2021 C.A.M. Gerlach, Ahmed Fasih and myself updated the package to support the latest Sphinx version.

My work on this project at QuantStack was funded by Bloomberg.

About the Author

My name is Martin Renou, I am a Scientific Software Engineer at QuantStack. Before joining QuantStack, I studied at the aerospace engineering school SUPAERO in Toulouse, France. I also worked at Logilab in Paris, France and Enthought in Cambridge, UK. As an open-source developer at QuantStack, I work on a variety of projects, from xtensor and xeus-python in C++ to ipyleaflet and bqplot in Python and JavaScript/TypeScript, I am also the author of several JupyterLab extensions.

Abracadabra! Bringing the magics to xeus-python

2021-02-18T13:30:00+00:00

Last year, we set ourselves to implement a visual debugger for JupyterLab. This endeavor required major developments in the JupyterLab front-end, in core-Jupyter protocols, and on the kernel side (the part of the Jupyter infrastructure responsible for executing the code).

For kernel-side development, we decided to start with the xeus-python kernel, a lightweight implementation of a Jupyter kernel for the Python programming language. Based on xeus, xeus-python has a flexible concurrency model that was required to e.g. add breakpoints while executing code.

Unfortunately, xeus-python did not provide all ipykernel features (magics, Matplotlib support, etc.). Furthermore, many notebooks depend on IPython, as they import it explicitely or make use of the IPython configuration system.

Today, we are proud to announce that xeus-python supports 100% of the IPython magics! This was achieved by leveraging the core IPython package. This is getting us closer to feature parity with ipykernel.

Magics

xeus-python now supports all magics that IPython provides and even user-defined magics!

Support for builtin IPython magics and user-defined magics

Matplotlib

Most Matplotlib back-ends are now supported by xeus-python, allowing you to show static plots with the inline back-end or interactive plots with ipympl in your Notebook:

Matplotlib inline back-end and ipympl interactive back-end

Extending

IPython has a rich configuration system that you can tweak in order to get an enhanced Notebook experience. Xeus-python now supports any configuration you setup for IPython:

Automatically import NumPy in the IPython settings

Visual Debugging

The latest JupyterLab version introduced a visual debugger in its interface. xeus-python was the first Jupyter kernel to add support for it!

Stepping into Python code in JupyterLab with the visual debugger

xeus-python is not the only Jupyter kernel that supports debugging anymore: xeus-robot is a xeus-based Jupyter kernel for the RobotFramework language that supports the JupyterLab visual debugger.

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Installation

You can install the latest xeus-python version using mamba or conda:

mamba install xeus-python -c conda-forge

conda install xeus-python -c conda-forge

You can also compile it yourself, instructions can be found in the repository:
https://github.com/jupyter-xeus/xeus-python

Acknowledgments

My work on xeus and xeus-python at QuantStack was funded by Bloomberg.

About the Author

Robotic Process Automation with JupyterLab

2021-01-18T10:36:00+00:00

Introducing a new Jupyter kernel for Robot Framework

Robotic Process Automation (RPA) differs from classical automation tools in that the actions to automate can be developed by observing a user perform a task in a graphical user interface, across multiple applications.

It is a means to lower the entry barrier of process automation and enable the use of tools that don’t provide a programmatic interface.

Most typically, RPA developers will use a mixed approach between textual programming and performing actions manually. The resulting programs are typically called software robots. Therefore, interactive computing tools like Jupyter are a natural environment for RPA, as the interactive nature of Jupyter allows for quick iterations and trial-and-errors when developing such robots.

While many RPA tools are commercial software, Robot Framework and the tooling developed by Robocorp provide an open-source RPA programming language, with a high-level syntax, extensible with Python plugins. It has a rich ecosystem of libraries and tools that are developed as separate projects.

Robot Framework and Project Jupyter

Today, we are happy to announce the first release of xeus-robot, a Jupyter kernel for Robot Framework based on xeus, supporting the new JupyterLab 3.0 visual debugger, auto-completion, and much more!

But before we dive into xeus-robot, we should recognize the earlier work by Nick Bollweg and Asko Soukka, who developed two Jupyter kernels for Robot Framework, irobotframework, and robotkernel, and gave an amazing talk together at RoboCon in 2019!

The motivation for us to reboot this effort with a kernel based on xeus was to enable the JupyterLab Visual Debugger for this kernel. This requires a different concurrency model than that of ipykernel, which underlies both irobotframework and robotkernel. In the end, we were able to provide the same features and more, including e.g. code completion in Python cells, debugging etc.

Diving into Xeus-robot

xeus-robot is a reboot of the already existing robotkernel, based on xeus.

Like most language kernels, xeus-robot supports code completion, inspection, error handling, etc. It also allows using Python cells to define custom robot keywords in Python, those Python cells support code completion as well.

Code Completion in Robot Framework

By using the libraries robotframework-seleniumlibrary and robotframework-seleniumscreenshots, you can even complete the selection of elements on the page you are currently testing!

Code completion with an action of the user in the UI.

The %%python cell magic makes it possible to extend Robotframework with Python modules in the notebook.

Extending RobotFramework with Python, and code completion in Python cells

Widget-based UIs are provided to test Robotframework “keywords”.

Testing Robot Framework “keywords” with Jupyter widgets

Last but not least, xeus-robot comes with full support for the JupyterLab Visual Debugger! After the xeus-python kernel, it is the second Jupyter kernel to support the Jupyter Debugger Protocol! We hope that many more will come.

You can set breakpoints, step in defined keywords (the equivalent of functions), inspect variables, and see the callstack, as shown below.

The JupyterLab Visual Debugger in action with Robot Framework

Installing xeus-robot

Xeus-robot is available for all platforms on conda-forge, and can be installed with conda or mamba.

mamba install xeus-robot -c conda-forge

The jupyterlab-robotmode package, which provides JupyterLab syntax highlighting for Robot Framework will also be installed as a dependency.

For your conda installation, we recommend starting from mambaforge or miniforge which are available for download here, and default to the conda-forge channel (making the -c conda-forge argument unnecessary).

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Acknowledgments

The work on xeus-robot by QuantStack was funded by Robocorp, and is part of their initiative to create an open-source RPA ecosystem. Beyond the xeus-robot kernel, Robocorp also funds the integration of Robot Framework with Visual Studio Code, RPA Framework, and other development to push the Robot Framework project forward.

The implementation of the debugger in xeus-robot relies on robotframework-lsp by Fabio Zadrozny and we want to thank him for his help in integrating it in xeus-robot.

About the authors

Martin Renou is a scientific software developer at QuantStack. He is the creator of the xeus-python and xeus-robot kernels.

Johan Mabille is a scientific software developer at QuantStack. He is a co-author of the xeus project, and developed the debugger extensions to xeus-python and xeus-robot. He also co-authored the front-end for the JupyterLab visual debugger.

ipygany: Jupyter into the third dimension

2020-10-14T09:51:00+00:00

Scientific visualization in the Jupyter notebook

From Paraview to Mayavi, there are multiple solutions for data analysis on 3D meshes on the desktop. Most of these tools provide high-level APIs that can be driven with a scripting language like Python. For example, one could control Paraview from a Jupyter Notebook. But this is not ideal as it relies on a desktop application for the rendering, which prevents using tools like MyBinder.

Nowadays, most scientists run their computation on the cloud, and they need tools for interacting and analyzing with their data.

There are already some solutions that are more integrated into Jupyter:

ipyvolume is a WebGL-based 3D plotting library for Jupyter. It has many features including multi-volume rendering.
K3D-jupyter helps you create 3D plots backed by WebGL with high-level API (surfaces, isosurfaces, voxels, mesh, cloud points, vtk objects, volume renderer, colormaps, etc).
itkwidgets is a tool for visualizing images, point sets, and meshes in 2D and 3D in Jupyter. It works by doing the rendering on the back-end and by streaming the frames to the front-end.
ipyvtk-simple is a Jupyter library for interfacing with any Python vtkRenderWindow. It relies on ipycanvas for streaming the frames to the front-end.

We needed a Paraview-like experience for Jupyter. We could provide this experience by relying on the vtk library in Python, but this means that every time you want to apply a new filter like warp-by-scalar, the Python back-end needs to send the filtered mesh to the front-end for display. This is far from ideal, as it might be hundreds of megabytes to download for every roundtrip to the back-end.

itkwidgets and ipyvtk-simple fix this issue by not sending the mesh to the page, instead, the rendering is done on the back-end and streamed to the user. This solution is, in a way, similar to using Paraview using a vnc solution. It works fine as long as you have a fast and low latency connection to the Jupyter server, and this solution scales properly with the mesh size, as the amount of data sent to the user is the same whether you analyze a fine or a coarse mesh.

Solutions like ipyvolume and K3D-jupyter can be backed by the Python vtk library (or by PyVista), but again, this means doing the mesh filtering in Python and sending the filtered meshes to the page for every change.

Today we are proud to announce ipygany! ipygany is a Jupyter widget that aims at bringing a Paraview-like experience to the webpage. With ipygany, you only send your mesh data to the front-end once, and effects such as mesh warping, contour computation, threshold filtering are directly done in the front-end and most-typically with the GPU.

Introducing ipygany

ipygany is a new interactive widgets library that allows you to visualize and analyze volumetric data in the Jupyter Notebook.

Whether your data comes from a VTK file or NumPy arrays, ipygany allows you to dynamically load your data, display them in the Notebook, and apply different kinds of visual effects on it.

ipygany provides a set of effects inspired by Paraview:

IsoColor: apply color-mapping to your mesh.
Warp: deform your mesh given a 3-D input data (e.g. displacement data on a beam)
WarpByScalar: deform your mesh given a 1-D input data (e.g. terrain elevation)
Threshold: only visualize mesh parts inside a range of data (e.g. 222 K≤ temperature ≤ 240 K)
IsoSurface: only visualize the surface where the mesh respects a data value (e.g. pressure == 3 bar)
Glyph effects like PointCloud
Water visualization
And there’s more to come!

Most of those effects are computed on the GPU only! Which makes them really fast. For example, changing the deformation factor of the Warp effect only sends one floating-point number to the GPU, and the GPU will know how to re-render the mesh (using shaders) according to the new factor value, this update is virtually instantaneous. Changing the warp factor value is technically as fast as moving the camera position, it only requires rendering a new frame.

We strive to use efficient algorithms for better performances, especially for computation that cannot be done with the GPU.

WarpByScalar: completely computed on the GPU

Effects can be easily combined for highlighting important parts in your mesh. For example, you can easily cut your mesh using the Threshold effect then apply a Warp effect for visualizing a deformation on the result.

Combining a Threshold with a Warp

All those effects are interactive widgets, they are stateful objects that you can dynamically update from Python or using widgets like sliders, text inputs, etc.

Your mesh is also an interactive widget: you can dynamically update your data, which is very useful when your data changes through time.

Visualizing an animation from two viewpoints

If you work with fluid dynamics, we even provide refractive/reflective effects and water caustics computation for nice looking visualization:

If you do Water simulation, ipygany also allows you to render you water with reflective/refractive effects and it even computes light caustics!

Installation

You can install ipygany with conda or mamba:

mamba install -c conda-forge ipygany

conda install -c conda-forge ipygany

Or you can install it with pip:

pip install ipygany

If you use JupyterLab you’ll need to install the labextension (not needed with the coming JupyterLab v3):

jupyter labextension install @jupyter-widgets/jupyterlab-manager ipygany

Documentation

You can find the documentation following this link:

https://ipygany.readthedocs.io

Try it online

Thanks to MyBinder, you can try it out without the need of installing anything on your computer. Just follow this link:

Acknowledgement

This work is led at QuantStack and founded by ERDC.

About the Author

ipycanvas: A Python Canvas for Jupyter

2019-10-25T12:48:00+00:00

As you may already know, the Jupyter Notebook and JupyterLab are Browser-based applications. Browsers are incredibly powerful, they allow you to swap rich and interactive graphical interfaces containing buttons, sliders, maps, 2D and 3D plots and even video games in your webpages!

All this power is readily made available to the Python ecosystem by Jupyter interactive widgets libraries. Whether you want to create simple controls using ipywidgets, display interactive data on a 2D map with ipyleaflet, plot 2D data using bqplot or plot volumic data with ipyvolume, all of this is made possible thanks to the open-source community.

One powerful tool in the Browser is the HTML5 Canvas element, it allows you to draw 2D or 3D graphics on the webpage. There are two available APIs for the Canvas, the Canvas API which focuses on 2D graphics, and the WebGL API which uses hardware acceleration for 3D graphics.

After some discussions with my work colleague Wolf Vollprecht, we came to the conclusion that it would be a great idea to directly expose the Canvas API to IPython, without making any modification to it. And that’s how we came up with ipycanvas!

ipycanvas: Exposing the Canvas API to IPython

ipycanvas exposes the Canvas API to IPython, making it possible to draw anything you want on a Jupyter Notebook directly in Python! Anything is possible, you can draw custom heatmaps from NumPy arrays, you can implement your own 2D video-game, or you can create yet another IPython plotting library!

ipycanvas provides a low-level API that allows you to draw simple primitives like lines, polygons, arcs, text, images… Once you’re familiar with the API, you’re only limited by your own imagination!

Draw image from NumPy array (left), implementation of the Game Of Life (right)

Draw millions of particles (left), draw custom sprites (right)

Make your own plotting library for Jupyter fully in Python!

Using Matt Craig’s ipyevents library, you can add mouse and key events to the Canvas and react to user interactions.

If you have a GamePad around, you can also use the built-in Controller widget and make your own video-game in a Jupyter Notebook!

Documentation

Check-out the ipycanvas documentation for more information: ipycanvas.readthedocs.io

Github repository

Give it a star on Github if you like it! github.com/martinRenou/ipycanvas

Try it online!

You can try it without the need of installing anything on your computer just by clicking on the image below:

Installation

Note that you first need to have Jupyter installed on your computer. You can install ipycanvas using pip:

pip install ipycanvas

Or using conda:

conda install -c conda-forge ipycanvas

About the author

My name is Martin Renou, I am a Scientific Software Engineer at QuantStack. Before joining QuantStack, I studied at the aerospace engineering school SUPAERO in Toulouse, France. I also worked at Logilab in Paris and Enthought in Cambridge, UK. As an open-source developer at QuantStack, I worked on a variety of projects, from xtensor and xeus-python in C++ to ipyleaflet and ipywebrtc in Python and Javascript.

A new Python kernel for Jupyter

2019-01-09T09:16:00+00:00

Project Jupyter aims at providing a consistent set of tools for interactive computing workflows across multiple programming languages. Jupyter projects are popular at all stages of a research project from the exploration phase to the communication of results and teaching.

The flagship project of Jupyter, the Notebook, and its modernized version, JupyterLab are web applications allowing the creation of documents including prose, executable code, and interactive visualizations.

The kernel is the part of the backend responsible for executing code written by the user in the web application. For example, in the case of a Python notebook, execution of the code is typically handled by ipykernel, the reference implementation.

History

Initially, the IPython project included everything from the notebook web application to the kernel and server implementation. Later on, the language-agnostic parts (the notebook format, messaging protocol, qtconsole, notebook web application) were split into separate projects with a clearer scope, together forming Project Jupyter.

The Big Split(TM) of IPython

Splitting IPython into multiple packages was a good decision in that it brought a clear separation of concerns between the projects. The ipykernel project was elected as the reference implementation of the Jupyter kernel protocol.

This came at a cost since ipykernel brought all the history and technical debt of IPython with it. Besides, Python is not a natural language for a base implementation. As a result, R and Julia kernels don’t use the reference implementation but use their own implementation of the protocol.

Furthermore, the standard implementation of the Jupyter Interactive Widgets lies in the Python package ipywidgets. That means that once you, as a kernel developer, implemented the Jupyter kernel protocol, you would still need to make your own backend for the interactive widgets if you want widgets support (and you should want it, honestly…).

To prevent this useless duplication of effort, which harms sustainability, we set ourselves to implement a solid reusable implementation of the Jupyter kernel protocol, xeus.

C++ implementation of the kernel protocol

Xeus is a C++ implementation of the Jupyter kernel protocol. It is not a kernel by itself but a library that helps kernel authoring. Xeus is very helpful when developing a kernel for a language that has a C or a C++API (Python, Lua, SQL, etc.). It takes the cumbersome task of implementing the Jupyter messaging protocol for you so you just can focus on the core interpreter tasks: executing code, inspecting, completing, etc.

C++ is a good choice for a standard implementation of the protocol, it is a common denominator of most of the languages out there, it has a massive developer community and is widely adopted in the industry for performance middleware applications.

With xeus, it is also very easy to reimplement core logic (server, kernel, history management etc.), if need be, by simply inheriting from xeus library classes.

Xeus is already known for being used as a base for the C++ kernel xeus-cling.

A xeus-based C++ Kernel

Xeus-cling is a xeus-based C++ kernel for the Jupyter Notebook. It’s very useful for teaching or learning C++. C++ has never been this interactive, thanks to the combined power of Jupyter, xeus, and cling. And even more impressive than executing interpreted C++, it supports interactive widgets, thanks to the xwidgets project.

Just like xeus is a C++ implementation of the Jupyter kernel protocol, xwidgets is a C++ implementation of the Jupyter Interactive Widgets protocol, and it can be used as a base for other implementations.

You can try it right now with binder, without the need of installing anything on your computer, just by clicking on this link.

Interactive C++ in the Jupyter Notebook

A xeus-based Python kernel

Today, I am pleased to announce a new Python kernel based on xeus: xeus-python.

Xeus-python supports error formatting, rich display, interactive widgets, input requests, code completion, code inspection, etc.

Thanks to xeus and pybind11, it was very straightforward to have a first simple version of a Python kernel written in C++. It took a couple of months to have the features listed above, with a relatively small amount of code (< 3000 lines of C++) and a good coverage of ipykernel’s features.

Simple code execution

Error formatting

Code completion

Ipywidgets support

Just like with xeus-cling, you can try it online without the need of installing anything on your computer following this link.

Why another Python kernel?

Obviously, xeus-python does not cover 100% of the features of ipykernel. For examples, IPython magics are not supported yet by xeus-python. However:

xeus-python is a lot lighter than ipykernel and IPython combined, which makes it a lot easier to implement new features on top of it. Our next goal is to augment the protocol to implement a Python debugger in JupyterLab.
xeus-based kernels are more versatile in that one can overload e.g. the concurrency model. This is something that Kitware’s SlicerJupyter project takes advantage of to integrate with the Qt event loop of their Qt-based desktop application.

Acknowledgments

The development of xeus, xwidgets, xeus-python, and related packages are led by QuantStack.

This development is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software Engineer at QuantStack. Before joining QuantStack, he studied at the French Aerospace Engineering School SUPAERO. He also worked at Logilab in Paris and Enthought in Cambridge. As an open source developer at QuantStack, Martin worked on a variety of projects, from xsimd, xtensor, and xframe in C++ to ipyleaflet and ipywebrtc in Python and JavaScript.

Interpreted C++ for GIS with Jupyter

2018-04-24T08:35:00+00:00

A live interactive map in a C++ Jupyter notebook

The recent release of the Jupyter kernel for C++, based on the Cling interpreter enabled a number of new workflows for the users of the C++ programming language.

Features of the xeus-cling C++ kernel for Project Jupyter include:

Showing quick-help pages for functions and classes of the STL and user-defined types, by prefixing them with a question mark:
For example, typing ?std::vector results in a pager displaying the page from cppreference on std::vector.

Quick-help page for classes and functions of the STL

Making use of the rich display features of the Jupyter stack, for user-defined types.
This can be enabled simply by overloading mime_bundle_repr in the namespace of the class for which we wish to have a rich representation in the front-end. The overload is picked up by the display system through argument-dependent lookup (ADL).

Using Jupyter’s rich display mechanism in C++

Another aspect of the newly released C++ kernel is the implementation of the Jupyter widgets protocol, enabling bi-directional communication between the front-end and the kernel.The xwidgets package, built upon xeus provides a complete implementation of the protocol, together with the implementation of most of the controls available in the reference ipywidgets Python package.

Bidirectional communication with the front-end using Jupyter interactive widgets

More than a limited set of base controls, Jupyter widgets are a framework upon which one can build arbitrarily complex interactions. A large number of interactive widget libraries has been built upon ipywidgets. Popular examples include pythreejs (a Jupyter-threejs bridge), bqplot (an interactive plotting library for Jupyter), and ipyleaflet (a Jupyter-leafletjs bridge) allowing rich interactive maps in the Jupyter notebook.

A common trait of most of these packages is that most of the logic is implemented in the front-end, while the back-end only involves synchronization of data attributes.

A fully-specified communication protocol and a thin back-end architecture facilitate the job of kernel authors willing to bring the power of these visualization libraries to their language of choice.

Hence, we have taken on the endeavor of providing a C++ implementation of the most popular Jupyter interactive widget libraries. These packages can be used in the C++ kernel, as well as in compiled application making use of the Jupyter kernel protocol.

Today, we are proud to announce the first release of xleaflet, the C++ counterpart to the popular ipyleaflet package, and which makes use of the same front-end component.

You can get started by simply creating a map inline in the Jupyter notebook.

Specifying a center location and zoom level
Specifying the tile layers to be displayed among the predefined base maps

A simple map with a specified center and zoom level, displaying the default tiles

A number of other attributes can be set in the map widget. To mimic named parameters, all widgets of xwidgets and xleaflet are provided with a generator class which can be used to initialize attributes using method-chaining syntax.

Making use of the generator class to specify any number of attributes of the map upon construction

In addition to the base map feature, a broad number of features of the leaflet JavaScript library are exposed to the C++ backend directly. This includes markers, marker clusters, image overlays, a variety of controls.

Using the marker widget

Whenever an attribute of a widget is modified in the front-end or in the back-end, the other side will properly reflect the data change.

For example, setting marker.location to a new value in the previous example will actually move the marker on the map. Reversely, if the draggable attribute was set to true, whenever the marker position changes in the front-end, the value is reflected in the C++ model.

Observer on the marker position

Another example is the support of the GeoJSON format, which allows one to load a JSON file locally and display its content on the map.

Support for the GeoJSON format

The bidirectional communication between the front-end and the C++ back-end makes it easier for the end user to create interactive web applications without having to write any JavaScript.

Using the rich features of xleaflet, one can start building fully-fledged GIS application in C++.

If you are interested in trying xleaflet right now in your web browser, we provided a binder for you.

Simply click on the following binder link and start playing with interactive GIS in C++ in your web browser:

Click on the image to launch the live demo.

Check out the documentation for more detailed information about xleaflet.

Aknowledgements

The software presented in this post was built upon the work of a large number of people including the Jupyter team, the Cling developers, the developers of xeus and xwidgets, and the developers of leafletjs.

We are especially grateful to Sylvain Corlay, Loic Gouarin, Johan Mabille, and Wolf Vollprecht.

The development of xeus, xwidgets and related packages at QuantStack is sponsored by Bloomberg.

About the Author

Martin Renou is a Scientific Software developer at QuantStack. Prior to joining QuantStack, Martin studied at the French Institute of Aeronautics and Space. As an open source developer, he worked on a variety of projects, notably SciviJS, a JavaScript library for 3-D mesh visualization.