-
Notifications
You must be signed in to change notification settings - Fork 59
Create new top-level "overview" section in docs #921
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
Integration tests report: appsharing.space |
3154520
to
53127b2
Compare
There was a problem hiding this 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**. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
docs/user_guide/how-tos/collab.md
Outdated
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). |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 :)
Description
Future PR: Roadmap page in overview section
Checklist
Resolves #XXX
.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