Skip to content

Changes

Page history
Explain different options for RPC authored by Julien Osman's avatar Julien Osman
Hide whitespace changes
Inline Side-by-side
Remove-OSSIM.md
View page @ 53906470
......@@ -477,8 +477,6 @@ expected from the OTB.
Note that RPC transforms will use GDAL DEM functions internally instead of using `otb::DEMHandler`.
### Re-implement RPC model
#### DEM and RPC exclusion
......@@ -487,9 +485,61 @@ The new DEM Handler uses GDAL's DEM functionalities. The new RPC
model also uses GDAL and its RPC functionalities. But it doesn't
allow the use of the new DEM handler. So the OTB will work with 2 DEM
handler, both based on GDAL, but that may now function the same
way. This is why it is important to check that all applications and
filters that use both the DEM handler and the RPC model are well
tested and don't start to malfunction.
way.
##### Use OTB's DEM handler with GDAL's RPC
GDAL's API only allows to provide the path to the DEM file. So we
can't provide the new `otb::DEMHandler` to GDAL. But we can consider
other possibilities:
1. We can see with GDAL if it is possible to add a new method to their
API that would take a `GDALDataset` as input. That way, we could
use the new `otb::DEMHandler`.
2. We can re-implement the RPC using what is done in GDAL. That way,
we would not be limited by GDAL's API.
3. We can re-implement the RPC using what is done in OSSIM. That way,
we would not be limited by GDAL's API.
4. We can use GDAL's MEM functionalitie to provide OTB's DEM handler
to GDAL's API. That way, we could use the new `otb::DEMHandler`.
Here is an analyze of those options:
###### Maintainability:
Re-implementing the RPC from GDAL or OSSIM means we will be in charge
of maintaining this new piece of code. If the code for the original
projects evolves, we may have some work to do to adapt it to our
needs. In particular, in the case of OSSIM, the current implementation
of the RPC seems quite basic, witch means some evolution are to come.
###### Ownership:
On the other hand, using GDAL's API means we depend on GDAL for any
evolution. This may be a problem if we want to add some
functionalities that GDAL doesn't need.
###### Functionalities:
GDAL's implementation of the RPC is a lot more advanced than
OSSIM's. If we can benefit from GDAL's work, it will save us much work
later. In OSSIM, some part of the code are still experimental and not
optimized.
###### Syntheses
| | 1. See with GDAL for a more open API | 2. Re-implement the RPC from GDAL | 3. Re-implement the RPC from OSSIM | 4. Use MEM dataset |
|-----------------|------------------------------------------------|-----------------------------------------------------|--------------------------------------------------------------------------------|------------------------------------------------|
| Maintainability | :white_check_mark: GDAL takes care of it | :large_orange_diamond: We need to maintain the code | :red_circle: We need to maintain the code, with potentially some big evolution | :white_check_mark: GDAL takes care of it |
| Ownership | :red_circle: GDAL owns the code | :white_check_mark: We can do what we want | :white_check_mark: We can do what we want | :red_circle: GDAL owns the code |
| Functionalities | :white_check_mark: GDAL's fully functional RPC | :white_check_mark: GDAL's fully functional RPC | :red_circle: OSSIM's basic RPC | :white_check_mark: GDAL's fully functional RPC |
| Complexity | :white_check_mark: + (if GDAL approves it) | :red_circle: +++ | :large_orange_diamond: ++ | :white_check_mark: + (need to be tested) |
##### Avoid using DEM and RPC at the same time
In the case we keep 2 DEM handler, it is important to check that all
applications and filters that use both the DEM handler and the RPC
model are well tested and don't start to malfunction.
List of OTB elements using DEM handler and RPC model:
......