I would like to ask if anyone has observed shifts in orthorectifictified ALOS Palsar 2 products, produced with S1TLB.
Workflow: SLC 1.1 level CEOS - Calibration - Range Doppler Terrain Correction (1. Dem 1sec 30m hgt SRTM and bilinear interpolation method, 2. Nearest Neighbor interpolation for image resampling.)
-the sar-sim TC did not work well for me-
-i have also implemented speckled filtering and multilooking to no avail-
The orthorectified product, though well orthorectified is misplaced about 20m towards the west,as a whole.
Has anyone else experienced that?
Is there a flaw on the Workflow?
If I use AW3D30 Dem instead of the SRTM would it yield better results? How can I use it? i.e. What are the specific steps to insert it as an external Dem in RDTC to work without errors?
Why did the ellipsoid correction - geolocation grid not produce better results?
Just to go sure: You have selected the SRTM 1Sec (AutoDownload)?
I have not experienced such a large offset, but if the SRTM is of bad quality in your area (extreme mountains), shifts are possible.
The Ellipsoid correction assumes a flat surface, so it potentially produces even larger shifts.
You can download the AW3D30 tile and use it as an input (Select External DEM in the dropdown menu). SNAP needs external DEMs as a GeoTiff and projected in WGS84, but if I recall correctly, both is the case.
I used the Dem of the autodownload option to avoid errors. How can I check it’s quality, considering that I am novice.
I will try the AW3D30 also to see what happens.
Perhaps, do I measure the offset in a wrong way? What would be a good way to assess the accuracy of the orthorectification?
What offset value is considered good?
If such offsets persist, can I produce a product that takes it into account and eliminated it?
In general, the terrain is not highly mountainous, though it’s hilly with local minima and maxima with difference from 10 to 50 meters.
I should also note that I use as ground range size the original slant range size of the pixels because I want all pixels of the original sar in the orthorectified product. (I have tried also the nominal ground range size but it didn’t make any difference, regarding the offset of course.)
you can set the option “Output Digital Elevation Model” in the terrain correction module. This writes the DEM which was (downloaded and) used for the orthorectification into the final product. You can then inspect it for quality errors, also in relation with the observed shift
A good way is to select WGS84 as output coordinate system and then export a kml file and compare the location of the features in Google Earth (explained in this tutorial, page 22: Interferometry Tutorial with Radarsat-2)
One more question:
Is the offset due to the Dem used? Or is anything that doesn’t work with RDTC? I opened the DEM of an AOI but their values are significantly larger than what it is presented on the same point on Google Earth. Let’s say that the elevation on Google Earth at a certain x y point is 100m but the height on corresponding point on DEM is almost 160m.
an offset can be caused by the DEM (which falsely shifts pixels to a location which is not correct), but it can also originate from other sources (e.g. orbit information in ALOS metadata)
The Google Earth elevations (and their horizontal offset to your DEM) are not a very good reference, to be honest. What matters is if your SAR image is located correctly. Can you show an example of the vertical offset you experience?
Allow me to present a image scene located in Hiroshima. The dataset is acquired from the JAXA’s site as sample data. In the first Figure there is the orthorectified product overlaid on google earth. The yellow line measures a displacement of 500m.
In this case, at the maximum height, google earth presents elevation of 240m while the DEM band presents 275m. (this difference however is also observed in the sea area. The DEM band presents an elevation of almost 33m.)
Yes I just did. The results are almost identical.
I think the problem might lie with the metadata of the product.
In another forum (I dont know if I am eligible to post here another’s forum post) I read that there was a somewhat constant shift of about 18.6m between an ALOS 2 orthorectified product and a basemap, such as openstreepmap. However, the respective geocoded raster data of 2.1 level matched exactly the aforementioned basemap.
Would that be possible?
Perhaps, I should download a Sentinel 1 image of the same area and see jow well its orthorectified product matches the ground.
I will now test both RDTC and SAR-Sim TC with SRTM, GETASSE30 and AW3D30. I well let default options on SAR-Sim TC.
What should I do with the gravitaional option in applying the external DEM.
For some reason the best results are obtained with RDTC + SRTM30/AW3D30 (shifts relative to road network of about 9-20m.
The SAR-Sim TC produced greater shifts. I test the Sentinel 1 product next and see what results it would yield.
Thank you for your contribution. I think it requires further investigation. I also trust that the ortho of Sentinel 1 would be fruitful, as well as checking whether the shifts are linear and constant.
Google Earth uses orthometric, while auto-downloaded SRTM uses ellipsoid heights. So difference in vertical datum is probably main reason for mentioned elevation difference.
I expect that roads in a SAR image would appear as black-ish stripes (with curves following the actual road). When I overlay a SAR image in either Google Earth or some GIS software+OpenStreetMap as basemap, I can locate those black-ish stripes but they are almost 10-20m far from the actual roads. This happens to the whole image. Is this a fault of the orthorectification procedure or is it based on how the actual SAR image is formed?
this is certainly an error in the geocoding. It should be possible to have these black lines exactly over the roads in Google Earth. So it is not caused by the acquisition principle in general.
You do have point.
I down loaded a Sentinel 1 image, and i did exactly what you mentioned here.
(Why did you propose Terrain Flattening prior to RDTC? why not SAR-Sim provided that you said that SAR-Sim is more accurate?)
I saw that the blackish stripes do coincide with the roads on Google Earth.
Ultimately, it should be an ALOS 2 inherited problem.
Any thoughts?
