The processor is invoked with a single commad line argument - the path to a request file. See also Request File Definition. An example processing request file SebsProcReq.xml is located next to the source code files. You must modify the input products and output product paths according to your computers setup.

Packages used in this example are:

The sebs processor main class - @link org.n52.beam.processor.SebsProcessorMain SebsProcessorMain

This class implements just one method, the main() method. Within main, the sebs processor is created and the command line and the processor are passed to a ProcessorRunner. Additionally there is some code for exception handling, but basically this is everything that's happening in main.

The {@link ProcessorRunner} takes the further control of what happens to the processor. It performs a lot of actions in the background which otherwise have to be programmed over and over for each processor. The runner performs the following steps:

• Parse the command line
• Load and parse the request file
• Switches debug mode on when the appropriate command line parameter is set
• Checks if the processor should run in interactive mode. If so
  • Initializes the processor with a request, if one is present
  • Creates the processor UI frame and attaches the processor to it
  • Attaches a progressbar to the processor and
  • runs the processor ui frame
  If the processor should run in non interactive mode it:
  • Loops over all requests in the request file and for each request it
  • initializes the processor with the current request
  • logs the processor header (optionally)
  • logs the request and
  • runs the processor on the current request

The processor class - {@link SebsProcessor}

The only method that must be implemented by SebsProcessor is the process method. This is the "worker-method". It is invoked by the framework each time a request has to be processed.

A first step in the process method is checking the request type. See the checkRequestType method. It can be seen how the base class functionality of the processor class is used to retrieve the request processed, which is at this point automatically read from the request file, parsed and (optionally) verified.

The second thing to do is opening the input products denoted in the request. This happens in the loadInputProduct method. Here, the functionality of the ProductIO framework is used to read the input product skeleton (not the product data but metadata, product size, band names ...). The class ProductIO automatically creates an object of type Product that holds all this information. Note that ProductIO automatically decides which product type the requested product is and which ProductReader to use. Once the input products are read, the four bands needed for the sebs calculation are requested from the products.

Now the output product must be created. This happens in the createOutputProduct method. This method reads the product width and height from the input product. Then an output product is created which at this point is just an empty hull with a product type, product name and same dimensions as the input product. Then the resulting sebs bands are added. The product now neither contains data nor has a disk representation, it's pure virtual. Again, the ProductIO class supplies the product with an appropriate disk writer, the default one in this example. And finally, the disk represenation is written out.

The request file definition

The request file must contain a few basic lines. These are:

• The xml header,
• a request list tag and
• a number of requests

For future expansion, it is mandatory that every processor defines a request type, in this case the type is defined by "SEBS".

Then this simple example request defines the input products and the output product.

@see org.esa.beam.framework.dataio @see org.esa.beam.framework.dataop @see org.esa.beam.framework.processor @see org.esa.beam.util