{@link com.bc.beam.usage.ndvi}
package contains example code
for a simple MERIS ndvi processor. This file will give a detailed step by step instruction on
how to implement a scientific processor using the processor framework supplied by the
MERIS/AATSR Toolbox.
The example 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 NdviProcReq.xml is located next to the source code files. You must modify the input product and output product paths according to your computers setup.
Packages used in this example are:
@link org.esa.beam.examples.ndvi_processor.NdviProcessorMain NdviProcessorMain
main()
method of the processor to be able to invoke
the processor from the command line. It is a general convention that every executable within the
Toolbox project has a xxxMain.java file which contains the main()
method. This
makes it easier to navigate the code.
This class implements just one method, the main()
method. Within main, the ndvi
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:
{@link NdviProcessor}
{@link org.esa.beam.framework.processor.Processor}
class which is embedded in the processor framework.
The only method that must be implemented by NdviProcessor
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 product 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 product is read,
the two bands needed for the ndvi calculation are requested from the product.
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 ndvi band is 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 must contain a few basic lines. These are:
{@link org.esa.beam.framework.processor.RequestTags}
. You can define any number of named parameters
to customize processor requests.
For future expansion, it is mandatory that every processor defines a request type, in this case the type is defined by "NDVI_EXAMPLE".
Then this simple example request just defines two more entrie, the input product 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