... | ... | @@ -422,6 +422,72 @@ Note that RPC transforms will use GDAL DEM functions internally instead of using |
|
|
|
|
|
### Re-implement RPC model
|
|
|
|
|
|
#### What will change with the new model
|
|
|
|
|
|
##### Description of the current model
|
|
|
|
|
|
The current RPC model is based on OSSIM SensorModel mechanism. OTB has
|
|
|
the classes `otb::SensorModelBase`, `otb::ForwardSensorModel` and
|
|
|
`otb::InverseSensorModel` to wrap OSSIM mechanism. When provided with
|
|
|
the metadata (keywordList), it uses OSSIM's sensor model factory to
|
|
|
instantiate the sensor model corresponding to the sensor described by
|
|
|
the metadata. It can then use this model to process the transformation
|
|
|
from image to coordinates (ForwardSendorModel) or from coordinates to
|
|
|
image (InverseSensorModel).
|
|
|
|
|
|
It is interesting to note that OTB doesn't know what kind of model is
|
|
|
used. It could be a RPC model, a SAR model, or a sensor specific
|
|
|
modeling. OSSIM takes care of this point, and OTB only provides
|
|
|
the metadata and calls the *TransformPoint* function of the OSSIM model.
|
|
|
|
|
|
This classes are mainly used by the filter
|
|
|
`otb::GenericRSTransform`. The purpose of this filter is to transform
|
|
|
the coordinate from any map projection or sensor model to any map
|
|
|
projection or sensor model. It chains an inverse transformation with a
|
|
|
forward transformation, and sets the correct parameters to those
|
|
|
transformations. This filter is used by composite filters to process
|
|
|
orthorectifications or reprojections.
|
|
|
|
|
|
##### Description of the new model
|
|
|
|
|
|
As we remove OSSIM, OTB needs to take over the modeling of the
|
|
|
sensors. So we choose to separate the different kind of models, with a
|
|
|
base class `otb::SensorTransformBase`, and the inheriting classes
|
|
|
`otb::RPCTransformBase` or `otb::SARTransformBase` (and the
|
|
|
possibility to add other type of model, if needed).
|
|
|
|
|
|
We decided to use GDAL's RPC implementation to manage the RPC
|
|
|
transformations (see [this discussion](#Syntheses) ). To do so, we
|
|
|
implemented a wrapper around GDAL's RPC:
|
|
|
`otb::GDALRPCTransformer`. This wrapper is instantiated by the
|
|
|
`otb::RPCTransformBase`, and provides a *TransformPoint* function, as
|
|
|
OSSIM did.
|
|
|
|
|
|
The `otb::GenericRSTransform` filter then needs to be modified to
|
|
|
select the model corresponding to the metadata, since OSSIM is not
|
|
|
there to do it anymore.
|
|
|
|
|
|
The RPC transformer works with the new metadata framework, not the
|
|
|
KeywordList. This means every time the old SensorModel is used, we
|
|
|
need to be sure we change it with the correct model (RPC or SAR), and
|
|
|
provide the ImageMetadata instead of the KeywordList. It is easy to
|
|
|
find all the calls to SensorModel, because the compiler will complain
|
|
|
that it is not available anymore.
|
|
|
|
|
|
##### Validation strategy
|
|
|
|
|
|
The different tests for the orthorectification filters and application
|
|
|
are good validation test for this new framework. But in case of error,
|
|
|
they won't help much to find the source of the problem.
|
|
|
|
|
|
The tests for the `otb::SensorModel` classes were removed years ago,
|
|
|
because the they depended on the precision in OSSIM, that could change
|
|
|
with OSSIM's version. This was fine at this time, because the values
|
|
|
were validated in OSSIM, and the OTB part was tested in the
|
|
|
filters. But we are introducing big changes in the mechanism, and
|
|
|
tests closer to the changes are helpful to track down eventual
|
|
|
regressions.
|
|
|
|
|
|
#### DEM and RPC exclusion
|
|
|
|
|
|
The new DEM Handler uses GDAL's DEM functionalities. The new RPC
|
... | ... | |