Remove-OSSIM.md

@@ -254,20 +254,13 @@ the OTB, based on GDAL's work.
 
 ### Re-implement DEMHandeler
 
-The current `otb::DEMHandler` class is an adapter class for
-OSSIM DEMs. The objective is to refactor this class to use GDAL
-instead.
+Before the refactoring, `otb::DEMHandler` class was an adapter class for
+OSSIM DEMs. It provided an API to retrieve height from DEM and/or geoid using OSSIM, and was used to set up DEM and geoids to be used by OSSIM internally (which is used in OSSIM RPCs for example).
 
-The RPC transform class in GDAL accepts a path to a DEM file, which is
-then opened and used internally by the RPC class. The first idea was
-to encapsulate this class in OTB. But after investigations, it appears
-that the DEM management functions are not part of GDAL's
-API. Therefor, it is not possible to access the DEM interpolation as
-expected from the OTB.
+The `otb::DEMHandler` class is a singleton, a reference to the `otb::DEMHandler` object can be obtained via the `GetInstance()` method. This is a change of API, the Ossim `otb::DEMHandler` returned a ITK smart pointer to the singleton object. This was not a very good design, and a singleton object does not need to use the ITK memory management system. 
 
-The `otb::DEMHandler` class is a singleton, a reference to the `otb::DEMHandler` object can be obtained via the `GetInstance()` method. 
 
-The new approach is based on RasterIO. A 2x2 window is extracted around the point of interest, and the height, above ellipsoid or above mean sea level. The following methods are provided: 
+The new approach is based on RasterIO from GDAL. A 2x2 window is extracted around the point of interest, and the height, above ellipsoid or above mean sea level. The following methods are provided: 
 
 * GetHeightAboveEllipsoid():
      * SRTM and geoid both available: dem_value + geoid_offset
@@ -280,11 +273,28 @@ The new approach is based on RasterIO. A 2x2 window is extracted around the poin
      * SRTM available, but no geoid: dem_value
      * No SRTM and no geoid available: 0
 
+
 Several DEM tiles can be provided at the same time, using the `OpenDEMDirectory` method. All raster from the input directory will be opened by GDAL. A mosaic of all DEM tiles is then created as a virtual dataset (vrt).
 
 Geoid are managed with the `GDALOpenVerticalShiftGrid` and `GDALApplyVerticalShiftGrid` function from GDAL API. The former opens a 1D raster grid as a GDAL Datasource, and the latter creates a new datasource from the raster grid (geoid) and a raster (the DEM). Vertical datums (shifts from the reference ellipsoid) are applied on the fly.
 
 
+#### Initial design
+
+The RPC transform class in GDAL accepts a path to a DEM file, which is
+then opened and used internally by the RPC class. The first idea was
+to encapsulate this class in OTB. But after investigations, it appears
+that the DEM management functions are not part of GDAL's
+API. Therefore, it is not possible to access the DEM interpolation as
+expected from the OTB.
+
+#### Possible evolutions
+
+1. It has been proposed to change the behavior of the DEM handler when a DEM is available but no geoid is, currently it returns the DEM height but it could return the sum of the DEM height and the default height above ellipsoid instead. This can be done in future work.
+2. The DEMHandler performs one rasterIO on a 2x2 window (for interpolation) call for each height request. It could be optimized to call rasterIO on a bigger window to take advantage of GDAL caching, like it is done in the RPC module of GDAL. This can be done in future work.
+
+
+
 ### Re-implement RPC model
 
 ### Re-implement generic SAR model