The Jupyter notebooks in ArcGIS pro are incredibly useful. Unfortunately it's in Arcgis Pro. I'm thrilled to have the similar setup that's not tied to a slow subsription software.
Coding assistants also work pretty well at doing GIS in python.
I can see it for programmers. Here you can use industry standard python libraries (shapely, geopandas etc.). Nobody really wants to learn PyQGIS (the python interface for qgis). So while qgis is much more full featured for "desktop" gis (designed to compete with esri arcgis) i can see the use case here for people who want to build their own extensions and port code from this to other python projects more easily.
I see a few advantages. For my work in particular, I have to rely on creating desk study reports via exporting PDFs from QGIS - this depends on export DPI, page size etc. Following that I have to pull those plans into e.g. Word and it's a messy system.
A python notebook would be a nice way of generating reports of GIS data in an interactive way without being forced to use pages, PDFs, and embedded image files.
Where I work, I can't give anything is not a word document to anybody else in the company. A python notebook might help at creating the figures for example, but I can already do that with QGIS layouts.
If the working environment allows for checking/reviewing within the notebook, I guess this could help automatise things.
> Collaborative GIS Environment: Work together on geographic data projects in real-time.
What does this mean? How is it collaborative in real-time? (I don't even know how Jupyter is collaborative... as in, several people can open a Jupyter Notebook and make changes simultaneously, and things don't break for either of them?)
I've spent the past month writing a HTTP+WebSocket proxy to be used with Jupyterlab for an ESA-adjacent company, and spent a good deal of time trying to make the collaboration system work behind this proxy.
That said, I don't think my contribution is at all related to this post.
I guess things might get nasty when you try to _run_ simultaneously, unless they actually have implemented a CRDT for the whole notebook state (it would still be nasty from a usability POV, but at least it would be consistent). Just writing on the notebook would work just as any other collaborative editor out there, I expect.
Ok, you link to a deployment, and also the docs say this:
> Collaborative GIS Environment: Work together on geographic data projects in real-time.
How does that work? I can apparently make changes to the files, and even save them, but then my changes are gone when I reload it. Where were the changes saved? This is exactly what I'm wary of when using Jupyter...
> How does that work? I can apparently make changes to the files, and even save them, but then my changes are gone when I reload it. Where were the changes saved? This is exactly what I'm wary of when using Jupyter...
The GP linked to JupyterLite, which is browser-based Jupyter based on WebAssembly...
Then there is JupyterLab which runs on your own machine, or on a server somewhere (e.g. a K8S pod)...
And then there are options like JupyterHub and Kubeflow which start K8S pods for you dynamically to run JupyterLab in...
So "where is my data stored" all depends on how Jupyter is deployed... at the moment, when I use Jupyter, I'm mainly using it running inside a Docker container which in turn runs inside a K8S pod (weird way of deploying it, but I have my reasons)... and then the notebooks are stored in a volume (PVC) attached to the K8S pod (statefulset actually), but that's just temporary storage while I work on them, anything I want to keep permanently is put in Git and pushed to our corporate Git host... and then our actual datasets are mostly on S3 (or something else which speaks the S3 protocol)
JupyterGIS uses OpenLayers as its visualization backend. It runs entirely in the browser and supports GPU-accelerated rendering through WebGL when available
JGIS builds on OpenStreetMap and other open geospatial data sources as basemaps or overlays. JupyterGIS itself is a Jupyter-based interface for working with GIS data—so you can visualize, query, and process OSM or any other data directly from notebooks alongside Python tools like GeoPandas.
The Jupyter notebooks in ArcGIS pro are incredibly useful. Unfortunately it's in Arcgis Pro. I'm thrilled to have the similar setup that's not tied to a slow subsription software. Coding assistants also work pretty well at doing GIS in python.
I don't see any advantage working on JupyterGIS over working in QGIS.
Notebooks is a nice and soft way to bring a programming mindset to non-programmers.
Your actions are repeatable and can be stored in a centralized repository.
There are probably some macro abilities in QGIS (it is an amazing tool), but this means moving to "script first" from "click first".
I can see it for programmers. Here you can use industry standard python libraries (shapely, geopandas etc.). Nobody really wants to learn PyQGIS (the python interface for qgis). So while qgis is much more full featured for "desktop" gis (designed to compete with esri arcgis) i can see the use case here for people who want to build their own extensions and port code from this to other python projects more easily.
I see a few advantages. For my work in particular, I have to rely on creating desk study reports via exporting PDFs from QGIS - this depends on export DPI, page size etc. Following that I have to pull those plans into e.g. Word and it's a messy system.
A python notebook would be a nice way of generating reports of GIS data in an interactive way without being forced to use pages, PDFs, and embedded image files.
Where I work, I can't give anything is not a word document to anybody else in the company. A python notebook might help at creating the figures for example, but I can already do that with QGIS layouts.
If the working environment allows for checking/reviewing within the notebook, I guess this could help automatise things.
> Collaborative GIS Environment: Work together on geographic data projects in real-time.
What does this mean? How is it collaborative in real-time? (I don't even know how Jupyter is collaborative... as in, several people can open a Jupyter Notebook and make changes simultaneously, and things don't break for either of them?)
Yes, Jupyterlab has a collaboration extension.
I've spent the past month writing a HTTP+WebSocket proxy to be used with Jupyterlab for an ESA-adjacent company, and spent a good deal of time trying to make the collaboration system work behind this proxy.
That said, I don't think my contribution is at all related to this post.
I guess things might get nasty when you try to _run_ simultaneously, unless they actually have implemented a CRDT for the whole notebook state (it would still be nasty from a usability POV, but at least it would be consistent). Just writing on the notebook would work just as any other collaborative editor out there, I expect.
You can try JupyterGIS live on this deployment powered by JupyterLite - https://jupytergis.readthedocs.io/en/latest/lite/lab/
Ok, you link to a deployment, and also the docs say this:
> Collaborative GIS Environment: Work together on geographic data projects in real-time.
How does that work? I can apparently make changes to the files, and even save them, but then my changes are gone when I reload it. Where were the changes saved? This is exactly what I'm wary of when using Jupyter...
> How does that work? I can apparently make changes to the files, and even save them, but then my changes are gone when I reload it. Where were the changes saved? This is exactly what I'm wary of when using Jupyter...
The GP linked to JupyterLite, which is browser-based Jupyter based on WebAssembly...
Then there is JupyterLab which runs on your own machine, or on a server somewhere (e.g. a K8S pod)...
And then there are options like JupyterHub and Kubeflow which start K8S pods for you dynamically to run JupyterLab in...
So "where is my data stored" all depends on how Jupyter is deployed... at the moment, when I use Jupyter, I'm mainly using it running inside a Docker container which in turn runs inside a K8S pod (weird way of deploying it, but I have my reasons)... and then the notebooks are stored in a volume (PVC) attached to the K8S pod (statefulset actually), but that's just temporary storage while I work on them, anything I want to keep permanently is put in Git and pushed to our corporate Git host... and then our actual datasets are mostly on S3 (or something else which speaks the S3 protocol)
Looks great! What visualization backend is used? Is it GPU accelerated?
JupyterGIS uses OpenLayers as its visualization backend. It runs entirely in the browser and supports GPU-accelerated rendering through WebGL when available
Question from the ignorant, how does this relate to OpenStreetMap?
This seems to be a Python based Jupiter notebook (style?) thing for collaboratively working with GIS data/visualizations.
OpenStreetMap is a project to "map the world". In the end, OpenStreetMap provides data (and map tiles) for other things to use.
Going out on a limb (since I haven't used it) but JupyterGIS can probably make use of OSM data, along with other data sources.
Osm is a database (in the Wikipedia sense not the Postgres sense). You will be able to use osm data in this tool.
Openstreetmap is not mentioned anywhere in the JupyterGIS repo [1]. As is mentioned OSM data can be used anywhere.
[1] https://github.com/search?q=repo%253Ageojupyter%252Fjupyterg...
JGIS builds on OpenStreetMap and other open geospatial data sources as basemaps or overlays. JupyterGIS itself is a Jupyter-based interface for working with GIS data—so you can visualize, query, and process OSM or any other data directly from notebooks alongside Python tools like GeoPandas.