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.
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.
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
Packaging / Installation
Deploy jpy package
Snappy Python package PyPi/Conda (Location of SNAP provided by an environment variable)
Support Python 3.5, 3.6
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.