I created subset of my data and saved it in Beam/DIMAP format.
I am able to open this product in SNAP Desktop, display it’s bands as well as calculate histograms for them, so I guess that file is not corrupted.
Unfortunately it seems that regardless of using Calibration Operator in SNAP Desktop nor calling it from Python, I receive an error message.
It seems that in the metadata the ‘calibration’ element is missing.
java.lang.NullPointerException
at org.esa.s1tbx.calibration.gpf.calibrators.Sentinel1Calibrator.getCalibrationVectors(Sentinel1Calibrator.java:204)
at org.esa.s1tbx.calibration.gpf.calibrators.Sentinel1Calibrator.getVectors(Sentinel1Calibrator.java:189)
at org.esa.s1tbx.calibration.gpf.calibrators.Sentinel1Calibrator.initialize(Sentinel1Calibrator.java:151)
Caused: org.esa.snap.core.gpf.OperatorException
at org.esa.s1tbx.calibration.gpf.calibrators.Sentinel1Calibrator.initialize(Sentinel1Calibrator.java:160)
at org.esa.s1tbx.calibration.gpf.CalibrationOp.initialize(CalibrationOp.java:146)
Caused: org.esa.snap.core.gpf.OperatorException: org.esa.snap.core.gpf.OperatorException due to java.lang.NullPointerException
at org.esa.snap.engine_utilities.gpf.OperatorUtils.catchOperatorException(OperatorUtils.java:421)
at org.esa.s1tbx.calibration.gpf.CalibrationOp.initialize(CalibrationOp.java:159)
at org.esa.snap.core.gpf.internal.OperatorContext.initializeOperator(OperatorContext.java:485)
at org.esa.snap.core.gpf.internal.OperatorContext.getTargetProduct(OperatorContext.java:272)
...
I don’t know where it originally should come from. Maybe it got lost during subset?
I also think that the cause should be passed to the new OperatorException created in OperatorUtils.catchOperatorException(). Otherwise the original stack trace gets lost.
As a general principle orbits and calibration should be taken care of first (even before subset), so doing the operations in different order could fix the issue.
The original product’s metadata is missing. The calibration needs these to get the calibration vector.
Go back to the original product and retrace how the metadata got lost. You might have selected in the creation of the subset to remove the original product metadata. I recall there was a bug with this in a very early version of SNAP. What version was the subset created with?
The current subset operation keeps the metadata by default and so the calibration should work with it.
The version returned by pkg_resources.get_distribution("snappy").version
hasn’t been updated for a while. But I think you use the one provided with SNAP 4.0, right?
Depending on how you configured it, snappy might still use an older installation of SNAP. If it still exists. Maybe you have to redo the configuration. Or there is an other reason why the metadata is absent. Can you check if the metadata is present when you open the product in SNAP. Especially the calibration elements. And please also check what happens if you do the subsetting in SNAP.
However it would be better if the error would be more meaningful and give more information instead just the plain NPE.
This bug isn’t resolved in snappy. When accessing the subset command (org.esa.snap.core.gpf.common.SubsetOp) from snappy, the original product metadata is definitely not copied automatically. Adding the line op.setCopyMetadata(True) (where op is the subset operation object) solves the problem.
That the metadata is not copied by the subset operator is not a bug, at least it is not a problem of snappy. As snappy simply provides the SNAP API for the usage with Python.
The Subset operators copies the metadata only if the parameter is set. This is the intended behaviour, since ~10 years. This behaviour might be questionable but it’s not a bug.