MRG: Synchronize with branch develop

Conflicts:
	Modules/Wrappers/QtWidget/include/otbWrapperQtWidgetView.h

.gitlab/issue_templates/bugs.md

+### Description
+
+Describe what happens and why you think it is a bug
+
+### Steps to reproduce
+
+Describe as precisely as possible how to reproduce the bug. Try to isolate a minimal number of steps. Also describe reproducibility (always, random ...).
+
+### Configuration information
+
+OS, OTB version or tag, information related to build (binaries, superbuild, system libs ...)
+
+/label ~bug

.gitlab/issue_templates/documentation_changes.md

+### Target documentation ressources
+
+Can be a combination of Software guide, cookbook, doxygen, blog, applications doc, websites
+
+### Change requested
+
+Describe precisely the changes that are required.

.gitlab/issue_templates/feature_request.md

+Short summary of the requested feature
+
+/label ~feature

.gitlab/issue_templates/request_for_comments.md

+### What changes will be made and why they would make a better Orfeo ToolBox?
+
+#### High level description
+
+#### Risks and benefits
+
+#### Alternatives for implementations
+
+### Who will be developing the proposed changes?
+

.gitlab/merge_request_templates/request_for_changes.md

+### Summary
+
+Gives a short summary of the changes.
+
+### Rationale
+
+Explain the rationale for the changes (possible link to a Request For Comments or to an issue).
+
+### Implementation Details
+
+#### Classes and files
+
+Give an overview of the implementation: main changes made to classes, files and modules. Do not paste complete diff, as it is available in the merge request already.
+
+#### Applications
+
+Describe any changes made to existing applications, or new applications that have been added.
+
+#### Tests
+
+Describe the testing strategy for new features.
+
+### Documentation
+
+List or link documentation modifications that were made (doxygen, example, software guide, application documentation, cookbook).
+
+### Additional notes
+
+List remaining open issues if any, and additional notes. 

CMake/FindShark.cmake

@@ -97,25 +97,43 @@ if(SHARK_CONFIG_FILE)
   "${SHARK_VERSION_MAJOR}.${SHARK_VERSION_MINOR}.${SHARK_VERSION_PATCH}")
 endif()
 
-set(SHARK_USE_OPENMP_matched)
-#define SHARK_USE_OPENMP
+# Check if Shark was built with OpenMP, CBLAS, DYNLIB, ...
 file(STRINGS "${SHARK_INCLUDE_DIR}/shark/Core/Shark.h" SHARK_H_CONTENTS)
-string(REGEX MATCH
-  "#define.SHARK_USE_OPENMP"
-  SHARK_USE_OPENMP_matched "${SHARK_H_CONTENTS}")
 
-if(SHARK_USE_OPENMP_matched)
-  if(NOT OTB_USE_OPENMP)
-    message(WARNING "Shark library is built with OpenMP and you have OTB_USE_OPENMP set to OFF.")
-  endif()
+if(SHARK_H_CONTENTS MATCHES "#define.SHARK_USE_OPENMP")
+  set(SHARK_USE_OPENMP 1)
+else()
+  set(SHARK_USE_OPENMP 0)
+endif()
+
+if(SHARK_H_CONTENTS MATCHES "#define.SHARK_USE_CBLAS")
+  set(SHARK_USE_CBLAS 1)
+else()
+  set(SHARK_USE_CBLAS 0)
+endif()
+
+if(SHARK_H_CONTENTS MATCHES "#define.SHARK_USE_DYNLIB")
+  set(SHARK_USE_DYNLIB 1)
+else()
+  set(SHARK_USE_DYNLIB 0)
+endif()
+
+if(SHARK_USE_CBLAS AND SHARK_USE_DYNLIB)
+  set(REQUIRED_CBLAS_LIB CBLAS_LIBRARY)
+  find_library(CBLAS_LIBRARY NAMES cblas)
+else()
+  set(REQUIRED_CBLAS_LIB)
 endif()
 
 INCLUDE(${CMAKE_ROOT}/Modules/FindPackageHandleStandardArgs.cmake)
 FIND_PACKAGE_HANDLE_STANDARD_ARGS(Shark
-  REQUIRED_VARS SHARK_LIBRARY SHARK_INCLUDE_DIR
+  REQUIRED_VARS SHARK_LIBRARY SHARK_INCLUDE_DIR ${REQUIRED_CBLAS_LIB}
   VERSION_VAR SHARK_VERSION_STRING)
 
 if(SHARK_FOUND)
   set(SHARK_INCLUDE_DIRS ${SHARK_INCLUDE_DIR} ${Boost_INCLUDE_DIR} )
   set(SHARK_LIBRARIES ${SHARK_LIBRARY} ${Boost_LIBRARIES} )
