Hello Reinoud
First to clarify the terminology:
- Modules
Modules are packages of source code, which provide functionality to the application. In our module framework a module must contain a module.xml, which describes the module and defines the extension provided to the application. - Plug-Ins
Are our old extension mechanism, used till version 3.7, some are still used. New extensions should be developed by using modules, extensions points and extensions. - Processor
Processors were developed with our old processing framework. Now such development should use our Graph Processing Framework (GPF). - Operator
Operators are processing units of GPF and can be chained to a graph.
Now to your questions.
What BEAM framework is should I use: processor, gpf or others?
You should use the GPF framework.
I understood that it is possible to do processor chaining with the GPF framework. If that is correct, do you have some documentation on how that would work?
Yes, this is possible. Unfortunately there is no documentation for this. But operators are chained by products. The target product of one operator can be the input of another operator. This can be done in source code by multiple calls to
GPF.createProduct(...). Using the result of one call as input for the next call.
Or you can write an xml file were you can set-up a chain of operators. You can find an example for such an XML-file in our project source at
<ProjectHome>beam-unmix\src\test\xml\SpectralUnmixing.xml. This file describes a chain of a read node followed by the unmix node followed by a write node. In general read and write nodes must not be added explicitly to the graph. They are added automatically when the graph is executed. But the example shows how to chain multiple nodes.
What package name should I choose for my new module: free choice or something like org.esa.beam.processor.<...>
You are free of choice. But I would recommend something like: com.bmta.beam.
What version of BEAM should I develop against: the trunk in SVN or rather the approach from the Programming Tutorial where I downloaded beam-4.6-sources.zip and used that as an external library. I have both up and running in Eclipse at the moment.
I recommend that you use the sources from SVN. So you stay up-to-date.
Suppose I would like to submit my new module to you for distribution through the module manager. What is required to do so?
You should send us the jar file, the source code (better the whole project). Also the module should have user help.
Then we do a short review, if everything is OK we will provide it via the module manager.
Regarding the invocation from within VISAT and execution from the command-line, both is possible. Graphs and operators anc be executed from the command-line by using the Graph Processing Tool (GPT). To invoke it from VISAT there is a bit more to do.
You have to implement an Action and add this as an extension to your module.xml.
In this action
DefaultSingleTargetProductDialog is used. It is an easy way to create a simple user interface for simple operators.
For more advanced use cases, you should look at
SpectralUnmixingAction or
CollocationAction and see how the UI is set-up there.
1
2public class EMClusterAnalysisAction extends AbstractVisatAction {
3
4 private ModelessDialog dialog;
5
6 @Override
7 public void actionPerformed(final CommandEvent event) {
8 if (dialog == null) {
9 DefaultSingleTargetProductDialog dstpDialog =
10 new DefaultSingleTargetProductDialog("EMClusterAnalysis", getAppContext(), "EM Cluster Analysis",
11 "clusterAnalysisEM");
12 dstpDialog.setTargetProductNameSuffix("_em");
13 dialog = dstpDialog;
14 }
15 dialog.show();
16 }
17}
1 2<extension point="beam-ui:actions">
3 <action>
4 <id>emClusterAnalysis</id>
5 <helpID>emClusterAnalysis</helpID>
6 <class>org.esa.beam.cluster.visat.EMClusterAnalysisAction</class>
7 <parent>imageAnalysis</parent>
8 <text>EM Cluster Analysis...</text>
9 <mnemonic>C</mnemonic>
10 </action>
11</extension>
Answer