| Page Properties | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Goals
Users 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 fit
This will allow senbox developers to easily integrate new tools and processors in the toolbox.
Assumptions
Requirements
| # | Title | User Story | Importance | Notes |
|---|---|---|---|---|
| 1 | Stand-Alone Tools Adapter | In addition to the APIs, the S-2 Toolbox shall provide Stand-Alone Tools Adapter, i.e. a generic interface that allows for integrating external, stand-alone tools into the S-2 Toolbox. The aim is to provide users an easy and consistent access to existing or new tools or processors developed independently of the S-2 Toolbox that are of high value to the users. If the external tools only have a command-line interface, the Stand-Alone Tools Adapter shall be able to generate a graphical user interface that is consistent with other functions of the S-2 Toolbox. |
...
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.
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.
...
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:
| Question | Outcome |
|---|---|