+  if(REQUIRED_CBLAS_LIB)
+    set(SHARK_LIBRARIES ${SHARK_LIBRARIES} ${CBLAS_LIBRARY})
+  endif()
 endif()

CMake/OTBModuleMacros.cmake

@@ -277,6 +277,12 @@ macro(otb_module_test)
   foreach(dep IN LISTS OTB_MODULE_${otb-module-test}_DEPENDS)
     list(APPEND ${otb-module-test}_LIBRARIES "${${dep}_LIBRARIES}")
   endforeach()
+  # make sure the test can link with optional libs
+  foreach(dep IN LISTS OTB_MODULE_${otb-module}_OPTIONAL_DEPENDS)
+    if (${dep}_ENABLED)
+      list(APPEND ${otb-module-test}_LIBRARIES "${${dep}_LIBRARIES}")
+    endif()
+  endforeach()
 endmacro()
 
 macro(otb_module_warnings_disable)

CMakeLists.txt

@@ -231,10 +231,6 @@ mark_as_advanced(OTB_USE_DEPRECATED)
 
 option(OTB_USE_OPENMP "Add openmp compiler and linker flags" OFF)
 option(OTB_USE_SSE_FLAGS "Enable SIMD optimizations (hardware dependent)." ON)
-#-----------------------------------------------------------------------------
-# SHOW_ALL_MSG_DEBUG option
-option(OTB_SHOW_ALL_MSG_DEBUG "Show all debug messages (very verbose)" OFF)
-#mark_as_advanced(OTB_SHOW_ALL_MSG_DEBUG)
 
 include(OTBSetStandardCompilerFlags)
 #---------------------------------------------------------------

CONTRIBUTING.md

