The default behavior is the suppression of band specific metadata when
the filter change the number of bands. Note that in a lot of cases this is the expected behavior, because the output bands information is not related to the input metadata.
#### ImageMetadataInterface
The ```ImageMetadataInterface``` classes now implement a ```parse``` method that is in charge of filling the ```ImageMetadata``` object.
The unit test for the ```ImageMetadata``` and ```ImageMetadatainterface``` classes currently use a process of writing the content of the ```ImageMetadata``` and comparing it to a file in the baseline. This is not optimal because the ```ImageMetadata``` has to be read many times in order to be sure the metadata are printed in the same order for the comparison. Later, we will implement a comparison and a "Read_From_File" method for the ```ImageMetadata``` in order to avoid having to write the metadata to a file.
#### Sentinel-1
GDAL's driver for Sentinel-1 can be found
[here](https://gdal.org/drivers/raster/safe.html) and the source code
[here](https://github.com/OSGeo/gdal/tree/ef49c00611235df0c1ce4f51344f00567a668661/gdal/frmts/safe). This
driver doesn't read all the metadata. For instance, the calibration
metadata are missing.
Options are:
- Contributing to the driver
- Implement our own metadata parser
##### Contributing to the driver
Contributing to GDAL's driver would present multiple
advantages. First, it would benefit other GDAL users how would be able
to access those missing metadata. Then, since the driver already
exists, the quantity of work to read the missing metadata should be
moderate. Moreover, using GDAL's means OTB will use GDALImageIO for
Sentinel-1 products, which is already implemented and simplifies the
processes. One drawback would be that we would need to wait until next
GDAL release to benefit from our contribution.
##### Implement our own metadata parser
Implementing our own parser would provide the OTB with a generic
metadata parser, not linked to a specific sensor. It will be
particularly useful for geom files. The implementation would be
available now, we won't need to wait for the next GDAL release. The
problem of this approach is that it would involves using a new
supplier (different from GDALImageIO), witch would be complicated to
one](https://lists.osgeo.org/pipermail/gdal-dev/2020-May/052227.html)). The
idea is to use the GDALRasterIOExtraArg argument of the RasterIO
function, by setting bFloatingPointWindowValidity to TRUE and setting
dfXOff, dfYOff, dfXSize, dfYSize.
Geoid are managed with the `GDALOpenVerticalShiftGrid` and `GDALApplyVerticalShiftGrid` function from GDAL API. The former opens a 1D raster grid as a GDAL Datasource, and the latter creates a new datasource from the raster grid (geoid) and a raster (the DEM). Vertical datums (shifts from the reference ellipsoid) are applied on the fly.
The new DEMHandler has the same API as its Ossim counterpart, in particular the following methods are provided :
* GetHeightAboveEllipsoid():
* SRTM and geoid both available: dem_value + geoid_offset
* No SRTM but geoid available: default height above ellipsoid + geoid_offset
* SRTM available, but no geoid: dem_value
* No SRTM and no geoid available: default height above ellipsoid
