Define base classes for sensor models and implement the new models
Sub-issue of #1506 (closed)
We should define base classes for sensor models (RPC, SAR, and external ones).
In order to implement progressively the new sensor models into the OTB, the work will be decomposed in 4 steps:
Implementing an interface for sensor models
Implementing the RPC model
Implementing the SAR model
Refactor the class
otb::GenericRSTransformso that it uses
Implementing a mecanisme for the integration of External models (see #2039 (closed))
Here is a description of each step:
Interface for sensor models
Interface for all sensor models in OTB (RPC, SAR and external) and associated factory that instantiates objects from image metadata (RPC sensor model from MDGEOM::RPC ...). This can be done by refactoring the
Example of class layout:
graph TD; otb::RPCTransform-->otb::SensorModelBase; otb::SARTransform-->otb::SensorModelBase; xxx::ExternalTransform-->otb::SensorModelBase;
To avoid the creation of Forward/Inverse duplicates, the transform direction can be a template parameter of
otb::SensorModelBase, or even a class attribute.
otb::GenericRSTransform should be refactored to use
ImageMetadata instead of
We could also add a small factory to instanciate the right transform:
xxx::ExternalTransform(see #2039 (closed))
The purpose of this task is to provide an API to GDAL's RPC algorithms (gdal/alg/gdalRPC.cpp).
This API will be supplied by the new class
otb::RPCModel which inherits from
otb::SensorModel. It will use the information contained in the image metadata dictionary (
MDGEOM::RPC) to instantiate GDAL's algorithms.
RPC are usually used with a DEM. GDAL's RPC API doesn't allow to directly provide a GDALDataset as DEM. This prevents us to directly use OTB's new DEMHandeler. The adopted solution is to modify the DEMHandler so it loads the DEM as a VRT in vsi memory, because the link to the DEM in the vsi memory is accepted by GDAL's RPC API.
See #2142 (closed)