Hi,
Thank you Cédric for this information.
We have also started using the S1 ortho-rectification and we have found one
issue linked to the gridspacing parameter.
We are producing a set of ortho images over a large area and, for storage and
distribution issues, we tile them onto 110 km x 110 km pieces over a grid of
100 km x 100 km, which gives us a 10 km overlap in every direction. Something
like this:
100 km 110 km
<---------><------------->
+----------+-+-----------+
| | | |
| | | |
| | | |
| | | |
+----------+-+-----------+
+----------+-+-----------+
| | | |
| | | |
| | | |
| | | |
+----------+-+-----------+
Instead of performing the ortho-rectifications and then tiling the results with
ExtractROI, we perform one ortho-rectification per destination tile (we have a
good reason for that). This means that the overlap areas are ortho-rectified
twice, once for every tile involved in the overlap area (or 4 times for the
simultaneous horizontal and vertical overlaps). The difference lies only on the
chosen origin for the orthos.
We have found that the same S1 IW GRD data produces slightly different pixel
values on the overlap areas. The differences are higher with a larger
gridspacing parameter value. For an ortho pixel size of 30 m, we need to set
the gridspacing to 10 in order to get the same values.
I suppose that this is related to the coordinate interpolation, but I was
expecting that a gridspacing equal to the target pixel size would be OK.
Other than that, everything seems OK and much faster and flexible than S1TBX.
So thank you OTB.
Jordi
CedricL <[email protected]> wrote:
>
> Hello,
>
> here my brief review of OTB S1 orthorectification, also in comparison to Snap.
>
> First of all, it's brief comparison in only one dataset so the review is not
> fully general and rigorous.
>
> Anyway, first, it's very fast (grid parameter at 50m) and output pixel to
> 10m, otb near 15min and use 2Go ram on Intel® Core™ i7-4710HQ CPU @ 2.50GHz
> (4 core*2) vs snap 40min with 3.5Go of ram
>
> When I compare results it's similar but it's seem that there is a small E/W
> shift (20m) and near 3m north south. I don’t know really which one is the
> best because I need to compare to a real dataset like Sentinel-2 and not only
> google earth.
>
> In addition I notice some small artefact with otb due to downloaded srtm dem
> with otb srtm tile downloader contrary to snap. After analysis of the "srtm
> snap dem" and "OTB dem", The artefact are in flat area 'river' where in snap
> all the river is
> masked contrary to otb. But the area of artefact was in the river where there
> is a small island that seems to be masked in srtm snap dem. So it’s not very
> often and due to dem and not otb but it’s to mentioned that.
>
> In conclusion, for me it's working very well and I am happy of that. So
> thanks you to have integrate this feature.
>
> I will continue my review on a dataset with multitemporal data in order to
> compare ortho with temporal data.
>
> Best regards
>
>
> --
--
--
Check the OTB FAQ at
http://www.orfeo-toolbox.org/FAQ.html
You received this message because you are subscribed to the Google
Groups "otb-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/otb-users?hl=en
---
You received this message because you are subscribed to the Google Groups
"otb-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
