Request for Comments-44: Support of time series

[Request for Comments - 44] Support for time series

Status

• Author: Guillaume Pasero
• Submitted on XX.XX.XXXX
• Open for comments

Content

What changes will be made and why they would make a better Orfeo ToolBox?

This RFComments is a first attempt to design how OTB should handle the time information in the context of Time Series processing. There are various aspects that needs to be adressed :

1. Storing the acquisition dates on disk

It is common to work on a multi-channel image where each band corresponds to a different date. These acquisition dates should be embedded with the image:

• there is a possibility to use GDAL directly, and store the dates using a per-dataset function GDALDataset::SetMetadata(), or even a per-band function GDALRasterBand::SetMetadata(). However, GDAL documentation says that "relatively few formats return any metadata at this time". I am not sure this comment take into account the PAM mechanism (see GDALPAMDataset). If the information is stored in the aux.xml, it should be simple to get/set arbitrary metadata along with the image (to be verified). The VRT driver seems to support it as it is directly embedded in the XML syntax of the .vrt file.
• the other option is to store the dates in the .geom file. This solution is imperfect because this file is intended for OSSIM to instanciate the right sensor model. However, there wouldn't be a need for an additional file following the actual image.tif

At first sight, the first option seems the best. It will allow to store/get the acquisition dates at least for GTiff and VRT drivers.

2. Storing the acquisition dates in a otb::(Vector)Image

The internal image representation is done with otb::Image and otb::VectorImage. These objects already have a metadata dictionary. It should be easy to extend it with dedicated entries for acquisition dates. A recent example of metadata with vector type is the support of no-data values (see otbMetaDataKey.cxx). On images with sensor information, the acquisition date detected by OSSIM can be also used as a second guess when GDAL doesn't return any dates.

3. Managing date in OTB

I would suggest to use the C++ date library for this.

4. Building multitemporal-stacks

The application ConcatenateImages can be used to create these temporal stacks. There is however a small issue : filters that change the band composition will mess up the metadata information (same problem with no-data values). For instance, the current ConcatenateImage totally mess up the no-data information. Maybe we should start to think of common way to handle these "per-band" metadata (i.e. : no-data values, acquisition dates, band names and even radiometric calibration coefficients). If OTB handles properly all these metadata, there will be no blocker to create and process multi-temporal (and even with multiple spectral channels) stacks.

I propose to work on a better layout of the MetadataDictionary, something like this :

• MetadataDict
  • [ProjectionRef=...]
  • [ResolutionFactor=...]
  • ...
  • [PerBandMetadata = [
    • [BandName=... , NoData=..., Date=...]
    • [BandName=... , NoData=..., Date=...]
    • ... ]

All the filters doing multi-to-mono channel extraction and band concatenation will have to deal properly with the acquisition date. I am pretty sure they can't rely on the method otb::Image::CopyInformation(), because here we have to mix the metadata dictionary from several inputs.

When will those changes be available (target release or date)?

Those changes can be available for release 6.4 and later.

Community

Comments

List here important comments (possibly links) received.

Support

List here community members that support this RFComments.

Corresponding Requests for Changes

List here links to corresponding Requests for Changes if any.