There's something wrong with the scrolling on this page, like something "puts the brakes on" (Chrome, macOS)
JupyterGIS breaks through to the next level
21–30 of 32 posts
Re: JupyterGIS breaks through to the next level
#22There's something wrong with the scrolling on this page, like something "puts the brakes on" (Chrome, macOS)
It seems like something called "nicescroll" hijacks the scrolling on the page, its compiled in the minified javascript so a bit hard to tell though.
Turning off javascript seems to fix it though.
Re: JupyterGIS breaks through to the next level
#23This looks great.
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).
Re: JupyterGIS breaks through to the next level
#24> 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 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.
JupyterLab does use CRDT via yjs (https://github.com/yjs/yjs), and the JupyterGIS collaboration system is based on the service provided by JupyterLab. So multiple users can edit the file concurrently.
Re: JupyterGIS breaks through to the next level
#25> 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).
> 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?
Re: JupyterGIS breaks through to the next level
#26> 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). > 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?
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.
Re: JupyterGIS breaks through to the next level
#27Looks 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.
Re: JupyterGIS breaks through to the next level
#28I don't see any advantage working on JupyterGIS over working in QGIS.
If you're doing primarily analytics rather than making a map, I could see how JupyterGIS might be a better choice.
(but you can always just use proj/GDAL at the import/export layer...)
Re: JupyterGIS breaks through to the next level
#29There's something wrong with the scrolling on this page, like something "puts the brakes on" (Chrome, macOS)
Drag with middle mouse button is supposed to scroll, but actually does nothing on this page.
Re: JupyterGIS breaks through to the next level
#30I'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.