Challenge 14 - GPU-accelerated interactive visualization of atmospheric composition forecasts

[DiegoDomenici]

Challenge 14 - GPU-accelerated interactive visualization of atmospheric composition forecasts

Stream 1 - Data Visualization for Earth Sciences Applications

Goal

Develop a single-page web application to display a map of global atmospheric composition forecast data. The map should use client-side GPU rendering (WebGL) for maximum performance and interactivity.

Mentors

Sebastian Steinig, Miha Razinger (all ECMWF)

Skills Required

• Frontend web development in JavaScript (React) is essential
• Experience or interest in WebGL data visualization is desirable
• Experience or interest in processing geospatial data (Python/xarray, Zarr) is desirable

---

Description

The Copernicus Atmospheric Monitoring Service (CAMS) provides daily global atmospheric composition forecasts of pollutants, aerosols and greenhouse gases. CAMS products are widely disseminated to the public through web applications and ECMWF's own web maps, providing quality-controlled information on air pollution and health to users worldwide. However, changes in composition and associated potential health impacts are often local or regional events. The current static web maps with limited user customisation can therefore make it difficult to effectively communicate these events to the public.

The aim of this project is to explore the possibility of creating CAMS visualisations directly in the browser, allowing users to interact with the underlying data and modify the visualisation in real time to suit their needs. Rather than fetching pre-generated maps from a server, the new application should download the underlying raster data itself for subsequent client-side rendering of the visualisation. Modern web APIs such as WebGL allow GPU-accelerated processing and mapping of the raw data to create responsive and engaging 2D and 3D map visualisations of global datasets see examples. We would like to test this exciting possibility by creating a single-page web application that gives users interactive and intuitive access to CAMS forecast data for any location in the world.

The necessary work in this project can be split into two parts:

1. Data preparation: First, the forecast data needs to be converted into a format which can be served to the browser and the WebGL API. Forecast data can be programmatically retrieved from the Atmosphere Data Store in GRIB or netCDF format. This input data should be converted to a cloud optimized format (e.g. Zarr or GeoTIFF/COG) to allow efficient access and streaming of data subsets via the browser. Complete workflows on how to convert GRIB data to Zarr stores are available from Google and CarbonPlan. Depending on your interests you could either implement a workflow for a single format, compare performance of different solutions or directly start with existing CAMS Zarr example data which can be provided by the mentors.

2. Data visualisation: We anticipate that most of the project time will be spent on developing the frontend visualisation, which should use the JavaScript React library. We can provide a React app template and component library to simplify development and to allow future reusability of the new WebGL map component within the ECMWF app ecosystem. As a minimum, the map should be able to display global fields of several CAMS forecast variables (e.g. air pollution, dust or greenhouse gases) with a time slider to select different forecast time steps. The user should be able to pan and zoom freely within the map and click on any point to get a time series of forecast values for that location.

The main challenge will be to pass the forecast data to the GPU and render it efficiently. The amount and complexity of any WebGL development work within this project can be tailored to the interests and expertise of the applicants. As a start, an existing open-source library to render interactive maps directly from a Zarr dataset could be adapted to fetch and display the CAMS data, therefore providing a possibility to start learning about client-side GPU rendering. A probably more challenging solution could be to develop a custom raster layer on top of the widely used deck.gl library (see links for more information and example code for this approach).

Please remember that the selection process will not simply be based on the complexity of the proposal, but rather on the feasibility of deliverables given the previous experience of applicants. Support and advice from the mentors for learning or experimenting with any new technologies will be available throughout the project.

Figure 1: Example of WebGL-based interactive visualisation of 10m winds. Source: https://weatherlayers.com/

---

Evaluation Criteria

• Feasibility
• Innovative approach
• Transferability
• Matching requirements

[JoachimKoenigslieb]

Hi,

I'm wondering why the skills required mentions React specifically?

The webGL rendered map itself would surely not be a React app but use webGL primitives.

Is creating bindings to React a core part of the challenge? If ECMWF internals are React based this would make a lot of sense.

There is a lot of noise about server rendering and server components currently in the React community. Would such a solution be interesting for ECMWF?

It does require some quite serious infrastructure buy-in.

[sebsteinig]

Hi @JoachimKoenigslieb,

Thanks a lot for your interest and your questions.

ECMWF launched a lot of exciting new application recently which use interactive maps to allow users to explore specific data sets directly in the browser. Some examples to give you a flavour of how they look are the Methane hotspot explorer or the ERA explorer app. They both use a similar architecture built on React and the Mantine component library.

