Community insight: 💃 The QGIS bounce 🕺

A common pattern: Bouncing between writing an analysis in a Notebook or scripting environment and validating work in QGIS

QGIS is a widely-loved, free, and open source graphical desktop environment for geospatial visualization and analysis. In contrast with the broad and deep ecosystem of programming-based geospatial tools, QGIS is simple to use and empowers practitioners to focus on their goals.

In GeoJupyter’s user interviews, geospatial data practitioners identified a pattern of bouncing between a scripting environment for analysis and a graphical environment for data validation.

We call this pattern 💃 The QGIS Bounce 🕺.

This pattern of transferring data between environments was represented by users as a point of repeated friction. We think we can improve on this with a tightly integrated collaborative GIS environment in JupyterLab, JupyterGIS.

🤷 How do I do 💃 The QGIS Bounce 🕺 ?

There are many variations on this general workflow. One example we heard several times looked something like this:

1. Open Jupyter Notebook in JupyterHub cloud computing environment for analysis
2. Open QGIS on local machine for validation
3. Set up QGIS project for validation:
   1. Create a new project
   2. Add a basemap
   3. Set projection
4. Write some analysis code in the Jupyter Notebook
5. 💃 Bounce 🕺 to QGIS for validation
   1. Write some code to save analysis output to disk in an interoperable geospatial file format
   2. Download the geospatial data file to the local machine
   3. Add the geospatial data file to QGIS as a new layer
   4. Use the Identify Tool and/or Attribute Table to validate the data
6. 💃 Bounce 🕺 back to JupyterLab to repeat step 4-5 until analysis is complete

😲 That’s a lot!

Yeah! 😅

Users expressed frustration with the number of repeated steps needed to complete a common and vital task: checking their work.

🤓 Why not “just” use <insert software package here>?

There are many distinct tasks involved in data validation. For example:

• Confirming that the data is correctly geolocated
• Spot-checking attributes of specific features based on their shape and location
• Spot-checking a value of raster grid cells corresponding with landmarks

Keeping up with programming-language-specific ecosystems of tools and features needed to accomplish these objectives is often not aligned with the goals of the practitioner. Using tools like QGIS helps researchers do research, helps educators educate, without unnecessary complexity getting in their way.

✨ Can we do better without leaving JupyterLab?

We’re trying! 💪

We are currently building a workflow to reduce steps 2, 3, and 5 to one line of code (not including imports 😁). For example, to view an analysis output in a GeoDataFrame:

from jupytergis import show_in_jgis

show_in_jgis(my_geodataframe)

After writing this line of code, JupyterGIS would open in a new JupyterLab window with a basemap and the analysis output loaded as layers. JupyterGIS would then allow users to verify geolocation and validate feature attributes and grid cell values, all under one roof. After validating, users would have the option to save their JupyterGIS project for future reuse!

Doing the 💃 The JGIS Bounce 🕺

Important

This is just an example. This is a work in progress and may look different when it’s done cooking.

🤝 What about collaboration?

Collaboration is critical to our vision for the future of geospatial data practice.

Because jupyter-collaboration provides architecture for real-time collaboration out of the box, and because QuantStack designed JupyterGIS’ architecture for the same, all of the workflow described above can be built to work collaboratively! Have you ever wanted a Google Docs-like collaborative experience when working on a geospatial project? Now you can!

✋ I want to help!

That’s amazing, you’re the greatest!

The GeoJupyter community is committed to building free and open source software that’s owned by its users. That’s you! 🫵 You can participate by signing up for an interview to share your expertise, opening GitHub issues to request features or report problems, chatting with us in Zulip, working directly with other community members in a virtual hackathon, and/or submitting code changes as GitHub Pull Requests.

We are looking forward to seeing you! 😄