I do yearn for a day though when we're using something like Marimo over Jupyter as a default for these kinds of things. Particularly in GIS where there's more utility in being able to use a notebook-like interface for an executable routine (rather than an analysis or experiment, which is (and should probably remain) the primary use case for Jupyter).
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)
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.
Looks nice. Hopefully this is one more geospatial jenga piece removed from the current
dominance of buggy, ancient closed source software like Google Earth and ESRI.
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.
I'm beyond excited to see this as a refugee from esri's products. The only reason I still use anything esri is due to their layout tools. Nightmarish as they are, it's still the best way to print or export a map to pdf. I'd like to see some advances in that area though I would bet money that Jupyter's architecture isn't adequate for those use cases.
> One of the most significant updates is a new browser-based processing toolbox powered by a WebAssembly (WASM) build of the Geospatial Data Abstraction Library (GDAL).
Since it was the ipython notebook I have only ever used jupyter locally. So my first instinct is to do it all on the backend too, but maybe they care about network latency? It looks like they're using this as a collaborative tool. So kind of like a multiplayer online video game, you don't want to waste time rendering graphics server side.
Readit News
Turning off javascript seems to fix it though.
I do yearn for a day though when we're using something like Marimo over Jupyter as a default for these kinds of things. Particularly in GIS where there's more utility in being able to use a notebook-like interface for an executable routine (rather than an analysis or experiment, which is (and should probably remain) the primary use case for Jupyter).
> 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...
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)
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".
(but you can always just use proj/GDAL at the import/export layer...)
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.
If the working environment allows for checking/reviewing within the notebook, I guess this could help automatise things.
> Available tools include:
> Buffer, Convex Hull, Dissolve, Bounding Boxes, Centroid, Concave Hull
Why would they want to calculate these from WASM in the browser instead of calling out to the Python kernel?