t.sentinel.import: Add option to add a band offset after importing S-2 data #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Since Sentinel-2 Processing Baseline 4.0.0 a systematic offset has been introduced to all reflectance values. This offset is currently
1000
and can be read from the scene metadata if available.In this PR, an option to indicate an offset number is given to the user. The offset is then added to all imported bands, and via a small hack, the
description.json
that holds band metadata that is relevant for e.g.i.sentinel.mask
is preserved.Important:
An ideal solution would obviously be to automatically parse the offset from the scene metadata and implement the offset addition directly in i.sentinel.import. This is not done for the following reasons:
i.sentinel.import
, the metadata is read after importing the data itself - changing this would be a major refactoring of the modulepattern
, it is up to the user to make sure that only relevant bands (and not quality layers etc.) are imported. Fori.sentinel.import
, a blind application of the offset would not be a valid solution, so an internal mechanism would have to make sure that only reflectance bands are affected - again this requires a major refactoringi.sentinel.import
is foreseen, then it would make sense to directly make use of the GDAL Sentinel-2 driver.--> in essence, this PR represents a small-effort workaround for an issue that would require much more effort for a sustainable solution