SRTM and Aster DEM are currently not yet supported. We will almost certainly add it at some point in the future, for the reason of completness, but it is not on a high priority list.

The Copernicus DEM is available globally and its quality is in general better than SRTM and Aster. You can use decide to use the best available one (10m over Europe, 30m globally) or choose the 30m or 90m exact, see;

Sentinel-1 GRD

Use Sentinel Hub Processing API to access Sentinel-1 (C-band synthetic aperture radar imaging) data.

Did you find some areas, where SRTM is better than Copernicus DEM?

To be gonest, the reason i’m asking is because i’m comparing the image I get from sentinelhub using MAPZEN for Orthorectification and image of google earth engine, when both suppose to have the same processing, and the only difference I found between the two platforms is the processing is the orthorectification , when GEE use SRTM and ASTER.

The difference I have found is in two aspects:

1. The pixels of the image from GEE do not overlap the pixels from Sentinelhub


2. I found many more pixels with value of -inf on sentinelhub, when GEE has no values like this at all.

I’m not sure why is this happenning, but as I find the orthorectification process to be different between the two platforms, I assume it might be the source of the problem. I could treat those values using median filter, but it worries me because I don’t have this on GEE image which has the same extent.

You should definitely check Copernicus DEM as well. We did see some discontinuities in Mapzen data, resulting probably from the stitching of various datasets. These could result in “inf” data.

The overlap of the pixels is probably not a consequence of one or another DEM. The actual pixel location is related to the original Sentinel-1 data and the CRS that you are using in your requests. Make sure to always use the original CRS if you want to get the best quality (avoiding reprojection errors).

Hi,

I have checked MAPZEN,copernicus 10/30, 30 and 90, and in all of them I’m getting the inf,similar to this:

This is just one example out of many . I believe chaing from MAZPEN did not improve it much and is true I can use median filter but in thos case and level of noise is not very helpful.

Do you know any other reason that could create those inf values?

Not by just looking at the image.

Can you tell us:

• instance ID that you are using (first two blocks will be sufficient)


• exact BBOX


• date of the data


• settings of the request (e.g. which band, which backscattter coefficient, etc.)
  
  The things that will help us to reconstruct this at our place.
  
  Ideally you would fetch the WCS request (or process API) that is being called from your Python workflow.

bbox: [-47.94472988694906,-8.740124011788941,-47.93459851294756,-8.729376781124973]

date:03/12/2020

band: VH

backscatter coefficient: gamma0 (radiometric terrain corrected)

Acquisition mode:IW

Polarization:VV+VH

Resolution:high

Orbit Direction:both

the costum script:

//VERSION=3



function evaluatePixel(sample) {

    return [sample.VV, sample.VH, sample.dataMask];

}



function setup() {

  return {

    input: [{

      bands: [

        "VV",

        "VH"

      ]

    }],

    output: {

      bands: 2,

      sampleType:"FLOAT32"

    }

  }

}

function evaluatePixel(samples){

   return [10 * Math.log(samples.VV) / Math.LN10,1973 * Math.log(samples.VH) / Math.LN10]}

the WMS request:

(is part of a for loop)

      wms_bands_request = WmsRequest(

            data_collection=DataCollection.SENTINEL1_IW_DES,

            data_folder='_folder',

            layer='BANDS-S1-IW',

            bbox=bbox,

            time=i,

            width=bbox_size[0],

            height=bbox_size[1],

            image_format=MimeType.TIFF,

            time_difference=datetime.timedelta(hours=2),#get one image when there is small time differences between them

            config=config)

        

The ID will be sent you privatly.

Thank you for your help

Hi,

I checked this with our team and they confirmed that these inf values are result of the VH being 0 at these pixels (log(0)=inf), which is an expected consequence of thermal noise removal (point 2 in the processing chain).

I am not farmiliar with how GEE is processing the data so I cannot comment on that part.

Best,