Skip to content
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

Interactive maps #44

Merged
merged 52 commits into from
May 5, 2021
Merged

Interactive maps #44

merged 52 commits into from
May 5, 2021

Conversation

gjoseph92
Copy link
Owner

stackstac.show and stackstac.add_to_map display Dask-backed DataArrays on ipyleaflet maps.

I took a lot of inspiration from xarray-leaflet, and originally hoped we could just use that. However, xarray-leaflet doesn't handle async concurrency and the Dask event loop as carefully as I needed, so I ended up implementing something different from the ground up. Some day maybe this could be pulled out into a separate library, but for now it lives here.

Performance is still as good as I want. It gets "stuck" for a bit, then lots of tiles come in.

  • I think Discussion: making slicing scale better dask/dask#5918 is a part of the problem; the local event loop can get bogged down generating dask graphs for each tile. An efficient blockwise/map-blocks warp would help more though (Using Dask in reprojection corteva/rioxarray#119).
  • On the distributed side, I suspect the scheduler's event loop being blocked by graph construction in update_graph_hlg is causing issues, since every time we submit a new tile to compute, it locks up the scheduler from sending back results, or scheduling tasks.
  • Also note: we're hitting Optimization turned off when using delayed dask/dask#7587 and missing some array optimizations (manually using the proper Array optimizer makes the optimize step unworkably long though).
  • I still wonder if something is blocking/screwed up with the local event loop though. The stackstac.server_stats bars can feel laggy / disconnected from what's going on

Other changes:

  • Exposed some handy spatial and miscellaneous operations in the public API (reproject_array, xyztile_of_array, etc.)
  • Exposed stackstac.mosaic! Closes Mosaicking #1.
  • Reorganized docs to have an examples subsection and base API reference page
  • Added visualization notebook from my webinar

* support non-async dask clients (launch http server on the client's event loop)
* resolve awk/bad UX of the weakref dict; do layers by name?
* proxy server
* interp-based reprojection; at a minimum don't assume 3857
* scales
still need to make some optional
is leaflet requesting the wrong XYZs now? i think something is off on the js side.
Support custom tilesizes internally, because the code feels cleaner that way. But don't expose to users, because ipyleaflet breaks.

This reverts commit 17c6420.
trying to figure out what's slowing down the compute calls.
1) we're using delayed_optimize, because the object is a delayed. should `dask.config.set({"delayed_optimize": dask.array.optimize})`
2) array_optimize is crazy slow (10x slower) because of `fuse_roots`
3) if you remove `fuse_roots`, the graph is broken. something in `optimize_blockwise` likely is counting on `fuse_roots` happening next.
don't trust any lockfiles before this
- no cancellations reported
- occasional del with refcount 1
- no initial load?
- don't actually need the released thing on TileRef, issue solved by fire_and_forget
- removing mangers on layer change isn't working
- panning to a spot where browser has cached tiles reruns computation
- maybe don't need full refcounts on TileRef, just a `requested_by_browser` flag? And then keep an LRU cache of them?
- swapping the same layer seems to fully work
- adding the same object as multiple layers breaks. need to check for this and error for now
- all tiles actually triggered on initial add to map
this only sorta works
ipyleaflet's iterative fitting was particularly bad, since it triggered tons of requests up and down zoom levels. basically the worst thing you could do here.
@gjoseph92 gjoseph92 merged commit 4029a68 into main May 5, 2021
@gjoseph92 gjoseph92 deleted the show2 branch May 5, 2021 06:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Mosaicking
1 participant