Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
otb
otb
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 305
    • Issues 305
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Merge Requests 15
    • Merge Requests 15
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Operations
    • Operations
    • Incidents
    • Environments
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Analytics
    • Analytics
    • CI/CD
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Main Repositories
  • otbotb
  • Issues
  • #2093

Closed
Open
Created Sep 02, 2020 by Cédric Traizet@ctraizetDeveloper

Evolution of DEM handling in OTB 8.0

The otb::DEMHandler class has been refactored to use GDAL instead of Ossim to compute heights. See #1762 (closed), !729 (merged) and the wiki.

The new class is functional and replaces the old DEMHandler, renamed ossimDEMHandler.

Several evolutions are considered :

Modification of the GetHeightAboveEllipsoid method

The GetHeightAboveEllipsoid has been reimplemented to have the same behavior as the ossim DEMHandler. In case no geoid is available, the DEM height is returned. Instead, it would make more sense to return the sum of the DEM height and the default height above ellipsoid.

This change is easy to implement, however it might require to change some baseline (I am not sure how many tests are using a DEM but no geoid. I think it mostly concerns test of the otb::DEMHandler class itself).

Caching and multi-threading improvements

Currently, when requesting a height value, a 2x2 RasterIO request is made on the dem dataset. This is computationally expensive. Instead we could take advantage of GDAL caching and request data on larger region to reduce the number of request to the raster drivers.

Also, because the DEMHandler is implemented as a singleton containing a single dataset (a vrt of all input DEMs) and because a GDALDataset cannot be shared across threads, the current DEMHandler is monothreaded (using std::locks). A method that return a new vrt dataset with all dems and the geoid in the singleton could be created. This method could be used to process DEMs in a multi-threaded environment, for example in the DEMToImageGenerator class.

DEM files setup.

Currently, DEMs can be set using two different methods

  • OpenDEMFile() : add a single raster file to the list of opened DEMs
  • OpenDEMDirectory() : add all raster file in the directory to the list of opened DEMs. this is the same API as the old DEM handler.

while it is important to keep the OpenDEMDirectory method, as it is used to setup DEM in applications (elev.dem), and is wrapped in Monteverdi, the qgis-plugin, etc... Opening the whole directory can lead to opening a lot of files, for example when targeting directories with a lot of srtm tiles.

It would be nice to have a OpenDEMFiles(std::vectorstd::string> files) that only opens a list of files. We could also have smarter ways of opening DEMs, for example opening all DEMs in a directory that intersect with an input geographic region.

Remove otb::ossimDEMHandle

This class is still used to setup DEMs for ossim based RPCs and SAR model. Once they will be removed, we will be able to delete this class.

Edited Sep 02, 2020 by Cédric Traizet
Assignee
Assign to
8.1.0
Milestone
8.1.0
Assign milestone
Time tracking
None
Due date
None