ODD PI 26.3 Objective 7: 🌐 Browser-based visualization + analysis

[abarciauskas-bgse]

Motivation

Current dynamic tiling methods rely on tiling APIs, which require data access and standard service maintenance and operations. While powerful, tiling APIs are additional complexity in the stack which may not need to exist!

deck.gl-raster has already demonstrated that client-side rendering of geospatial datasets is possible. It offers the additional following benefits:

• being a client-side library, it can render data without a server. You can point it at any compliant data URL and it should "just work"
• it can reproject data on the client
• it uses the raw data, so can be a more scientific tool. It can be used for common geospatial pre-processing (applying a bitmask) and analytics (computations on the data, like combining bands and variables)

Known limitations:

• data must be publicly accessible (not the case for lonboard integration!)

Acceptance Criteria

• Demonstrate deck.gl-raster in documentation (proposal: with sentinel-2 as time series, using lazycogs and zarr-datafusion-search?)

• Expand capabilities of deck.gl-raster

  • Initial GeoZarr support in deck.gl-raster
  • Initial GeoZarr support in Lonboard which will enables access to data user’s python environment has access to
  • Make progress towards generic GPU-based styling of Zarr visualizations through Lonboard. This Python library to translate into WebGL bandmath, which could be exported to a static website

• Stretch: Coordinate with plugins on deck.gl-raster layer

LOE

0.5 FTE

Dependencies

Any instances that may want to use this technology