Commit ef6ab1c8 authored by David Youssefi's avatar David Youssefi

Merge branch 'develop' into 819-display-pixel-type-of-image-in-readimageinfo-application

parents 7dbc21cc 61c61e24

Too many changes to show.

To preserve performance only 1000 of 1000+ files are displayed.

We are ready to release OTB version MAJOR.MINOR.PATCH. The following steps need to be done:
### 1. Branches
* [ ] **(if major or minor release)** Feature freeze: [create the new release branch](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#create-release-branch)
* [ ] **(if patch release)** Work on the already existing branch `release-MAJOR-MINOR`
* [ ] Make sure the version number in `CMakeLists.txt` is MAJOR.MINOR.PATCH
### 2. Housekeeping
* [ ] In this story, make a list of blocking issues for the release (if any)
* [ ] [Update dashboard scripts](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#dashboard) to support new version numbers
* [ ] [Update the SuperBuild archive](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#superbuild-archive) (if needed)
* [ ] Update release notes (walk the GitLab MR merged history and log all improvements)
* [ ] Update the date in RELEASE_NOTES.txt
* [ ] Run Debian [spelling](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#spelling-check) checker
* [ ] Run shellcheck script from [OTB-Devutils/Scripts/](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb-devutils/blob/master/Scripts/run_shellcheck.sh)
* [ ] [Update translation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#translation-for-monteverdi-mapla) for Monteverdi and Mapla
* [ ] [Sanity check the binary packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#standalone-packages-sanity-check)
* [ ] Windows
* [ ] Linux
* [ ] Mac
### 3. Actual release
Once all blocking issues are closed, and the previous steps are done:
* [ ] [Tag the release or RC](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#release-tag)
* [ ] **(if major or minor release)**: Merge the release into develop
* [ ] **(if it's the latest release)**: Merge the release into master
* [ ] **(if patch release)**: Backport fixes
* [ ] Update GIT_TAG for all official remote modules (if needed)
### 4. Publish and plan next release
* [ ] [Prepare and upload source packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#prepare-and-upload-source-packages)
* [ ] [Promote nightly packages](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#promote-nightly-packages)
* [ ] [Update documentation](https://gitlab.orfeo-toolbox.org/orfeotoolbox/otb/wikis/Help-for-release-actions#update-documentation)
* [ ] Software Guide
* [ ] Cookbook
* [ ] Doxygen
* [ ] Application online documentation
* [ ] WordPress page "Home" and "Download" pages
* [ ] Upload OTB source archive to [Zenodo](https://zenodo.org/) to create a unique Digital Object Identifier (DOI)
* [ ] Update OTB-Data-Examples.tgz on orfeo-toolbox (packages)
* [ ] Send email to mailing list to announce the release
* [ ] Release announcement on the blog
* [ ] Announcement on social networks (twitter, google+)
* [ ] Forward announcement to news_item@osgeo.org ([OSGeo news](https://www.osgeo.org/foundation-news/))
* [ ] Plan the next release (nominate new release manager, setup PSC meeting on IRC)
* [ ] Contact QGis processing plugin maintainer to update XML description for new OTB-Applications (or [supply it](https://wiki.orfeo-toolbox.org/index.php/QGIS_access_to_OTB_applications#updating-the-XML-descriptors))
* [ ] Remove public branches related to MR or bugfix merged before the release
/label ~story
......@@ -117,8 +117,6 @@ macro(otb_create_application)
list(REMOVE_DUPLICATES OTB_APPLICATIONS_NAME_LIST)
set(OTB_APPLICATIONS_NAME_LIST ${OTB_APPLICATIONS_NAME_LIST}
CACHE STRING "List of all applications" FORCE)
mark_as_advanced(OTB_APPLICATIONS_NAME_LIST)
endmacro()
macro(otb_test_application)
......
......@@ -23,7 +23,8 @@ cmake_minimum_required(VERSION 3.1.0)
foreach(p
CMP0025 # CMake 3.0
CMP0042 # CMake 3.0
CMP0058
CMP0058 # CMake 3.3
CMP0072 # CMake 3.11
)
if(POLICY ${p})
cmake_policy(SET ${p} NEW)
......@@ -91,6 +92,8 @@ if( CMAKE_HOST_WIN32 )
endif()
endif()
set(OTB_APPLICATIONS_NAME_LIST "" CACHE STRING "List of all applications" FORCE)
mark_as_advanced(OTB_APPLICATIONS_NAME_LIST)
set(OTB_CMAKE_DIR ${OTB_SOURCE_DIR}/CMake)
set(CMAKE_MODULE_PATH ${OTB_CMAKE_DIR} ${CMAKE_MODULE_PATH})
......
......@@ -177,3 +177,21 @@ Regarding labels, we use the following set:
* ~"To Do": action is planned
* ~Doing: work in progress
* ~api ~app ~documentation ~monteverdi ~packaging ~qgis: optional context information
## Versioning
Starting from OTB 7.0.0, we use [semantic versioning](https://semver.org/). See the website for the full spec, in summary:
> Given a version number MAJOR.MINOR.PATCH, increment the:
>
> 1. MAJOR version when you make incompatible API changes,
> 2. MINOR version when you add functionality in a backwards-compatible manner, and
> 3. PATCH version when you make backwards-compatible bug fixes.
>
> Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
The develop branch is always the place where the upcoming major or minor release is worked on. Patch releases are done on release branches, for example 7.0.1 and 7.0.2 could be found on the release-7.0 branch.
For the purpose of defining backwards compatibility, the OTB API covers (not an exhaustive list): the C++ API, the Python bindings, application names, application parameters, output format and interpretation of input data.
When we deprecate part of our public API, we should do two things: (1) update our documentation to let users know about the change, (2) issue a new minor or major release with the deprecation in place.
......@@ -333,7 +333,23 @@ The available syntax for boolean options are:
- OFF, Off, off, false, False, 0 are available for setting a ’false’
boolean value
::
&nodata=(double) value / [int:double, int:double ...]
- This options allows one to set specific nodata values for all or selected bands.
There are two ways of setting nodata values. simple scalar values of band,value pair.
OTB will select either one of them depending on type of nodata value string
- If value is scalar (without bandindex), it will be applied only to first band of image.
- If value is given as "bandindex:value" pair separated by a ":" then
nodata value is applied to only those selected band.
- By default OTB will not alter any existing nodata value.
OGR DataSource options
^^^^^^^^^^^^^^^^^^^^^^^
......
......@@ -16,16 +16,6 @@ A simple example is given below:
#include "otbBandMathImageFilterX.h"
#include "otbVectorImage.h"
int otbBandMathImageFilterXNew( int itkNotUsed(argc), char* itkNotUsed(argv) [])
{
typedef double PixelType;
typedef otb::VectorImage<PixelType, 2> ImageType;
typedef otb::BandMathImageFilterX<ImageType> FilterType;
FilterType::Pointer filter = FilterType::New();
return EXIT_SUCCESS;
}
As we can see, the new band math filter works with the class
otb::VectorImage.
......
......@@ -16,9 +16,10 @@ Conrad Bielski (JRC),
Cyrille Valladeau (CS),
Daniel McInerney,
David Dubois,
David Youssefi (CNES Intern, then CS),
David Youssefi (CNES Intern, then CS, then CNES),
Edouard Barthelet (Telecom Bretagne and Thales Communications),
Emmanuel Christophe (CNES, then CRISP, then Google),
Emmanuelle Sarrazin (CNES),
Etienne Bougoin (CS),
Gr\'egoire Mercier (Telecom Bretagne),
Guillaume Borrut (CS),
......@@ -33,7 +34,7 @@ Julien Malik (CS),
Julien Michel (CS then CNES),
Julien Osman,
Julien Radoux (UCL),
Laurentiu Nicola (CS Romania),
Laurentiu Nicola (CS ROMANIA),
Luc Hermitte (CS),
Ludovic Hussonnois (CS),
Manuel Grizonnet (CNES),
......
......@@ -158,20 +158,28 @@ OTB, through the use of the OSSIM library --
sensors either through a physical or an analytical approach. This is
transparent for the user, since the geometrical model for a given
image is instantiated using the information stored in its meta-data. The
search for a sensor model is not straightforward. It is done in 3 steps :
search for a sensor model is not straightforward. It is done in several steps :
\begin{enumerate}
\item Load an external \code{.geom} file specified through extended filenames
(if present)
\item Load the \code{.geom} file attached with the input image (if present).
They share the same name, without extension.
\item Search in the OSSIM plugin factory for a suitable model
(\code{ossimplugins::ossimPluginProjectionFactory}). For instance, this
factory contains Pl\'eiades and TerraSar sensor models.
\item If no model was found, search in the OSSIM projection factory
(\code{ossimProjectionFactoryRegistry}). For instance this factory contains
Spot5, Landsat and Quickbird sensor models.
\item If still no model was found, search for a valid sensor model defined
in an external \code{.geom} file. If no model is found, check if there are
any RPC tags embedded within the image (GDAL is used to detect those RPC
tags). When the tags are present, an \code{ossimRpcModel} is created.
\item If no model was found, search any RPC tags in the input image. When the
tags are present, an \code{ossimRpcModel} is created.
\item If still no model was found, search for a valid sensor model in other
files attached to the current dataset. For instance, with a Sentinel-1 SAFE XML
product, it will inspect underlying \code{.tiff} files. With a VRT dataset, it
will inspect the files referenced by the VRT.
\end{enumerate}
Note that the \code{.geom} metadata file can store any sensor model recognized
by OSSIM.
\subsection{Using Sensor Models}
\label{sec:UsingSensorModels}
......
......@@ -157,19 +157,15 @@ The header files contain class declarations
and formatted comments that are used by the Doxygen documentation
system to automatically produce HTML manual pages.
In addition to class headers, there are a few other important header files.
In addition to class headers, there are a few other important ITK header files.
\begin{description}
\item[\code{itkMacro.h}] is found in the
\code{Utilities/ITK/Code/Common} directory
and defines standard system-wide macros (such as \code{Set/Get},
\item[\code{itkMacro.h}] defines standard system-wide macros (such as \code{Set/Get},
constants, and other parameters).