otb issueshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues2021-02-10T07:39:09Zhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2136RFC: Enable `zstd` support in SuperBuild2021-02-10T07:39:09ZLaurențiu NicolaRFC: Enable `zstd` support in SuperBuild### What changes will be made and why they would make a better Orfeo ToolBox?
ZSTD is a modern compression format that offers compression ratios comparable with `zlib`, but faster compression and decompression speeds: https://engineerin...### What changes will be made and why they would make a better Orfeo ToolBox?
ZSTD is a modern compression format that offers compression ratios comparable with `zlib`, but faster compression and decompression speeds: https://engineering.fb.com/2016/08/31/core-data/smaller-and-faster-data-compression-with-zstandard/. GDAL supports ZSTD since 2.3.
This is a proposal to include `libzstd` in the SuperBuild package, and enable GDAL's support of it. OTB applications will be able to use ZSTD compression seamlessly, by virtue of GDAL.
Results for a noisy `Float32` 10980x10980 TIFF, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 482 330 028 b | N/A | N/A | N/A |
| DEFLATE | 419 729 334 b | 4.030s | 0.687s | 1.647s |
| ZSTD-9 | 415 737 011 b | 8.514s | 3.787s | 0.903s |
Results for a 15-bit `Int16` 10980x10980 TIFF, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 226 122 884 b | N/A | N/A | N/A |
| DEFLATE | 201 822 038 b | 9.292s | 7.615s | 8.064s |
| ZSTD-9 | 207 553 979 b | 13.921s | 7.801s | 7.696s |
Results for a the file above, converted to 16-bit, no predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 241 187 444 b | N/A | N/A | N/A |
| DEFLATE | 177 040 501 b | 1.736s | 0.396s | 0.869s |
| ZSTD-9 | 184 242 872 b | 12.715s | 3.077s | 0.558s |
Results for a the file above, converted to 16-bit, horizontal differencing predictor:
| Format | Size | Compression time | Compression time (MT) | Decompression time |
| ------ | ------ | ------ | ------ | ------ |
| Uncompressed | 241 187 444 b | N/A | N/A | N/A |
| DEFLATE | 159 937 804 b | 2.053s | 0.392s | 1.722s |
| ZSTD-9 | 153 871 845 b | 13.487s | 3.058s | 0.735s |
| ZSTD-3 | 154 626 632 b | 1.643s | 0.378s | 0.565s |
Times are best of three runs, taken on my computer, with GDAL from `osgeo/gdal:ubuntu-full-3.2.0`.
It seems that users would need to be very careful selecting the compression level, because the default is less efficient than DEFLATE-6.
#### Risks and benefits
- it makes SuperBuild more complex (one more library to keep track of)
- the SuperBuild package will be slightly larger (`libzstd.so` is about 678 KB)
- files saved with ZSTD will probably be unreadable by most software, but it's not used by default
- it allows users to take advantage of the faster compression and decompression speeds
#### Alternatives for implementations
Do nothing.
### Who will be developing the proposed changes?
Not sure.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2133Wrong input layer size in TrainImagesRegression using the ANN classifier2022-01-07T09:18:56ZCédric TraizetWrong input layer size in TrainImagesRegression using the ANN classifier### Description
This bug was reported by a user on the [forum](https://forum.orfeo-toolbox.org/t/problems-doing-imageregression-with-ann-created-model/934)
The input layer of the output model produced `TrainImagesRegression` when using...### Description
This bug was reported by a user on the [forum](https://forum.orfeo-toolbox.org/t/problems-doing-imageregression-with-ann-created-model/934)
The input layer of the output model produced `TrainImagesRegression` when using the artificial neural network classifier (`ann`) always has a size of 1, when it should match the number of bands of the input image. The training does not fail, and a mse is computed. However awhen trying to use the model with `ImageRegression` an error is thrown by OpenCV:
```
(FATAL) ImageRegression: itk::ERROR: MultiThreader(000001D5109CC040): Exception occurred during SingleMethodExecute OpenCV(4.1.1) C:\build\otb\build\OPENCV\src\OPENCV\modules\ml\src\ann_mlp.cpp:350: error: (-215:Assertion failed) (type == CV_32F || type == CV_64F) && inputs.cols == layer_sizes[0] in function ‘cv::ml::ANN_MLPImpl::predict’
```
Note that training an artificial neural network model with `TrainVectorRegression` works correctly, so the problem is likely located in `TrainImagesRegression`. Also note that `TrainImagesClassifier` works correctly whn trying to train an artificial neural network for classification.
### Steps to reproduce
```
otbcli_TrainImagesRegression -io.il input.tif -io.ip "predicted_values.tif" -io.out model.txt -classifier ann -classifier.ann.sizes 10
otbcli_ImageRegression -in input.tif -model model.txt -out out.tif
```
leads to the following model :
``` yml
%YAML:1.0
---
opencv_ml_ann_mlp:
format: 3
layer_sizes: [ 1, 10, 1 ]
[...]
```
but the input image has 4 bands.
### Configuration information
OTB 7.2, reproduced on Windows 10 and Ubuntu 16.04Thibaut ROMAINThibaut ROMAINhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2126orfeo-toolbox Conda package WSL2022-01-07T08:55:18Zschwarzcsorfeo-toolbox Conda package WSL### Description
I am able to install the orfeo-toolbox on WSL Ubuntu, using Anaconda and creating a python=3.7 virtual environment (conda install -c conda-forge -c orfeotoolbox otb).
I am able to successfully run the "Smoothing" test ca...### Description
I am able to install the orfeo-toolbox on WSL Ubuntu, using Anaconda and creating a python=3.7 virtual environment (conda install -c conda-forge -c orfeotoolbox otb).
I am able to successfully run the "Smoothing" test case using the above described setup (https://www.orfeo-toolbox.org/packages/nightly/2019-06-28/CookBook-stable/recipes/python.html).
However when I run the command "print(str(otb.Registry.GetAvailableApplications()))", I get the error message:
[...]/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so: undefined symbol: _ZN5shark6random9globalRngE
I further looked into the problem and it seems some applications are working, e.g. "TrainImageClassifier", while others such as "TrainVector Classifier" produces the same error:
run--> app1= otb.Registry.CreateApplication("TrainVectorClassifier")
error--> 2020-11-17 12:30:03 (WARNING): Failed to load libraries from /home/cschwarz/miniconda3/envs/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so while trying to create application TrainVectorClassifier
because: -> /home/cschwarz/miniconda3/envs/oftb/lib/otb/applications/otbapp_TrainVectorClassifier.so: undefined symbol: _ZN5shark6random9globalRngE
### Steps to reproduce
- install conda on WSL Ubuntu
1. conda create --name oftb python=3.7 spyder=4
2a. conda activate oftb
2b. conda install -c conda-forge -c orfeotoolbox otb
3. python
4. import otbApplication as otb
5. print(str(otb.Registry.GetAvailableApplications()))
### Configuration information
conda version: 4.9.2
python version: 3.7.8
otb : 7.1.0 / Build: py37h06a4308_1
I am very excited to use OTB for patch-image-processing and would value your advice on how to solve this issue?
Best Regards,
Christianhttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2122Missing "ImageTimeSeriesGapFilling" in the conda linux 7.1. version?2020-11-04T15:13:24ZRapsodia86Missing "ImageTimeSeriesGapFilling" in the conda linux 7.1. version?I accidently marked previous issue as confidential and was not able to edit it later on so I created a new one. Could you remove the old one or merge and leave it open? Sorry!
### Description
Hello,
I tried the LIS (let it snow app) a...I accidently marked previous issue as confidential and was not able to edit it later on so I created a new one. Could you remove the old one or merge and leave it open? Sorry!
### Description
Hello,
I tried the LIS (let it snow app) and it throw me the error that there is no ImageTimeSeriesGapFilling module.
I checked the installed packaged in the anaconda folder and I do not see that application. There was no issue during the installation process.
Could you verify it? There are other apps from the Image Filtering group, but not this one.
The downloaded package is named: otb-7.1.0-py37hf484d3e_0.
### Steps to reproduce
Please, check the file that is submitted to the anaconda website
### Configuration information
The downloaded package is named: otb-7.1.0-py37hf484d3e_0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2121Bug in GroundSpacingImageFunction at image middle2020-11-04T10:20:40ZGuillaume PaseroBug in GroundSpacingImageFunction at image middle### Description
When calling the `GroundSpacingImageFunction` at the image middle index, the results are nan.
I think the reason is here: https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Filtering/Projection/inc...### Description
When calling the `GroundSpacingImageFunction` at the image middle index, the results are nan.
I think the reason is here: https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Filtering/Projection/include/otbGroundSpacingImageFunction.hxx#L70
I don't get the logic : we want to estimate the spacing at a given index, but the measurements are made at `index` and `largest_size - index`. Of course, when `index = largest_size/2`, the measurements are on the same index => crash.
The delta X and delta Y applied on index should not be too large. This can give quite imprecise results especially for SAR images. I understand that using a `delta_X = 1 pixel` may be unstable (because of DEM), but maybe we should do all transforms from sensor to ground at a constant elevation.
### Steps to reproduce
I could reproduce the bug with a S1 image that has an even number of pixels.
### Configuration information
OTB 7.2
Custom Debian build with native dependencies.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2119Support otb::Image writers in OutpuImageParameter2020-11-02T14:20:26ZGuillaume PaseroSupport otb::Image writers in OutpuImageParameterIt would be nice if the applications could use `otb::Image` writers (in addition to `otb::VectorImage` writers). When the application produces an `otb::Image<T,2>` , and the output pixel type corresponds to `T`, we can therefore avoid th...It would be nice if the applications could use `otb::Image` writers (in addition to `otb::VectorImage` writers). When the application produces an `otb::Image<T,2>` , and the output pixel type corresponds to `T`, we can therefore avoid the double cast filters, and save some RAM space.
I know that applications using `otb::Image` internally is not generic, but it gives more performances in some projects outside OTB.
The implementation is not difficult:
* separate macros `CAST_IMAGE_BASE` and `CAST_VECTOR_IMAGE_BASE`
* separate functions `SwitchInput` and `SwitchVectorInput`https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2118double precision would be better for ConvertSensorToGeoPoint application output2022-01-07T07:47:39ZJonathan Guinetdouble precision would be better for ConvertSensorToGeoPoint application outputlat/lon output are displayed in float precision https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Applications/AppProjection/app/otbConvertSensorToGeoPoint.cxx#L78. Double precision would be better .lat/lon output are displayed in float precision https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Modules/Applications/AppProjection/app/otbConvertSensorToGeoPoint.cxx#L78. Double precision would be better .https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2112Use symlink in main package page2022-01-07T07:30:30ZCédric TraizetUse symlink in main package pageThere are two pages on the website containing release packages:
* `https://www.orfeo-toolbox.org/packages/`: packages corresponding to the current release
* `https://www.orfeo-toolbox.org/packages/archives/OTB/`: all otb packages.
Pac...There are two pages on the website containing release packages:
* `https://www.orfeo-toolbox.org/packages/`: packages corresponding to the current release
* `https://www.orfeo-toolbox.org/packages/archives/OTB/`: all otb packages.
Packages for the current release are duplicated on two different pages. We could simplify it by creating symlinks from the main package page to the archive page.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2110ConvertSensorToGeoPoint application with Elevation management2020-10-07T08:33:30ZJulien OsmanConvertSensorToGeoPoint application with Elevation managementIt would be [interesting](https://forum.orfeo-toolbox.org/t/convertsensortogeopoint-elevation-management/811) to be able to use a DEM as input of the ConvertSensorToGeoPoint application. The new RPC mechanism that will come with OTB 8.0 ...It would be [interesting](https://forum.orfeo-toolbox.org/t/convertsensortogeopoint-elevation-management/811) to be able to use a DEM as input of the ConvertSensorToGeoPoint application. The new RPC mechanism that will come with OTB 8.0 should make it easy to implement.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2108Add setup.py to install python Bindings2020-10-23T07:48:26ZEsquis BenjaminAdd setup.py to install python BindingsFor now the python binding is only installed in the install folder but not officially in the pythons libraries
It would be interesting to provide a setup.py to install the python bindings in the python workspace:
For example:
```
#!/us...For now the python binding is only installed in the install folder but not officially in the pythons libraries
It would be interesting to provide a setup.py to install the python bindings in the python workspace:
For example:
```
#!/usr/bin/env python
from distutils.core import setup
setup(name='otbApplication',
version='7.0',
description='OTB Python bindings',
author='OTB Team',
author_email='https://forum.orfeo-toolbox.org/',
url='https://www.orfeo-toolbox.org/',
packages=['otbApplication'],
package_data={'otbApplication': ['_otbApplication.so']},
)
```https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2105Add performance test monitoring into OTB CI2022-01-07T09:50:11ZMickael SavinaudAdd performance test monitoring into OTB CIIn order to facilitate the OTB development when large modifications are done. It could be interesting to monitor the performance of OTB.
Currently it is possible to use regression test to do that. Indeed CTest provide test time executio...In order to facilitate the OTB development when large modifications are done. It could be interesting to monitor the performance of OTB.
Currently it is possible to use regression test to do that. Indeed CTest provide test time execution and CDash display it. The idea could be to retrieve this test time and compare the test time of develop with feature branch.
@sdinot has perform some test with CDash API and it is very interesting:
* all test are available here: https://cdash.orfeo-toolbox.org/viewTest.php?buildid=53386
* successful tests are available here: https://cdash.orfeo-toolbox.org/viewTest.php?onlypassed&buildid=53386
* with API we can retrieve the corresponding JSON:
* https://cdash.orfeo-toolbox.org/api/v1/viewTest.php?buildid=53386
* https://cdash.orfeo-toolbox.org/api/v1/viewTest.php?onlypassed&buildid=53386
With [jq](https://stedolan.github.io/jq/) we can filter the JSON to retrieve the desired information and understand the content:
```
curl -s 'https://cdash.orfeo-toolbox.org/api/v1/viewTest.php?onlypassed&buildid=53386' | jq .
```
To retrieve the test time:
```
curl -s 'https://cdash.orfeo-toolbox.org/api/v1/viewTest.php?onlypassed&buildid=53386' | jq '.tests[] | { name: .name, time: .execTimeFull }'
```
or whitout JSON structure:
```
curl -s 'https://cdash.orfeo-toolbox.org/api/v1/viewTest.php?onlypassed&buildid=53386' | jq '.tests[] | .name, .execTimeFull'
```https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2104Remove 6S2020-09-22T08:12:38ZMickael SavinaudRemove 6S### What changes will be made and why they would make a better Orfeo ToolBox?
6S code is outdated and very difficult to maintain. Other version are available but it could be complicated to update the code in OTB due to manual correction ...### What changes will be made and why they would make a better Orfeo ToolBox?
6S code is outdated and very difficult to maintain. Other version are available but it could be complicated to update the code in OTB due to manual correction done after f2c.
Therefore it could be interesting to remove 6S and keep outside the radiative transfer code from OTB.
The idea is to delegate the functionalities to an external code and managed file interface. For example we can use the [SOS](https://github.com/CNES/RadiativeTransferCode-SOS) code to generate the LUT as for MAJA software. Moreover the MAJA software will be released in open source, so we can reuse the code to read the data.
#### High level description
#### Risks and benefits
Mutualize code with MAJA
#### Alternatives for implementations
### Who will be developing the proposed changes?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2103Documentation of output parameters in application examples2020-09-21T07:50:27ZCédric TraizetDocumentation of output parameters in application examplesOutput parameters don't appear in the doc of Python examples. The example of `EndmemberNumberEstimation` is
```
import otbApplication
app = otbApplication.Registry.CreateApplication("EndmemberNumberEstimation")
app.SetParameterString(...Output parameters don't appear in the doc of Python examples. The example of `EndmemberNumberEstimation` is
```
import otbApplication
app = otbApplication.Registry.CreateApplication("EndmemberNumberEstimation")
app.SetParameterString("in", "cupriteSubHsi.tif")
app.SetParameterString("algo","vd")
app.SetParameterFloat("algo.vd.far", 1.0E-3)
app.ExecuteAndWriteOutput()
```
An extra line could be added :
```
print(app.GetParameterDouble("number"))
```
The examples are generated from the application by this [script](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Documentation/Cookbook/Scripts/otbGenerateExamplesRstDoc.py)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2102Bad integration of InputImageList in the Application Wrapper2020-09-28T12:26:28ZEsquis BenjaminBad integration of InputImageList in the Application WrapperDear All,
The InputImageParameter has a complete set of getters for any image types.
However the InputImageListParameter can only be accessed in FloatVectorImage.
This can be an issue when working with specific types that you don't wan...Dear All,
The InputImageParameter has a complete set of getters for any image types.
However the InputImageListParameter can only be accessed in FloatVectorImage.
This can be an issue when working with specific types that you don't want to cast into Float. Moreover when branching Apps in memory a cast will be automatically done.
An optional 'unsigned int idx' can be added to all the accessors in order to mimic the behavior or the already existing 'GetParameterImageBase(const std::string& key, unsigned int idx = 0);'
Regardshttps://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2101Output vector layers of LargeScaleMeanShift have not a correct geometry accor...2022-01-06T16:08:34ZaloboaOutput vector layers of LargeScaleMeanShift have not a correct geometry according to GEOS### Description
Output vector layers of LargeScaleMeanShift have not a correct geometry according to GEOS, as implemented in rgeos.
The layer can be fixed using geos tools.
Same problem is found if -mode raster is used, followed by gdal...### Description
Output vector layers of LargeScaleMeanShift have not a correct geometry according to GEOS, as implemented in rgeos.
The layer can be fixed using geos tools.
Same problem is found if -mode raster is used, followed by gdal_polygonize
### Steps to reproduce
`otbcli_LargeScaleMeanShift.bat -in QB_1_ortho.tif -spatialr 4 -ranger 80 -minsize 16 -tilesizex 256 -tilesizey 256 -cleanup 1 -mode.vector.out regions.shp`
in R:
```
> require(rgeos)
> require(rgdal)
> v1 <- readOGR(dsn="D:/FLUXPYRetal/Navarra/SegNavarra", layer="regions")
> gIsValid(v2)
[1] FALSE
Warning message:
In RGEOSUnaryPredFunc(spgeom, byid, "rgeos_isvalid") :
Ring Self-intersection at or near point 370624.65625896002 4831278.72278025
> v1f <- gSimplify(v1, tol = 0.00001)
> gIsValid(v1f)
[1] TRUE
```
### Configuration information
OS, OTB version or tag, information related to build (binaries, superbuild, system libs ...)https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2100otbcli_LargeScaleMeanShift does not cleanup all temporary files2022-01-07T11:47:25Zaloboaotbcli_LargeScaleMeanShift does not cleanup all temporary files### Description
otbcli_LargeScaleMeanShift does not cleanup temporary *FINAL.tif files, even if -cleanup is stated.
Furthermore, in the -mode.vector case, undocumented images *_labelmap.tif and *_labelmap_merged.tif are produced (even i...### Description
otbcli_LargeScaleMeanShift does not cleanup temporary *FINAL.tif files, even if -cleanup is stated.
Furthermore, in the -mode.vector case, undocumented images *_labelmap.tif and *_labelmap_merged.tif are produced (even if -mode.vector.imfield has not been set). It looks like the two labelmap images correspond, respectively, to the unfilterd and filtered versions, but this should be documented (actually, only written if specifically so requested by an specific option).
In the case of -mode.raster, the undocumented *_labelmap.tif image (corresponding to the unfiltered version) is also produced.
### Steps to reproduce
`otbcli_LargeScaleMeanShift.bat -in QB_1_ortho.tif -spatialr 4 -ranger 80 -minsize 16 -tilesizex 256 -tilesizey 256 -cleanup 1 -mode.vector.out regions.shp`
`otbcli_LargeScaleMeanShift.bat -in QB_1_ortho.tif -spatialr 4 -ranger 80 -minsize 16 -tilesizex 256 -tilesizey 256 -cleanup 1 -mode raster -mode.raster.out regions.tif`
### Configuration information
Windows 7, OTB 7.1.0https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2097On redirecting standard output into a Python logger2022-01-21T14:16:56ZLuc HermitteOn redirecting standard output into a Python logger# TL;DR
We should document that Python bindings require the `sys.stdout` object to provide an `isatty()` method.
This need appears when we try to redirect `sys.stdout` elsewhere, like for instance a Python logger.
# Details
When using...# TL;DR
We should document that Python bindings require the `sys.stdout` object to provide an `isatty()` method.
This need appears when we try to redirect `sys.stdout` elsewhere, like for instance a Python logger.
# Details
When using OTB applications through Python bindings, one may be tempted to redirect OTB logs into the Python logger currently configured for the application.
After a few minutes we find many solutions on stackoverflow or even directly available through pip. But, these solutions will induce a very cryptic error message (sorry I can't remember it, I fixed the issue a long time ago).
By injecting the solution proposed in https://github.com/swig/swig/issues/1117 we can find what goes wrong: the redirected output doesn't provide the `isatty()` method.
I think this requirement should be documented in OTB cookbook in _Python binding_ chapter.
For information a _stdout 2 logger_ redirection compatible with OTB is provided in S1Tiling: https://gitlab.orfeo-toolbox.org/s1-tiling/s1tiling/-/blob/eodag/s1tiling/Utils.py#L256
# Side notes
An open question is should we report this patch (for SWIG) (or a similar one, for licensing issues) into `otbApplication.i`?https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2095Consider switching to the C++11 GLIBC ABI2023-08-01T14:56:42ZLaurențiu NicolaConsider switching to the C++11 GLIBC ABIWe might want to enable the C++11 ABI (`-D_GLIBCXX_USE_CXX11_ABI=1`) in the Linux package for better compatibility with newer compilers.
See https://gitlab.orfeo-toolbox.org/s1-tiling/s1tilingsupportapplications/-/issues/4 for an example.We might want to enable the C++11 ABI (`-D_GLIBCXX_USE_CXX11_ABI=1`) in the Linux package for better compatibility with newer compilers.
See https://gitlab.orfeo-toolbox.org/s1-tiling/s1tilingsupportapplications/-/issues/4 for an example.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2092GDAL Superbuild fails when building the KEA driver2020-09-02T11:54:51ZCédric TraizetGDAL Superbuild fails when building the KEA driverBy default the [KEA GDAL driver](https://gdal.org/drivers/raster/kea.html) is built by GDAL if `libkea` is found on the system. This leads to the following error in the SuperBuild if `libkea` is found.
```
/usr/bin/ld: warning: libkea.s...By default the [KEA GDAL driver](https://gdal.org/drivers/raster/kea.html) is built by GDAL if `libkea` is found on the system. This leads to the following error in the SuperBuild if `libkea` is found.
```
/usr/bin/ld: warning: libkea.so.1.4, needed by /tmp/SuperBuild/GDAL/src/GDAL/.libs/libgdal.so, not found (try using -rpath or -rpath-link)
/tmp/SuperBuild/GDAL/src/GDAL/.libs/libgdal.so: undefined reference to `kealib::KEAImageIO::getImageBandClrInterp(unsigned int)'
/tmp/SuperBuild/GDAL/src/GDAL/.libs/libgdal.so: undefined reference to `kealib::KEAImageIO::readImageBlock2BandMask(unsigned int, void*, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, unsigned long, kealib::KEADataType)'
[...]
```
This can be reproduced in a conda environment :
```
conda create -n pykea -c conda-forge python=3.7 kealib
conda activate pykea
cmake ~/OTB/otb/SuperBuild/ -DCMAKE_INSTALL_PREFIX=/tmp/install -DCMAKE_PREFIX_PATH=/tmp/install
make GDAL -j12
```
In the SuperBuild, drivers should not be built depending what libraries are installed on the system. Only the drivers corresponding to the SuperBuild dependencies should be built. Most drivers are specifically disabled in the Superbuild using the `--with-drivername=no` option. `--with-driver=kea` should be adde din this case. If an user wants to use an [exotic](https://en.wikipedia.org/wiki/Kea) GDAL driver with OTB he should compile its own version of GDAL and set `USE_SYSTEM_GDAL=ON`.
Maybe an issue should be opened on GDAL on the kea driver compilation though.https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/issues/2088Documentation on how to build the documentation2020-09-01T14:10:10ZCédric TraizetDocumentation on how to build the documentationThe Cookbook is a CMake target of the OTB project: it can be built by setting the `BUILD_COOKBOOK` cmake variable option to `ON`. The name of the target is `CookbookHTML`.
However the cookbook used to be a separate project (see this [MR...The Cookbook is a CMake target of the OTB project: it can be built by setting the `BUILD_COOKBOOK` cmake variable option to `ON`. The name of the target is `CookbookHTML`.
However the cookbook used to be a separate project (see this [MR](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/merge_requests/235)), with different build instruction. But the `[README.md](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/-/blob/develop/Documentation/Cookbook/README.md) file has never been updated with the new instructions.
As far as i know, there is no up to date doc (wiki, cookbook ?) on how to build the Cookbook. I think updating the `README.md` file is enough.Cédric TraizetCédric Traizet