There is a incorrect nodata value in the Copernicus 30m DEM Model descriptor which results in all marine data (where elevation is 0) being clipped out. The correct nodata value should be -32767 as per the metadata. This is the same for the 90m DEM.
There is no override parameter for the nodata value of internal DEMs (equivalent to externalDEMNoDataValue for external DEMs), so this currently makes it impossible to use the internal Copernicus DEM for any marine work.
Per section 1.1 Table 1 it should be -32767 (e.g. INT16_MIN) https://spacedata.copernicus.eu/documents/20126/0/GEO1988-CopernicusDEM-SPE-002_ProductHandbook_I1.00.pdf When reading that seems like there are different formats available (DGED, DTED, INSPIRE). For Most general DGED format it is not explicitly defined!
So I opened one of the COP 30m DEMs (it contains float 32 values) that SNAP downloads - Copernicus_DSM_COG_10_N51_00_E004_00_DEM.tif
The GeoTIFF property does not explicitly define NoData value. I viewed the raster in QGIS and seems that no data value there is actually 0. When specifying additional no data value, the sea and other low level water areas are perfectly masked out (it covers netherland).
Hence this is not a straightforward topic.
I don’t quite understand your comments. If the GeoTIFF itself does not have a nodata values specified internally, QGIS should not make it 0 unless you force it to. When I download a similar file, the nodata value doesn’t exist when using gdalinfo and also doesn’t get applied when I load it in QGIS as shown below.
There is of course in QGIS a lot of data with the value of 0, but those are valid data values over the ocean. The true “no data” value should simply be -32767, even if it has been converted from int16 to float32, the value should still remain the same. Using a value of 0 trims out all of the ocean surface, which then does the same to the Sentinel-1 data.
About no data value. For SRTM3 the sea has values -32768 not 0. As far as I elaborated in previous post, it should be the same for COPDEM INSPIRE and DTED formats. But for DGED format it was not specified. Now when loading the data in QGIS and manually specifying no data value as 0 for that format it matches the -32768s of the SRTM3 format (e.g. masking out sea). For applications that I use (SAR), trimming out ocean surface is desired.
For our use cases, we are very interested in the ocean (including for example monitoring/detection of oil spills). My real concern here is the automatic trimming of any value which is not the official “no data” value of this data, even if it might be correct for other formats of the same data. We have already moved on from this and are using the exact same DEM files, downloaded from the same source (the AWS S3 COG bucket) but are downloading them manually and treating them as an external DEM. From my perspective, I therefore consider this issue closed. I was only trying to point out that the default behaviour was not functional for some (perhaps many?) users.
