Introduction

In the SNAP user community snappy is very well received. However, it is still complex to set everything up and get it running. The user experience shall be enhanced so it gets easier to develop for SNAP or with SNAP in Python.

Open

For now we want to focus on the use case #1, the scripting use case. It is more frequently used, as the comments in the forum suggest. The use case #2 is mainly used by BC till now. Probably caused by the complexity to setup such a project. 

Typical User-Problems

• Slowness:
  It is reported that snappy is using only one core when calling GPF operators. People ask why?

• What's the name of the parameters of an operator.
  Some write their own iteration over OperatorDescriptor and reader/writer formats too.

• How to increase the memory?

• Several questions regarding the API
  How do I this or how do I that?

• Users are confused by API. getPixel, readPixel, reastRasterData, getSample
  same with write API

• How to create python project when I want to implement a Python operator?
  How to run this operator with SNAP?

Things we would like to address

• Deploy jpy package

• Snappy Python package PyPi/Conda
  (Location of SNAP provided by an environment variable)

• Support Python 3.5, 3.6

• Support Mac

• Compile jpy on target system -> use gcc/clang on Mac and linux

• Setup Continous Integration

• Check how to sync build of PyPi and Conda

• Find out if we can have more than one python interpreter in one process

• Specify Python Op requirements

• Address jpy bugs and PRs

• Ease usage of SNAP API by a pythonic high-level interface

  • Hide jpy in API

  • Support simple use cases well

  • Consider experience of developer community (Functional vs OO)

  • Ease usage of both script and operator way 

  • Check other APIs GDAL/QGIS
    How do they the processing?

  • Study use cases (forum, GeoInfo)

  • When enhancing operator documentation,
    have also the Operator Library Window in mind.
    

Stuff

Open