ODD PI 26.2 Objective 7: 🌐 Client-side raster rendering (deck.gl-raster)

[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?

Description

This objective will be to establish and demonstrate what deck.gl-raster can and cannot do to assess it's value and potential impact to be included in future VEDA portals or to be more generally used as a solution for working with NASA's data client-side.

Acceptance Criteria

• An assessment of the impact, level of effort and how it fits within VEDA’s objectives

Sub-tasks

• deck.gl-raster is demoed to wider VEDA team
• Gather feedback on ADR from VEDA leads (Aimee, Brian), plugins and dashboard teams (Sijan, Simi, Gjore)
• Finalize ADR based on feedback and include an assessment of the impact, level of effort and how it fits within VEDA’s objectives
• Request go/no-go decision

[abarciauskas-bgse]

Noting, Kyle's roadmap for deck.gl-raster also includes:

• Exposing to Python through Lonboard
• Stabilizing the COG implementation on the frontend so it works with more types of COGs (e.g. COGs with an internal mask don't currently work)
• Likewise, making sure that as many COG types as possible render out-of-the box without user input
• Generic custom raster expressions. I was thinking of starting with Python, because Python users are closer to end users
• That's all before getting to Zarr. Zarr will be a huge set of work on its own. Just getting Zarr rendering will be a large task because I have to learn how GeoZarr works and how to architect the rendering so that it works across both space and time.
• Then longer term I want to ensure the custom raster expressions work for Zarr as well as COG

[kylebarron]

In the context of VEDA is it only in the context of browser apps? Is Lonboard relevant here? One nice thing about Lonboard is that (through Obstore) it can access any data with your cloud credentials that already exist in your Python environment.

[abarciauskas-bgse]

Lonboard is definitely relevant! While instance development (and specifically visualization tooling + plugins) is heavily website focused at the moment, we do want to support python/JupyterHub users as well and science users are focal to VEDA's vision to "accelerate the science lifecycle".

[maxrjones]

@abarciauskas-bgse @kylebarron should we label this issue with any repos for the automated reporting in https://github.com/NASA-IMPACT/veda-odd/pull/329/changes?

[kylebarron]

deck.gl-raster makes sense. Some adjacent work is happening in the lonboard and async-tiff/async-geotiff repos, but it's primarily in deck.gl-raster