Skip to content

Conversation

mfisher87
Copy link
Member

@mfisher87 mfisher87 commented Sep 10, 2025

Description

  • Front page
    • The front page of our docs is pretty wordy! Extract long-form content to overview section, replace with quick-to-read highlights on the front page. Add some 🔥 emojis.
    • Link to GeoJupyter website on docs front page
  • Overview section
    • Add page: "What is JupyterGIS?"
    • Move the "features" section from the user guide to the overview.
      • Move the "how-to setup up collaboration" instructions to a new how-tos section in the user guide. Cross-link.
  • Link to team compass in contributor guide

Future PR: Roadmap page in overview section

Checklist

  • PR has a descriptive title and content.
  • PR description contains references to any issues the PR resolves, e.g. Resolves #XXX.
  • PR has one of the labels: documentation, bug, enhancement, feature, maintenance
  • Checks are passing.
    Failing lint checks can be resolved with:
    • pre-commit run --all-files
    • jlpm run lint

📚 Documentation preview: https://jupytergis--921.org.readthedocs.build/en/921/
💡 JupyterLite preview: https://jupytergis--921.org.readthedocs.build/en/921/lite

@mfisher87 mfisher87 added the documentation Improvements or additions to documentation label Sep 10, 2025
Copy link
Contributor

Binder 👈 Launch a Binder on branch mfisher87/jupytergis/docs-overview-and-reorg

Copy link
Contributor

github-actions bot commented Sep 10, 2025

Integration tests report: appsharing.space

@mfisher87 mfisher87 force-pushed the docs-overview-and-reorg branch from 3154520 to 53127b2 Compare September 29, 2025 17:26
@mfisher87 mfisher87 changed the title Create new top-level "oveview" section in docs Create new top-level "overview" section in docs Sep 29, 2025
@mfisher87 mfisher87 marked this pull request as ready for review September 30, 2025 20:10
Copy link
Collaborator

@stefanv stefanv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good overall! I left some minor feedback.


# Collaborative Features

One of the standout features of JupyterGIS is its shared editing functionality, which **seamlessly connects users across different interfaces within the JupyterGIS ecosystem**. Whether collaborators are using the JupyterLab GIS extension, or working with the Python API in a Notebook, **any changes made to a shared document are instantly reflected for all users**.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "interfaces" refer to here?

Copy link
Member Author

@mfisher87 mfisher87 Sep 30, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good question, I didn't change this text, I only moved it, and I didn't write it originally :X I think what it means is the Python API in a Notebook or the actual JupyterGIS viewer, and the 2nd sentence is meant to explain that. Does that sound reasonable to you? Suggestions to clarify even further? Or do you prefer to workshop the text in a different PR?


### A reimplementation of traditional GIS paradigms

```{figure} ./jupytergis-venn-diagram.svg
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find this diagram quite confusing, FWIW 👀 What is it meant to show the reader?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well shit, that's not what I'm going for 😆

It's meant to communicate that "data analysis" is territory well-served by Notebooks, and JupyterGIS shouldn't try to "invade" that territory in the way that traditional desktop tools' "model builder" interfaces do. The right side defines two categories of things that serve analysis: the "viz/explore" layer which is similar to the functionality Notebook users might normally open QGIS to access; and the "utility" layer which connects the analysis environment and the "viz/explore" layer.

It's meant to communicate more clearly the shape of JupyterGIS as not a reimplementation of traditional GIS software in JupyterLab, instead it's an attempt to imagine a new interface that is shaped differently and tightly integrates with a Notebook as an analysis environment.

geospatial researchers find integration of visualization into their workflow to be a
much larger challenge, and this is often a reason for them to leave their Notebook
environment and open up QGIS.
While QGIS serves this need very well, the friction and mental context switching
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps this suggests that we need better in-memory bridges between QGIS and Jupyter as well; wonder if such things are feasible.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's an interesting thought. At the moment we hadn't considered such a bridge, and envisioned JupyterGIS as the target viz environment instead. It would be really cool to enable an Xarray dataset to be opened directly in QGIS, but I also don't know how feasible that might be. 🤔

introduced by working in two disjoint applications presents a definite challenge.

With these lessons in mind, we feel that our primary focus on JupyterGIS should _not_ be
on reimplimenting "geoprocessing" toolboxes, and that we should instead focus on utility
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sentence suggests that QGIS is still central to the analysis pipeline, since JupyterGIS does not want to duplicate all their functionality. Which sounds right, but how does that work?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm trying to describe the Notebook as the replacement for the QGIS / Arc "model builder" interfaces here. From interviews, many folks are very comfortable doing their analysis in a Notebook with Xarray or GeoPandas, but when it comes time to visualize the results or plan their analysis visually, they leave the Notebook to open QGIS. It sounds like I could do a much better job explaining this 😆 Ideas?

In both cases, you should forward the port of the JupyterLab instance. The default port is `8888`.

2. For a more scalable alternative, consider hosting JupyterGIS on a cloud-based or network-accessible instance. This setup allows multi-user cooperation with authentication and access restriction, without requiring a local installation. Once the instance is created using any of the options below, JupyterGIS needs to be installed on the created instance by opening a terminal window and following [the installation guide](../install.md).
2. For a more scalable alternative, consider hosting JupyterGIS on a cloud-based or network-accessible instance. This setup allows multi-user cooperation with authentication and access restriction, without requiring a local installation. Once the instance is created using any of the options below, JupyterGIS needs to be installed on the created instance by opening a terminal window and following [the installation guide](/user_guide/install.md).
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where will users find these cloud-based or network-accessible instances? If they don't know, I imagine this sentence could be rather intimidating.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was another piece of content that I only moved, didn't edit or write originally. Perhaps we could suggest some existing Hubs like CryoCloud or other 2i2c community hubs?

set -e

while inotifywait -e delete -e create -e close_write -r ${THIS_DIR}; do
${THIS_DIR}/clean.sh
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need to clean each time?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think so. But I'm not 100% sure. I copied this from another project that I worked on a few years back. Maybe it could be faster without a clean, but I imagine I learned a lesson the hard way that led to cleaning every time? Sorry I don't remember more :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation
Projects
Status: No status
Development

Successfully merging this pull request may close these issues.

2 participants