Closed alexisahedo closed 1 year ago
Hi @alexisahedo,
thanks for reaching out and great to hear that pyroSAR is useful to you!
The function snap.geocode
has an argument nodataValueAtSea
. Setting this to False
should solve your problem.
Cheers,
John
Hello @johntruckenbrodt,
I would like to thank you for your prompt response and assistance with my issue.
Sadly, I already tried it with no luck, the product of the processing always has no data values at ocean’s pixels. Down below I’ll add the .xml, the parameters I use with snap.geocode
and a picture with the resulting product.
S1A__IW___D_20181026T125803_Cal_NR_Orb_TF_TC_dB_proc.txt
resolution = 10
extra_list = ['localIncidenceAngle', 'layoverShadowMask', 'scatteringArea']
geocode(infile=s1_scene, outdir=output, spacing=resolution, polarizations='all', scaling='db', demName='Copernicus 30m Global DEM', export_extra=extra_list, terrainFlattening=True, groupsize=60, tmpdir='/Sentinel_1/temp', returnWF=True, nodataValueAtSea=False)
As I said in my first post, I’m guessing that the problem lies in the DEM which assigns 0 to all ocean’s pixels and the no data value configured to 0, probably at some point SNAP classifies the ocean’s pixels as no data. Please correct me if I’m wrong, I’m not an expert in the field.
I really appreciate all your help.
Saludos. Alexis A.
Hi @alexisahedo. In this case I suggest you search in the STEP Forum as this seems to be a SNAP issue. If it turns out that SNAP is somehow not handling the Copernicus DEM well, you can create your own DEM file with pyroSAR and pass it to snap.geocode
as externalDEMFile
.
Hello @johntruckenbrodt, Thanks a lot for the information, I really appreciate the answer, I’ll investigate it in more detail. A possible way around would be to simple use de SRTM 1sec HGT, I made some tests and it constructed the raster correctly, but well, Copernicus 30m Global DEM is newer so I thought it would be better, plus the DEA applications.
I’ll in the future ask some questions I have had in mind for a while regarding the processing step’s order used in snap.geocode
, see you in Discussions.
Saludos. Alexis A.
Hi @alexisahedo. This thread could describe your problem: https://forum.step.esa.int/t/no-data-value-of-dem-for-terrain-flattening/35949 Let's keep this issue open, apparently this is indeed an issue with SNAP but just as well relevant for pyroSAR of course. Feel free to ask any time. If it is on a different topic just open another issue. If you find a solution it would be great if you could share it here. Cheers John
I am closing this for now as I expect this to be fixed with this issue in S1TBX 9.0.1: https://senbox.atlassian.net/browse/SITBX-925
Hello dear @johntruckenbrodt
First, I’ll like to thank and congratulate you for this excellent work, it has been really useful in my current project.
I’m facing a problem and would like to ask for your advice, one of the areas of interest I’m working on is a costal zone, when I use geocode on the selected scene with Copernicus 30m Global DEM all the ocean and marsh pixels are classified as noData, I’m guessing that the reason is because the DEM use 0 as ocean’s value which causes that ocean’s pixels to be classified as noData value. To try to solve the problem, I’ll like to change the noData value written to my rasters to “nodata” or something like that to avoid such issue. Is it possible to accomplish it with pyroSAR?
I know this problem could be potentially solved using SRTM 1sec HGT, but I’m trying to follow the Digital Earth Africa recommendations (basically Sentinel-Hub product) and they used Copernicus DEM. I would really appreciate if you could help me.
Saludos. Alexis A