Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • otb otb
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 205
    • Issues 205
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 13
    • Merge requests 13
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Main Repositories
  • otbotb
  • Issues
  • #2040
Closed
Open
Issue created Mar 30, 2020 by Guillaume Pasero@gpaseroOwner5 of 5 checklist items completed5/5 checklist items

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:

  1. Implementing an interface for sensor models
  2. Implementing the RPC model
  3. Implementing the SAR model
  4. Refactor the class otb::GenericRSTransform so that it uses ImageMetadata instead of ImageKeywordlist
  5. 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 otb::SensorModelBase.

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.

The class otb::GenericRSTransform should be refactored to use ImageMetadata instead of ImageKeywordlist.

We could also add a small factory to instanciate the right transform:

  • MDGeom::RPC -> RPCParam -> otb::RPCTransform
  • MDGeom::SAR -> SARParam -> otb::SARTransform
  • MDGeom::SensorModel -> boost::any -> xxx::ExternalTransform (see #2039 (closed))

RPC model

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.

SAR model

See #2142 (closed)

Edited Nov 05, 2021 by Julien Osman
Assignee
Assign to
Time tracking