+# How to contribute to Orfeo ToolBox ?
+
+Thank you for taking the time to contribute to OTB! This document will guide you
+through the workflow and best practices you need to know to send your
+contribution.
+
+There are many ways to contribute to OTB:
+
+* [Reporting a bug](#reporting-bugs)
+* [Making a feature request](#feature-requests-and-discussions)
+* [Improving documentation](#documentation-improvements)
+* [Contributing code (C++, Python, CMake, etc.)](#code-contribution)
+* [Publishing a remote module](#remote-modules)
+
+Our main workflow uses GitLab for source control, issues and task tracking. We
+use a self-hosted gitlab instance:
+
+[`https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb`](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb)
+
+Remember to check out also our [developers mailing list](https://groups.google.com/forum/?hl=fr#!forum/otb-developers/join),
+where we discuss some features, improvements and high level project planning.
+You are welcome to ask questions there as a beginner or future OTB contributor!
+
+## Reporting bugs
+
+If you have found a bug, you can first [search the existing issues](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues?label_name%5B%5D=bug)
+to see if it has already been reported.
+
+If it's a new bug, please [open a new issue on GitLab](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues/new).
+The 'Bug' issue template will help you provide all important information and
+help fixing the bug quicker. Remember to add as much information as possible!
+
+## Feature requests and discussions
+
+Feature requests are welcome! Generally you are welcome to simply [open an issue](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/issues)
+and discuss your idea there. For more complex requests there is an issue
+template for in depth description called 'Request for Comments'.
+
+
+## Documentation improvements
+
+The two main OTB documentations are the [Software Guide](https://www.orfeo-toolbox.org/SoftwareGuide/index.html)
+and the [CookBook](https://www.orfeo-toolbox.org/CookBook/).  Their sources are
+hosted in the main OTB repository in the `Documentation/` directory. Then, to
+contribute documentation use the same workflow as for code contributions (see
+below).
+
+See also the [Compiling documentation](https://wiki.orfeo-toolbox.org/index.php/Compiling_documentation)
+wiki page for help on building the Sphinx and Latex source.
+
+## Code contribution
+
+The OTB workflow is based on GitLab [Merge Requests](https://docs.gitlab.com/ee/gitlab-basics/add-merge-request.html).
+Clone the repository, create a feature branch, commit your changes, push the
+feature branch to a fork (or the main repository if you are a core developer),
+then send a merge request.
+
+Note that we also accept PRs on our [GitHub mirror](https://github.com/orfeotoolbox/OTB)
+which we will manually merge.
+
+Feature branches are tested on multiple platforms on the OTB test infrastructure (a.k.a the [Dashboard](https://dash.orfeo-toolbox.org/)). They appear in the FeatureBranches section. 
+
+Caveat: even if the Dashboard build on develop branch is broken, it is not
+allowed to push fixes directly on develop. The developer trying to fix the
+build should create a merge request and submit it for review. Direct push to
+develop without review must be avoided.
+
+### Commit message
+
+On your feature branch, write a good [commit message](https://xkcd.com/1296/):
+short and descriptive. If fixing an issue or bug, put the issue number in the
+commit message so that GitLab can [crosslink it](https://docs.gitlab.com/ce/user/project/issues/crosslinking_issues.html).
+You can prefix your commit message with an indicating flag (DOC, BUG, PKG,
+TEST, SuperBuild, etc.).
+
+Standard prefixes for OTB commit messages:
+
+    BUG: Fix for runtime crash or incorrect result
+    COMP: Compiler error or warning fix
+    DOC: Documentation change
+    ENH: New functionality
+    PERF: Performance improvement
+    STYLE: No logic impact (indentation, comments)
+    WIP: Work In Progress not ready for merge
+
+For example, here are some good commit messages:
+
+    BUG: #1701 Warn users if parameter string is unset
+    DOC: Fix typo in Monteverdi French translation
+    COMP: Allow GeoTIFF and TIFF to be disabled when no 3rd party drags them
+
+### Merge request
+
+Your contribution is ready to be added to the main OTB repository? Send a Merge
+Request against the `develop` branch on GitLab using the merge request
+template. The merge request will then be discussed by the community and the core
+OTB team.
+
+* Merge requests can not be merged until all discussions have been resolved (this is enforced by GitLab)
+* Merge requests **must receive at least 2 positives votes from core developers** (members of Main Repositories group in Gitlab with at least "Developer" level; this includes PSC members) before being merged
+* The merger is responsible for checking that the branch is up-to-date with develop
+* Merge requests can be merged by anyone (not just PSC or RM) with push access to develop
+* Merge requests can be merged once the dashboard is proven green for this branch.
+  This condition is mandatory unless reviewers and authors explicitely agree that
+  it can be skipped (for instance in case of documentation merges or compilation
+  fixes on develop)
+
+Branches can be registered for dashboard testing by adding one line in `Config/feature_branches.txt` in [otb-devutils repository](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils.git).
+
+For branches in the main repository, the syntax is the following:
+
+```
+branch_name [otb-data_branch_name]
+
+```
+The second branch name is optional. It can be set if you need to modify [otb-data](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-data.git) according to your changes.
+
+For branches in forks, the syntax is the following:
+```
+user/branch_name [user/otb-data_branch_name]
+```
+Again, the second branch name is optional.
+
+For users without push access to [otb-devutils repository](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils.git), the modification can be asked through a merge requests to this repository.
+
+Once the feature branch is registered for testing, it should appear in the *FeatureBranches* section of the [OTB dashboard](https://dash.orfeo-toolbox.org/index.php?project=OTB) next day (remember tests are run on a nighlty basis).
+
+Do not forget to remove the feature branch for testing once it has been merged.
+
+## Remote modules
+
+[Remote Modules](https://wiki.orfeo-toolbox.org/index.php/Remote_Modules) are
+the prefered way if you wish to make your apps and filters available to the
+community while keeping control and maintenance of their sources. Remote
+modules are just like regular modules, except they are not distributed inside
+OTB source code. Under some conditions (dependencies, official acceptance
+process, etc.), we are also able to distribute your remote module in the
+official standalone binaries. See [the wiki](https://wiki.orfeo-toolbox.org/index.php/Remote_Modules)
+for more information.
+
+## Gitlab guidelines
+
+In order to organize the issues in our Gitlab instance, we use both labels and
+milestones.
+
+The [milestones](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/milestones) should be used to track in which release a feature is merged.
+Gitlab can then provide a summary of all features and bugs added to a given release
+version.
+
+Regarding labels, we use the following set:
+* ~story: significant feature to be implemented with a detailed work plan, it can
+  correspond to a Request for Comments that has turned into a development action
+* ~bug: Bug, crash or unexpected behavior, reported by a user or a developer
+* ~feature: Feature request expressed by an OTB user/developer
+* ~"To Do": action is planned
+* ~Doing: work in progress
+* ~api ~app ~documentation ~monteverdi ~packaging ~qgis: optional context information

Documentation/Cookbook/Scripts/otbGenerateWrappersRstDoc.py

@@ -95,7 +95,8 @@ def GenerateChoice(app,param,paramlist, count = 0):
     return output
 
 def GenerateParameterType(app,param):
-    if app.GetParameterType(param) == otbApplication.ParameterType_Empty:
+    if app.GetParameterType(param) == otbApplication.ParameterType_Empty \
+       or app.GetParameterType(param) == otbApplication.ParameterType_Bool:
         return "Boolean"
     if app.GetParameterType(param) == otbApplication.ParameterType_Int \
        or app.GetParameterType(param) == otbApplication.ParameterType_Radius \
@@ -346,6 +347,8 @@ def GetApplicationExamplePythonSnippet(app,idx,expand = False, inputpath="",outp
         if paramtype == otbApplication.ParameterType_Empty:
             app.EnableParameter(param)
             output+= "\t" + appname + ".EnableParameter("+EncloseString(param)+")" + linesep
+        if paramtype == otbApplication.ParameterType_Bool:
+            output+= "\t" + appname + ".SetParameterString("+EncloseString(param)+","+EncloseString(value)+")" + linesep
         if paramtype == otbApplication.ParameterType_Int \
                 or paramtype == otbApplication.ParameterType_Radius \
                 or paramtype == otbApplication.ParameterType_RAM:

Documentation/Cookbook/rst/AdvancedUse.rst

+Advanced Use
+============
+
+This section describes advanced configuration options and tricks.
+
+Environment variables that affects Orfeo ToolBox
+------------------------------------------------
+
+The following environment variables are parsed by Orfeo ToolBox. Note
+that they only affect default values, and that settings in extended
+filenames, applications, monteverdi or custom C++ code might override
+those values.
+
+* ``OTB_DEM_DIRECTORY``: Default directory were DEM tiles are stored. It should only contain ```.hgt`` or or georeferenced ``.tif`` files. Empty if not set (no directory set)
+* ``OTB_GEOID_FILE``: Default path to the geoid file that will be used to retrieve height of DEM above ellipsoid. Empty if not set (no geoid set)
+* ``OTB_MAX_RAM_HINT``: Default maximum memory that OTB should use for processing, in MB. If not set, default value is 128 MB.
+* ``OTB_LOGGER_LEVEL``: Default level of logging for OTB. Should be one of  ``DEBUG``, ``INFO``, ``WARNING``, ``CRITICAL`` or ``FATAL``, by increasing order of priority. Only messages with a higher priority than the level of logging will be displayed. If not set, default level is ``INFO``.
+
+Extended filenames
+------------------
+.. _extended-filenames:
+
+Extended filenames is an interesting feature of OTB. With it, you can control
+several aspects of the beahvior of the OTB in the OTB-Applications or in our
+own C++ applications. Historically this feature has been desingn to solve
+an issue with how to handle geo-referencing information. 
+
+Indeed, there are multiple ways to define geo-referencing information. For
+instance, one can use a geographic transform, a cartographic projection,
+or a sensor model with RPC coefficients. A single image may contain
+several of these elements, such as in the “ortho-ready” products: this
+is a type of product still in sensor geometry (the sensor model is
+supplied with the image) but it also contains an approximative
+geographic transform that can be used to have a quick estimate of the
+image localisation. For instance, your product may contain a “.TIF” file
+for the image, along with a “.RPB” file that contains the sensor model
+coefficients and an “.IMD” file that contains a cartographic projection.
+
+This case leads to the following question: which geo-referencing
+element should be used when opening this image in OTB. In
+fact, it depends on the users need. For an orthorectification
+application, the sensor model must be used. In order to specify which
+information should be skipped, a syntax of extended filenames has been
+developed for both reading and writing.
+
+Since the development of this feature we have extend this mechanism for 
+other aspaects: like band or overview selection in reader part or support
+create option of gdal in writer part.The reader and writer extended filename 
+support is based on the same syntax, only the options are different. 
+To benefit from the extended file name mechanism, the following syntax 
+is to be used:
+
+::
+
+    Path/Image.ext?&key1=<value1>&key2=<value2>
+
+**Note that you’ll probably need to “quote” the filename, especially if calling
+applications from the bash command line.**
+
+Reader options
+^^^^^^^^^^^^^^
+::
+
+    &geom=<path/filename.geom>
+
+-  Contains the file name of a valid geom file
+
+-  Use the content of the specified geom file instead of
+   image-embedded geometric information
+
+-  empty by default, use the image-embedded information if available
+
+-----------------------------------------------
+
+::
+
+    &sdataidx=<(int)idx>
+
+-  Select the sub-dataset to read
+
+-  0 by default
+
+-----------------------------------------------
+
+::
+
+    &resol=<(int)resolution factor>
+
+-  Select the JPEG2000 sub-resolution image to read
+
+-  0 by default
+
+-----------------------------------------------
+
+::
+
+    &bands=r1,r2,...,rn
+
+-  Select a subset of bands from the input image
+
+-  The syntax is inspired by Python indexing syntax with
+   bands=r1,r2,r3,...,rn where each ri is a band range that can be :
+
+   -  a single index (1-based) :
+
+      -  :code:`2` means 2nd band
+
+      -  :code:`-1` means last band
+
+   -  or a range of bands :
+
+      -  :code:`3:` means 3rd band until the last one
+
+      -  :code:`:-2` means the first bands until the second to last
+
+      -  :code:`2:4` means bands 2,3 and 4
+
+-  empty by default (all bands are read from the input image)
+
+-----------------------------------------------
+
+::
+
+    &skipcarto=<(bool)true>
+
+-  Skip the cartographic information
+
+-  Clears the projectionref, set the origin to :math:`[0,0]` and the
+   spacing to :math:`[1/max(1,r),1/max(1,r)]` where :math:`r` is the resolution
+   factor.
+
+-  Keeps the keyword list
+
+-  false by default
+
+-----------------------------------------------
+
+::
+
+    &skipgeom=<(bool)true>
+
+-  Skip geometric information
+
+-  Clears the keyword list
+
+-  Keeps the projectionref and the origin/spacing information
+
+-  false by default.
+
+-----------------------------------------------
+
+::
+
+    &skiprpctag=<(bool)true>
+
+-  Skip the reading of internal RPC tags (see
+   [sec:TypesofSensorModels] for details)
+
+-  false by default.
+
+Writer options
+^^^^^^^^^^^^^^
+
+::
+
+    &writegeom=<(bool)false>
+
+-  To activate writing of external geom file
+
+-  true by default
+
+-----------------------------------------------
+
+::
+
+    &writerpctags=<(bool)true>
+
+-  To activate writing of RPC tags in TIFF files
+
+-  false by default
+
+-----------------------------------------------
+
+::
+
+    &gdal:co:<GDALKEY>=<VALUE>
+
+-  To specify a gdal creation option
+
+-  For gdal creation option information, see dedicated gdal documentation for each driver. For example, you can find `here <http://www.gdal.org/frmt_gtiff.html>`_ the information about the GeoTiff create options
+
+-  None by default
+
+-----------------------------------------------
+
+::
+
+    &streaming:type=<VALUE>
+
+-  Activates configuration of streaming through extended filenames
+
+-  Override any previous configuration of streaming
+
+-  Allows to configure the kind of streaming to perform
+
+-  Available values are:
+
+   -  auto: tiled or stripped streaming mode chosen automatically
+      depending on TileHint read from input files
+
+   -  tiled: tiled streaming mode
+
+   -  stripped: stripped streaming mode
+
+   -  none: explicitly deactivate streaming
+
+-  Not set by default
+
+-----------------------------------------------
+
+::
+
+    &streaming:sizemode=<VALUE>
+
+-  Allows to choose how the size of the streaming pieces is computed
+
+-  Available values are:
+
+   -  auto: size is estimated from the available memory setting by
+      evaluating pipeline memory print
+
+   -  height: size is set by setting height of strips or tiles
+
+   -  nbsplits: size is computed from a given number of splits
+
+-  Default is auto
+
+-----------------------------------------------
+
+::
+
+    &streaming:sizevalue=<VALUE>
+
+-  Parameter for size of streaming pieces computation
+
+-  Value is :
+
+   -  if sizemode=auto: available memory in Mb
+
+   -  if sizemode=height: height of the strip or tile in pixels
+
+   -  if sizemode=nbsplits: number of requested splits for streaming
+
+-  If not provided, the default value is set to 0 and result in
+   different behaviour depending on sizemode (if set to height or
+   nbsplits, streaming is deactivated, if set to auto, value is
+   fetched from configuration or cmake configuration file)
+
+-----------------------------------------------
+
+::
+
+    &box=<startx>:<starty>:<sizex>:<sizey>
+
+-  User defined parameters of output image region
+
+-  The region must be set with 4 unsigned integers (the separator
+   used is the colon ’:’). Values are:
+
+   -  startx: first index on X (starting with 0)
+
+   -  starty: first index on Y (starting with 0)
+
+   -  sizex: size along X
+
+   -  sizey: size along Y
+
+-  The definition of the region follows the same convention as
+   itk::Region definition in C++. A region is defined by two classes:
+   the itk::Index and itk::Size classes. The origin of the region
+   within the image with which it is associated is defined by Index
+
+-----------------------------------------------
+
+::
+
+    &bands=r1,r2,...,rn
+
+-  Select a subset of bands from the output image
+
+-  The syntax is inspired by Python indexing syntax with
+   bands=r1,r2,r3,...,rn where each ri is a band range that can be :
+
+   -  a single index (1-based) :
+
+      -  :code:`2` means 2nd band
+
+      -  :code:`-1` means last band
+
+   -  or a range of bands :
+
+      -  :code:`3:` means 3rd band until the last one
+
+      -  :code:`:-2` means the first bands until the second to last