Even though SNAP is based on the Java programming language it supports also the development of operator plugins written in Python. This is mad made possible by the snappy module. It enables Python developers to write operators for SNAP. In the background, snappy uses the library jpy which builds a bridge between Java and Python.
The intention of this page is to point out where writing an operator in Python is different from writing an operator in Java and what you need to consider. In general, the concepts presented in How to create a new operator , How to integrate an operator, and Operator Implementation Guidelines also apply here. This page will focus on pointing out where they are different. A working example of a Python operator plugin can be found in the snap-examples repository on GitHub. The RUT project provides an example of a Python-based Operator in operational use. As you will use the Java API of SNAP Engine via snappy, you should familiarise familiarize yourself with this API, or at least know where and how to look things up.
...
- Maven >= v3.2.5
Maven is the build tool used to build and package the final plugin file. - 2.7 <= Python <= 3.4 6 (recommend best tested version is = 3.4 )
In order to make the development easier, we recommend PyCharm as your IDE. Also, before starting to implement an operator you should make sure that you have followed the procedure described in Configure Python to use the SNAP-Python (snappy) interface.
...
The main differences are that you use (1) a Python file for your operator (obviously), (2) a dedicated .xml-file to set the operator metadata, and (3) a Python-specific OperatorSpi-file to register the Operator in SNAP. These files will be explained below in detail. In the pom.xml you only need to make the usual changes which are explained at How to integrate an operator. Special adaptations are not necessary for a python operator.
Operator Implementation
An Operator implemented in Python needs to have three methods. The initialize() - method , one of the three methods to compute ( doExecute(), computeTile() or computeTileStack() ) and the dispose() method. Please have a look at the following skeleton of an operator.
...
| XML Tag | Description |
|---|---|
<name> | A unique identifier within SNAP. The identifier could be created by following the convention for the Java packages. E.g. com.companyName.domain.opName |
<alias> | A user-friendly alias name to be used e.g. . This name should be easily usable on the command line. So it should be short but still distinguishable. Let's say your operator computes a cloud mask using neural nets. You could name it 'NNBasedCloudMaskOperator', but this is not handy. So maybe just name it 'CompanyNameClouds' or invent some other handy name. You can use the gpt tool to get a list of already existing operators and their names. |
<operatorClass> | This must be always org.esa.snap.python.gpf.PyOperator |
| The version of the operator. It should follow the concept of Semantic Versioning |
<authors> | The names of the authors |
| The copyright notice |
<description> | A short description of the operator shown on the command line |
<namedSourceProducts> | This section defines one or more source products. In the GUI currently, one product is supported. On the command line, it is possible to use the names along with the -S option to specify the source product, like -SmyInput=<path> |
| In the parameters section, all the parameters needed by the operator are specified. Each parameter is surrounded by the <parameter> tag. |
...
| XML Tag | Description |
|---|---|
| The name of the parameter. |
<description> | The description of the parameter shown on the command line and as tool-tip in the GUI. |
<label> | Used in the GUI only instead of the name. The label can have white spaces in contrast to the name. |
<unit> | The unit of the parameter. Shown in the user interface. |
<dataType> | The data type of the parameter can be either byte,char,short,int,long,boolean,double,String. |
<defaultValue> | The value this parameter shall have by default. |
| <notNull> | The parameter must be provided if set to true. |
| <notEmpty> | The parameter must not be empty if set to true. The difference to <notNull> is that even if the parameter tag present in a graph XML file it is not allowed to be empty. e.g. <bandName></bandName> |
| The valid interval for numeric parameters, e.g. [10,20): in the range 10 (inclusive) to 20 (exclusive) |
| Set of values which can be assigned to a parameter field. The value set is given as textual representations of the actual values. |
| A conditional expression which must return |
<pattern> | A regular expression pattern to which a textual parameter value must match in order to indicate a valid value, e.g. |
<format> | A format string to which a textual parameter value must match in order to indicate a valid value, e.g. |
<rasterDataNodeClass> | The value can be ensures that the user can only specify bands, tie-point grids or mask of the source product for this parameter. For example, when the user shall select the bands which shall be processed or the shall select a mask from the input which defines the area to be processed. |
Graphical UI for the Operator
...
Like Java Operators, Python Operators need to be registered via the Java Service Provider Interface (SPI). For Python Operators, there exists a bridge via the PyOperatorSpi. To use this class, users In order to register the operator, developers need to create a file named named 'org.esa.snap.python.gpf.PyOperatorSpi
...
'. This file needs to be placed in the directory resources/META-INF/services in the project structure (see above). This file must contain the python package path and name of the operator
...
.
...
See below for an example and a more
...
detailed explanation.
| Code Block | ||||
|---|---|---|---|---|
| ||||
# In order to publish the python operators in this plugin module to SNAP, they need to be listed in this file. On each
# line an operator class is specified by its fully qualified name.
# A fully specified name includes the Python package path and the class name both separated by dot characters ('.').
# For example:
#
# cloud_mask.CloudMaskOp
# water.mci.MciOp
# land.ndvi.NdviOp
# land_ops.FaparOp
#
# Following Python conventions, the last name in the package path must therefore either be subpackage or a Python
# file. For the 'water.mci.MciOp' entry above, the pysical representation could either be:
# (a) water/mci.py where mci.py defines the MciOp class
# (b) water/mci/__init__.py where __init__.py defines the MciOp class
ndvi_op.NdviOp |
Known issues
- ensure same Python configuration (used libraries) on the user system as the developer usesGPF.getDefaultInstance().getOperatorSpiRegistry().loadOperatorSpis() needs to be called
- Import-Vector can't be used (see forum thread)
- logging configuration might be changed by snappy (see forum thread)
...