NoData values are being interpolated while reprojecting

[dcoelho]

Hello,
I am currently reprojecting SLSTR and OLCI data and exporting them to geotiffs but running into two issues while re-projecting.

First,
I would like to use the bicubic resampling instead of nearest neighbor, however when doing so NoData values (-327680 for the S1_radiacne for example) are being interpolated to nearby reprojected pixels causing the data to not get masked out and become extremely negative.

Is there any alternative to just using nearest neighbor that will yield nicely resampled image while somehow preventing pixels neighboring NoData values from being interpolated?

Also if I use NaN as the NoData value I can interpolate and everything seems to work as intended, but I do not want to do this for bands which are integer based such as S1-6 radiance since the integer values get converted to float.

Second,
I would like the preserve the datatype of the bands during the process of reprojecting → writing as a geotiff. However the geotiff output seems to be float32 by default. Is there some implicit casting happening during reproject, and can I prevent this from happening?

[ABraun]

I would like the preserve the datatype of the bands during the process of reprojecting -> writing as a geotiff. However the geotiff output seems to be float32 by default. Is there some implicit casting happening during reproject, and can I prevent this from happening?

you can reproject and output to Dimap format and then, in a second step, convert to GeoTiff format with the required data type.

[marpet]

@dcoelho
The data type float32 is used because we have to. In Tiff it is necessary to use a common data type. So we have to use the one which can hold the data of all bands.
If you write each band into a single tiff file, the type of the band will be used.

Regarding the interpolation issue you have mention. I’ currently investigating this.

[dcoelho]

@ABraun, and @marpet

Thanks for the input. I think I found a workaround the issue I was having, by leaving the NoData as NaN during reproject, and then using Convert Datatype -> Write as GeoTiff.

My processing graph previously was:

1. Reproject (with the band’s original fill value)
2. BandSelect (select all bands of same data type)
3. Write as GeoTiff

But instead will use:

1. Reproject (With NaN)
2. Convert-Datatype
3. Write as GeoTiff

[marpet]

The holes you have mentioned are coming from a data overflow caused the interpolation.
I’ve noted this in our issue tracker for the further development (SNAP-763).

[MCG]

Hi,

I did a ML classification. I want now to export to KMZ but before need to reproject to WGS84. When doing so, NoData pixels appears in the raster (see attached files).

This image shows the output of the ML classification. The pink class is the one that will cause the problem in the next step.

Output after doing the reprojection:

Any help?
M

[MCG]

Just found the solution. 0 values are converted to NoData when reprojecting. By specifying NoData = -1 in the reprojection tool the problem is solved. Hope this help someone

(bug?) Reprojection of Sentinel-1 file causes values amendments

Before reprojection 0 is defined as no data value. After reprojection nan is defined as no data value. Many zeroes in your dataset significantly affect mean and median. But you are right, the changes are too large to be caused by nodata only. Did your pixel size change? I can't open the file on your Google Drive because the dim file alone is just some of the metadata. You also need to upload the folder with the same name: subset_calibrated_S1A_IW_GRDH_1SDV_20160512T161044_2_TC.data This…

[marpet]

The problem is a bit different.
Here the problem is that integer bands have no dedicated no-data value.
For float bands there is NaN.
If you use -1, it’s the no-data value of the band in your case, as no-data value for the reprojection, then the result should be good.
I have to admit, we should handle this better.

[MCG]

Thanks for the clarification, I am sure it will help someone struggling with the same issue.