The EGU General Assembly always is a great opportunity to both show your science and catch up with the latest scientific findings. EGU2019 was no exception. The MULTIPLY team was offered the opportunity to present various developments. I had the chance, on behalf of the Assimila and UCL-Geography teams, to present the use of MODIS and Sentinel-3 OLCI data to better characterise the land surface. What’s the result of combining MODIS and OLCI observations? The MOLCI.
The highlight of the week for me however, was the hands-on MULTIPLY experience session. The main goal of the almost 2 hour session was to demonstrate the MULTIPLY platform and provide some theoretical background about Radiative Transfer (RT) models such as:
- the JRC-TIP;
- the integration of a priori knowledge when retrieving land surface parameters, e.g. Leaf Area Index (LAI); and ultimately,
- how to combine observations and prior information in a Bayesian scheme.
Great lecture, really well done Joris!.
The hands-on started…… and the challenges started. When you have a reasonably good processing server, performing an atmospheric correction of one Sentinel-2 MSI image using the marvellous Sensor Invariant Atmospheric Correction (SIAC) approach developed by the UCL-Geography group, everything runs smoothly. When you have 10 simultaneous processes, performance starts to slows down. This brings an interesting question, namely: you, as a user of the platform, where do you want to run your processing? Where can you do it? Would you pay for it if needed? In MULTIPLY we will address this in the near future. However this is a common issue nowadays. There are multiple cloud-computing providers with access to Earth Observation data. Perhaps the most used one being the Google Earth Engine (GEE), where you do some actual processing. Nevertheless GEE’s web code editor uses Java Script to do the processing. We don’t want to develop a RT model in Java Script. You can use its Python Application Programme Interface (API) but then the computing power will be yours, not the GEEs. Hence, the GEE is a great tool to perform some tasks but not necessarily to perform atmospheric correction of Sentinel-2 data and retrieve biophysical parameters. At least not yet.
Then, we showed some more Jupyter Notebooks. The hardcore ones we used in the platform. They brought some more interesting questions such as: “can I use my own priors?” and “could it be possible to use a different RTM?”. Basically the answer is, “yes” and “yes”. We are trying to develop the platform being as flexible as possible. In the end, if you are a scientist who knows your area of study, it doesn’t matter if it’s a micro-basin in the middle of the Amazon or a set of agricultural fields in East England. You know the characteristics of the area, you have a broad expectation of what the outputs would be. In MULTIPLY we want to take advantage of this knowledge. Hence, it’d be possible to use your RTM model of preference, create some emulators so it can run super-fast (the scientific world will always be thankful for this Jose!) and use it within the Data Assimilation MULTIPLY inference engine, KaFKA. Obviously, it won’t be that straightforward as it sounds: you might need some help of the MULTIPLY team (in exchange of food or beer) but the point is: it is possible. Right now we have three different RTMs that take different inputs, from broadband albedo to narrow band reflectance and microwave backscatter. Additionally, if you know the inputs of the RTM, you can create your own priors. In the end a prior is only the probability distribution where you can express your belief about a specific quantity before any observations are taken into account.
After two hours of lecture and Python and plots and logfiles and questions and answers, it was clear that the MULTIPLY project is facing a great challenge and providing some solutions. But we are still short as an Earth Observation scientific community to embrace the use of multi-sensor products, rather than relying on a per-sensor product and to use uncertainties along a whole processing chain, all the way from the sensor observations to biophysical parameters. Therefore our task within MULTIPLY is to widen even more our scope to show, particularly early-career scientists that, this approach can make the most of all available observations and provide an uncertainty, a sense of how good the retrieval is. Once again EGU2019 was great but the best part was the chance to interact with scientists, looking to make a difference using Earth Observation data. And of course, the MULTIPLY Platform will be there to help them.