The map components in these two apps already use different technologies (leaflet, D3.js) and the idea of this challenge is to explore another alternative for creating an interactive visualisation of our data, by using a WebGL-based rendering of the map and atmospheric composition data. Each mapping solution has its own pros and cons and potentially different use cases in the future. Ideally, the outcome of this challenge is therefore to develop a new React WebGL map component which integrates into the existing ECMWF component ecosystem to be reusable in other applications in the future. This is the reason why some experience with React is listed in the required skills.

It is not required to be able to develop a solution using WebGL primitives. There are already existing, higher level solutions using e.g. mapbox-gl-js and regl or deck.gl which could be used for this project to speed up things. The main idea of this challenge is to explore how we can make these exciting technologies work with our datasets to provide even better access to them for users.

I think server-side rendering and server components are outside of the scope of this challenge as the overall project length and infrastructure resources are limited, but feel free to outline how these technologies could be integrated into your proposed solution in the future.

I hope this helps a bit and you are still interested in submitting a proposal 😄. Please let me know if you have any more questions.

Best wishes,
Seb

[JoachimKoenigslieb]

Hi Sebastian,

This makes a lot of sense! A big part of the challenge is in the interop then!

I'll try to dig around and see how your current pipeline accesses the raw forecasts.

Another angle I think could also be very interesting to be able to visualise grib files directly. This might be quite a mouthful (at least for the full standard...), but even a specialised implementation on just the CAMS datasets could skip a cloud-level decode step.

This could even be used generally. Currently I always go through Panoply for visualising grib files, but that has a distinctive "last decade" feel. (Zoom and pan is borderline broken)

I think this challenge is very interesting! I'll definitely write some proposal, and will try to keep it focused and reasonable in the timeframe!

[JoachimKoenigslieb]

Hi Sebastian,

I've taken a look at the available examples now. They all seem to use a pipeline of reading from zarr files.

I think a solution of reading grib2 files directly could be very interesting. There is some prior art for having a grib decoder in javascript (https://github.com/BlueNetCat/grib22json and others). I think this has a very nice upside of having less requirements on the backend system: Potentially creating a very portable React component that could be plugged in just about everywhere!

The downsides would be that we cannot leverage the zarr "pyramids" to efficiently fetch only the very zoomed-out parts. But I think this trade-off could still be very interesting.

My plan for a proposal is (very roughly) to:

1. Read grib files directly and parse in the front-end. Potentially levering range headers in fetch to only get sub-parts of the fields. (This would obviously require some pre-calculated indexes...)
2. Render the decoded grib data to screen with deck.gl. Here we probably have to write some custom layer code. It looks like the bitmap layer (https://deck.gl/docs/api-reference/layers/bitmap-layer) would be a good starting point. I expect that this step will take the majority of the effort.
3. Integrate into a POC with the ECMWF React apps.

Do you think this approach could be of interested to you guys? It is a bit more experimental, so maybe you want to stick to the netCDF/grib -> zarr/geoTIFF -> render to webGL pipeline?

[sebsteinig]

Hey Joachim,

Thanks a lot for your ideas!

My recommendation would be to focus on so called "cloud-optimized" file formats like Zarr or GeoTIFF (see e.g. https://guide.cloudnativegeo.org) for this challenge. Developing a GRIB decoder for the browser would be a major undertaking on its own, while we anticipate to spend more time on exploring the possibilities (and maybe limitations) of combining the cloud-optimized data formats with client-side rendering.

Zarr datasets are currently being created for different ECMWF products and also allow quick access to e.g. time series data (see section on Zarr here). They are therefore likely a more efficient way of transferring (subsets of) data to the browser for our use case. Cloud-optimized GeoTIFFs (COG) on the other hand might be easier to directly render with deck.gl (see examples here or here. We would be happy about any development towards finding out whether either (or both) of them can help us creating better visualisations of our data 😃.

Best of luck with writing your proposal.

Best wishes,
Seb

[JoachimKoenigslieb]

Hey,

It actually turned out it was sort-of possible to do the "direct-from-grib" method. There is an example live on my blog:
https://joachimkoenigslieb.github.io/blog/posts/Vizualising-GRIB-files-in-the-browser

Probably a good call not to pursue this. I think there GRIB2 decoder I used here is pretty... minimalistic. Lots of codepaths are throwing errors, no types etc.

Could be an interesting challenge for next year to write a WebAssembly GRIB2 decoder tough....

Best regard, Joachim Kønigslieb

[zakjan]

Hi, author of WeatherLayers here. Thanks @sebsteinig for letting me know about this thread. Feel free to use the library for your visualization needs. There should be no blockers since it has been open-sourced. Don't hesitate to reach out to me if you have any questions or suggestions!

Especially I appreciate the effort in trying out the approach to parse GRIB in the browser. If there were a well-maintained JS GRIB parsing library, it would remove the need for any preprocessing server. WeatherLayers GL supports any format as input as long as you can handle the decoding.