I want to download S1-GRD with original pixel locations. I am trying to use the TileSplitter to get the bboxes of S1 tiles, but when I chose Sentinel1 or Sentinel1_IW as data-collection, it returns below error. Is this expected behaviour? Is there another method I should use instead?
Hi, it looks like you have a projection issue in your code. Are you able to share code you are using to get this error so we can help debug it for you.
The code is below (where geom is a shapely geometry in WGS84):
I guess the issue is that SentinelHubCatalog search result (which happens inside the TileSplitter function), does not contain ‘proj:bbox’: the bbox of the Sentinel1 image in its native CRS?
But actually, maybe I shouldn’t even use the TileSplitter. My main question is: how do I get the actual pixel locations of a sentinel-1-grd image which I orthorectified using COPERNICUS_30? Every time I use a different bbox and resolution/size in the request the image that gets returned is resampled differently?
Hope to hear from you soon!
Hi Geert, Sentinel Hub will automatically create a grid based upon your bounding box and resolution. Therefore, if you change either then the raster will likely be on a different grid. There is a little more you can read on this here.
When you say actual pixel locations, what are you referring to? The original Sentinel-1 GRD product?
Hi William, I mean to get the output aligned to the pixel grid of the original Sentinel-1GRD product indeed (but perhaps the orthorectification changed this, I’m not sure). The link you posted was indeed helpful to get alignment to work for Sentinel-2, but I was wondering how to get this done for Sentinel-1?
Hi Geert, yes, you should be able to use the same method but using the extent of the Sentinel-1 tile instead. However, it is important to remember that Sentinel-1 (Synthetic Aperture Radar) is a very different data type to Sentinel-2 (Multispectral). Therefore, concepts like spatial resolution are different between the two sensors.
In addition, when you say you want you output aligned with the original Sentinel-1 GRD product, what do you mean by this? Sentinel-1 GRD is not projected, because it is in ground range geometry, if you check the .tiff file in the .SAFE folder you will see it is not a GeoTIFF. You must apply terrain correction to output the file in .geoTIFF format. You can read more into the processing chain on Sentinel Hub here.
Hi William, I am aware that the original GRD is in ground range geometry, therefore I am requesting S1 GRD with terrain correction/orthorectification. I cannot use the same method I use for S2, because for S2 I know the native projection (UTM) and the resolution (10m), for S1 all I know is the extent in WGS84 of the GRD product. If I request an orthorectified S1 GRD product from Sentinelhub, what is the native extent/projection/resolution so I can use the same method I use for S2? Sorry if I am overlooking something stupid…
As I said, Sentinel-1 GRD is not projected, because it is in ground range geometry, if you check the .tiff file in the .SAFE folder you will see it is not a GeoTIFF. You must apply terrain correction to output the file in .geoTIFF format.
As I said, I am aware of that and am therefore requesting with terrain correction and orthorectification (like in your examples. I am using the process API btw.
Hi Geert,
Digging into this a little more, I can confirm that the TileSplitter function will not work with Sentinel-1 data collections. This is because the “Original tiling grid” for S-1 has no tangible meaning. The pixel grid only makes sense after orthorectification and terrain correction, but this is not available in Catalog API, so the TileSplitter doesn’t get the required info to construct (projected) bbox.
I hope that this explanation helps you out.