| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
| Excerpt |
|---|
GoalsUsers of remote sensing data, may they be data end-users or scientists, usually make use of a variety of different software tools. BEAM already provides a large number of common tools for recurring tasks when working with remote sensing and correlative data. This will also be true for the Toolbox to be developed. However, users will always utilise other tools external to the Toolbox that either provide functionality not provided by the Toolbox or that implement a desired functionality in a different way, or are more performant. Frequently changing between used tools can be time consuming for users due to recurring configuration changes and data management. In many cases, it would be more comfortable and more effective if users could stay in one environment. We propose to achieve this a) by letting the user integrate his desired external tools into the Toolbox, and b) by adding external tools to the Toolbox standard configuration. Within this project we will provide integration of specific tools coming from the ORFEO Toolbox (see subsection below). Background and strategic fitThis will allow senbox developers to easily integrate new tools and processors in the toolbox. Use CasesThere is two use cases for the Stand-Alone Tools Adapter: First wrapping a tool, such as a data processor, as a GPF operator so that it can be used in GPF processing chains. Secondly, letting a user invoke an external tool from the Toolbox’ GUI menu and tool bars. The Stand-Alone Tools Adapter is the glue between the Toolbox and the external tool’s user interface. The three major responsibilities for the Stand-Alone Tools Adapter both in GUI and GPF operator mode are:
The points above are now explained in more detail: Provide the user’s inputs: If the tool is invoked from the Toolbox GUI, the Stand-Alone Tools Adapter will have to take care of the current GUI context and state: opened product files, selected product file, available bands in selected product, the selected band, the displayed views, the selected view may serve as input to the tool. In case of the GPF operator, inputs are provided by standard mechanisms used by the GPT and are already implemented in BEAM: inputs can come from XML configuration files or from command-line parameters. Notify the user: The output of the tool while it is running, for example logging information, shall be convertible to a progress indication for the user. In the case of invocation from the Toolbox GUI, the user should see a progress bar and shall have a cancel button for immediately terminating long-running processes; Open the generated outputs: If the tool is invoked from the Toolbox GUI, and the output is readable by the Toolbox it should be opened so that the user can visualise the result. If the tool is invoked from a GPF operator, it shall be ensured that it can serve as input to a subsequent processing step.
Use cases diagrams can be foune here : Standalone Tool Adapter Use Cases GPF/GPT Use Cases can be found here : Standalone Tool Adapter GPF/GPT Use Case External tools we want to wrap via the Standalone Tools Adapter can be found here : Sample standalone tools
|
Proposed solution
From the requirements stated above, we derive the following design goals for the Stand-Alone Tools Adapter:
...
We will take special care that the default user interface generated in step (1) will look very similar to the ones used by native BEAM GPF processors. We will also allow for the development of dedicated user interfaces using the BEAM API, in the case that the generated default user interface is not satisfactory for a given tool. For example, we can easily generate user interface components for Boolean, numerical, enumeration, text, date and file path parameters. For more advanced components, a user interface will have to be programmed.
Application of the Adapter: ORFEO Toolbox Integration
The Standalone Tool Adapter functionality will be illustrated by the integration of Orfeo Toolbox command line applications.
Using the Orfeo Toolbox library typically require to write C++ code, setting up an image processing pipeline with OTB formalism, and compiling the resulting code to get a usable executable able to process images. The library comes also with a handful set of processing plugins which have been developed to ease the end-user access to the functionalities of the library. These plugins are dynamic libraries based on a common framework which provides a bundled processing pipeline targeted at specific task, ready to use in different context.
On top of this framework has been developed several applications able to run the plugins. This includes a command line wrapper, a GUI wrapper with automatic interface generation (much like the BEAM GPT provides), and a SWIG wrapper for access of the framework from Python or Java.
Orfeo Toolbox command line applications will be available through the Sentinel Toolbox Standalone Tools Adapter.
The complete list of tools which are interesting to provide in the Sentinel 2 Toolbox is as follows:
Tool Name | Functionnality |
|---|---|
BinaryMorphologicalOperation | Erosion, Dilation, Opening, Closing |
ClassificationMapRegularization | Majority Voting on classification results |
ComputeImageStatistics | Compute band statistics on large rasters |
DimensionnalityReduction | Apply a dimension reduction algorithm : PCA, NA-PCA, Maximum Autocorrelation Factor, ICA |
EdgeExtraction | Gradient, Sobel, Touzi edge detectors |
FusionOfClassification | Fuse classification results by majority voting or more evolved Dempster-Shafer based framework |
GrayscaleMorphologicalOperation | Erosion, Dilation, Opening, Closing on greyscale images |
HaralickTextureExtraction | Local Texture Extraction |
HyperspectralUnmixing | Apply unmixing algorithms on hyperspectral datasets |
LineSegmentDetection | Extract line segment via CMLA algorithm |
LocalStatisticsExtraction | Compute local statistics feature image |
MultivariateAlterationDetector | Multivariate Alteration Detector algorithm on two images |
RadiometricIndices | Computes a set of radiometric indices |
SFSTextureExtraction | Structural Feature Set Texture algorithm |
Segmentation | Several segmentation algorithms (see section 3.4.2) |
Smoothing | Simple and anisotropic smoothing |
TrainImageClassifier | Image classification by SVM, Random Forest, decision trees, and other algorithms (see section 3.4.3) |
A subset of the GDAL command line tools will also be available. At least two tools are of great interest for the Sentinel 2 Toolbox:
- gdal_rasterize: an executable providing rasterization of any vector file (shp file, GML masks…) to raster bands. It is able to burn a predefined band value at all pixels covered by a geometry (usefull to create binary raster mask out of geometries for example), or to burn the value of a specific field of a geometry on the pixels covered by the said geometry (usefull for creating labeled raster band out of vectorized classification results).
- gdal_polygonize: its counterpart, allowing transformation of binary or labeled rasters to vector files. The tool extracts connected components of a raster band, and associates a numeric field containing the pixel value of the connected component to each resulting polygon.
These two tools are handful helpers to work with masks associated with EO products.
Some other GDAL tools can be considered for integration into the Sentinel Toolbox, and the interest for their integration should be further evaluated and agreed during Iteration planning.
Questions
Below is a list of questions to be addressed as a result of this requirements document:
...