Remove-OSSIM.md

@@ -156,7 +156,55 @@ Here is a new workflow to replace the current function
    to store the metadata.  If the parsing returns successfully, the
    generated ImageMetadata is given to the *ImageCommon* that
    propagate through the pipeline.
-   
+
+### DEM Handler
+
+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 `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 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(lon, lat):
+     * SRTM and geoid both available: dem_value + geoid_offset
+     * No SRTM but geoid available: default height above ellipsoid + geoid_offset
+     * SRTM available, but no geoid: dem_value
+     * No SRTM and no geoid available: default height above ellipsoid
+* GetHeightAboveMSL(lon, lat):
+     * SRTM and geoid both available: dem_value
+     * No SRTM but geoid available: 0
+     * 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.
+
+All raster that can be opened by gdal can be used as a geoid. In Ossim it was common to use the `egm96.grd` file as geoid, this file cannot be opened by GDAL. However it is still possible to use it by using the following `egm96.grd.hdr` file : 
+
+```
+ENVI
+samples = 1441
+lines   = 721
+bands   = 1
+header offset = 24
+file type = ENVI Standard
+data type = 4
+interleave = bsq
+sensor type = Unknown
+byte order = 1
+wavelength units = Unknown
+map info = {Geographic Lat/Lon, 1, 1,-0.125, 90.125, 0.25, 0.25,WGS-84}
+coordinate system string = {GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]}
+band names = {
+Band 1}
+```
+
+With this file attached, GDAL will be able to read the `egm96.grd` file as a ENVI dataset
+
+
 ### The new Sensor Model mechanism
 
 ```mermaid 
@@ -316,53 +364,6 @@ the OTB, based on GDAL's work.
 
 ### Re-implement DEMHandeler
 
-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 `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 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(lon, lat):
-     * SRTM and geoid both available: dem_value + geoid_offset
-     * No SRTM but geoid available: default height above ellipsoid + geoid_offset
-     * SRTM available, but no geoid: dem_value
-     * No SRTM and no geoid available: default height above ellipsoid
-* GetHeightAboveMSL(lon, lat):
-     * SRTM and geoid both available: dem_value
-     * No SRTM but geoid available: 0
-     * 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.
-
-All raster that can be opened by gdal can be used as a geoid. In Ossim it was common to use the `egm96.grd` file as geoid, this file cannot be opened by GDAL. However it is still possible to use it by using the following `egm96.grd.hdr` file : 
-
-```
-ENVI
-samples = 1441
-lines   = 721
-bands   = 1
-header offset = 24
-file type = ENVI Standard
-data type = 4
-interleave = bsq
-sensor type = Unknown
-byte order = 1
-wavelength units = Unknown
-map info = {Geographic Lat/Lon, 1, 1,-0.125, 90.125, 0.25, 0.25,WGS-84}
-coordinate system string = {GEOGCS["GCS_WGS_1984",DATUM["D_WGS_1984",SPHEROID["WGS_1984",6378137,298.257223563]],PRIMEM["Greenwich",0],UNIT["Degree",0.017453292519943295]]}
-band names = {
-Band 1}
-```
-
-With this file attached, GDAL will be able to read the `egm96.grd` file as a ENVI dataset
-
-#### 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