JupyterGIS 0.16: a grammar of graphics for maps, and collaborative story maps

# JupyterGIS 0.16: New visualization capabilities, collaborative Story Maps, and more Source: [https://blog.jupyter.org/jupytergis-0-16-new-visualization-capabilities-collaborative-story-maps-and-more-03e6b78bacc0?gi=a031da6fa29c](https://blog.jupyter.org/jupytergis-0-16-new-visualization-capabilities-collaborative-story-maps-and-more-03e6b78bacc0?gi=a031da6fa29c) [](https://medium.com/@martinRenou?source=post_page---byline--03e6b78bacc0---------------------------------------) > Read this article in Notebook\.link, as a live story\-map\ [Earlier this year, we introduced STAC browsing and Story Maps in JupyterGIS](https://blog.jupyter.org/expanding-geospatial-workflows-in-jupytergis-stac-browsing-and-story-maps-7fb98eece82e), making it easier to discover geospatial datasets and communicate results without leaving Jupyter\. [JupyterGIS 0\.16](https://github.com/geojupyter/jupytergis/releases/tag/v0.16.0)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\ Press enter or click to view image in full size 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\. Press enter or click to view image in full size 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\. Press enter or click to view image in full size 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](https://sentinel-hub.github.io/titiler-openeo) ``` import openeofrom jupytergis import GISDocumentfrom openeo.processes import processconnection = 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) / 2ndwi_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 ``` Press enter or click to view image in full size 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 Press enter or click to view image in full size Editing an openEO process graph from the JupyterGIS front\-endAnother 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](https://jupyter-tiler.readthedocs.io/)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\. ## GetMartin Renou’s stories in your inbox Join Medium for free to get updates from this writer\. Remember me for faster sign in 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\. Press enter or click to view image in full size *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](https://quantstack.net/)was funded by[the European Space Agency \(ESA\)](https://www.esa.int/)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\)](https://cnes.fr/)for the lazy visualization of xarray datasets\. ## Contributors to this release By order of[number of contributions](https://github-activity.readthedocs.io/en/latest/use/#how-does-this-tool-define-contributions-in-the-reports): [**Arjun Verma**](https://github.com/arjxn-py)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**](https://github.com/martinRenou)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**](https://github.com/gjmooney)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**](https://github.com/MMesch)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**](https://github.com/mfisher87)is the Community Manager of[GeoJupyter](https://github.com/geojupyter)\. He contributed to many of the discussions around the release and helped shape several of the design decisions across the project\. [**Nakul Verma**](https://github.com/nakul-py)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**](https://github.com/AntoinePrv)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**](https://github.com/SandrineP)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\!