What software and tools will be required to support use of Sentinel-3 data at L1B and L2?

Dear ocean colour colleagues,

As member of the Sentinel-3 Mission Advisory Group (MAG) I have been asked by the European Space Agency to collect your opinions on what software and tools should be made available to the ocean colour community to facilitate usage of Sentinel-3/OLCI data. Please provide your input either via the forum or by direct email to me before end-August 2011.

BACKGROUND

The background for this is that the release of SeaDAS (http://seadas.gsfc.nasa.gov/) as free public domain software by NASA in 1997 was an enormous help to the ocean colour science community and also facilitated greatly the improvement of processing algorithms. Visibility of the source code allowed scientists both to understand fully the processing and to suggest improvements and/or contribute their own algorithms to the community.

ESA made available from 2002 free of charge to the user community the BEAM (http://www.brockmann-consult.de/cms/web/beam/) open-source toolbox and development platform for viewing, analysing and processing of remote sensing raster data, including MERIS.

In 2011 ESA released the ODESA Optical Data Processor (http://www.odesa-info.eu/info/) to provide a level 2 processing environment for the MERIS instrument including MERIS online processing, analysis tools, validation facilities and a forum for discussion.

The Sentinel-3 satellite (http://www.esa.int/esaLP/SEMTST4KXMF_LPgmes_0.html) is due for launch in 2013 as a successor to the MERIS mission, and will host the Ocean and Land Colour Instrument, OLCI, as well as the Sea and Land Surface Temperature Instrument (SLSTR), Radar Altimeter, Microwave Radiometer, GNSS receiver and Laser retroflector. ESA and EUMETSAT are preparing the Ground Segment and are now considering what software and tools should be made available to scientists and users to support use of this data. Hence this request.

SCOPE

Please send me your opinion and idea on what software and tools should be made available to support the use of the Sentinel-3 data at level 1B and level 2.

I note that I am not representing or contracted by ESA in this respect. The MAG members are not paid but act as independent unpaid scientists in response to specific technical and scientific questions raised by ESA. My role regarding this request is to collect opinions from the community and forward this to ESA in a coherent manner. I propose to do this in the form of a short public note, based on your inputs.

Your input can be provided via the forum or by email to me before end-August 2011. In general I will consider that emails sent to me on this subject are non-confidential and can be used or quoted for the summary note.

Obviously there are no guarantees that all requests to ESA will be satisfied. However, if an important tool is missing in a few years time then you may well regret not having asked for it now.

Best regards,
Kevin Ruddick,

Management Unit of the North Sea Mathematical Models (MUMM)
Royal Belgian Institute for Natural Sciences (RBINS)

My email is K<dot>Ruddick<at>mumm<dot>ac<dot>be

Kevin,

One of the most effectove decisions we made for SeaWiFS and MODIS was to store and distribute uncalibrated radiances. This allows us to continuously re-evaluate the temporal calibration model, and test alternative interpretations of the on-board calibration measurements. It also allows our users to maintain a local archive of L0 or L1A source data (downloaded once), and simply apply updated calibration code and calibration LUTs to obtain the latest L1B calibrated radiances.  To that end, user-supported calibration code and LUTs should be distributed. Ideally, the calibration code would be implemented as a library utility that could be called from other applications (e.g., l2gen in SeaDAS). This would allow processing directly from L1A to L2, without need to produce or store L1B files (i.e., the model we have for SeaWiFS).  

As you already noted, there is tremendous benefit to distribution of processing source code, as it allows the end user to understand fully the algorithms being used, and potentially implement algorithm improvements or advanced applications.  The transparency also contributes to greater trust in the derived products, and thus increased use.Further, ESA/EUMETSAT should have some mechanism to facilitate the incorporation of community-developed enhancements into distributed processing code, and ultimately into future reprocessing and distribution when warranted.

To support climate research, standard data production and distribution should include global Level-3.

L2 and L3 files should be in a self-describing format (e.g., hdf or netCDF), and existing tools (e.g., BEAM, SeaDAS) should be augmented to handle the display and analysis.

Bryan Franz
NASA Ocean Biology Processing Group

Greetings,

The data analysis tools should make the data at all levels (1,2,3) be easily exportable to other formats so that they are readable by other software. This process has always been painful with SeaDAS due to the non-friendly format of the supported ocean color products and the inability of SeaDAS to ease that process. A compatibility with free software data access libraries like gdal would definitely be a plus.

It should also be possible to more easily import into the data analysis environment external  georeferenced data (various vector and image formats) with varying projections and superimpose them on top of the supported products for rapid evaluations. SeaDAS never offered such a functionality while what VISAT can do is the strict minimum.

On the overall, a very good support for the gdal libraries would solve this problem.
Servet

Dear colleagues,

The summary report from this consultation can be found at:
ftp://ftp.mumm.ac.be/kevin/S3OLCI_SoftwareTools_SummaryReport_v1.2_MAIN.pdf
This report provides a synthesis of the contributions received (18 in total).

I note also the related initiative from
http://omel_test.coas.oregonstate.edu/home/events/2011_DOSI_Workshop_Industry_NASA.shtml

I thank all those who contributed to these recommendations and hope that these ideas will be taken onboard in the development of software and tools for Sentinel-3/OLCI.

Kevin Ruddick