Opened 16 years ago
Closed 10 years ago
#2403 closed defect (fixed)
[PATCH] NOAA level 1b geolocation interpolation
Reported by: | arb | Owned by: | dron |
---|---|---|---|
Priority: | normal | Milestone: | 1.10.2 |
Component: | GDAL_Raster | Version: | svn-trunk |
Severity: | normal | Keywords: | AVHRR L1B |
Cc: | Markus Neteler, jurien, spareeth, mmetz |
Description
The current noaa level 1b geolocation relies on sparse GCPs. This might be fine when reprojecting a small area but when reprojecting a whole swath width it produces significant errors.
It might be better if the GCPs were interpolated inside the driver and returned as a geolocation array, or if a new Lagrangian interpolation method was added to GDAL.
See ticket 2388: http://trac.osgeo.org/gdal/ticket/2388 although the sample code there doesn't handle the case where longitude wraps around (360 back to 0), or switches sign (180 to -180). When copying the 51 longitudes into a 2048-element array (prior to interpolation) it would be advisable to check for a difference > 180 compared to the previous longitude and just continue with the same magnitude/sign, then perform some modulo function after interpolation. Hope that helps!
Attachments (2)
Change History (15)
comment:1 by , 16 years ago
Status: | new → assigned |
---|
comment:2 by , 15 years ago
Cc: | added |
---|
comment:3 by , 15 years ago
Component: | default → GDAL_Raster |
---|---|
Milestone: | → 1.7.0 |
Version: | unspecified → svn-trunk |
by , 13 years ago
Attachment: | noaa_l1b_gcp_equidistant_subsampling.patch added |
---|
Modification to L1BDataset::ProcessRecordHeaders to return equidistant points.
comment:4 by , 13 years ago
Function L1BDataset::ProcessRecordHeaders subsamples the GCPs of the l1b image, but the points returned are not equidistant.
The attached patch modifies this behaviour.
I tested "gdalwarp -tps" on the AVHRR image and seems to work ok(no error "There is a problem to invert the interpolation matrix" produced).
gdalwarp -tps -t_srs EPSG:4322 A1726874.L2460388 out_noaa_l1b.tif
To apply the patch execute from gdal:
patch -p0 < noaa_l1b_gcp_equidistant_subsampling.patch
comment:5 by , 13 years ago
Cc: | added |
---|
follow-up: 7 comment:6 by , 13 years ago
Milestone: | 1.8.1 |
---|---|
Summary: | NOAA level 1b geolocation interpolation → [PATCH] NOAA level 1b geolocation interpolation |
comment:7 by , 13 years ago
comment:8 by , 13 years ago
No, it just means that as 1.8.1 has been released and didn't include this patch, it was no longer the appropriate milestone. And I didn't assign a new one because - to the extent of my knowledge - there's no one actively working on this bug. But the ticket is still open
comment:9 by , 11 years ago
Cc: | added |
---|---|
Keywords: | AVHRR L1B added |
Milestone: | → 1.10.0 |
by , 10 years ago
Attachment: | l1bdataset.diff added |
---|
patch for frmts/l1b/l1bdataset.cpp to read more GCPs
comment:10 by , 10 years ago
The attached patch l1bdataset.diff reads all GCPs per line and attempts even spacing across X and Y. It also fixes a bug for the index of the last line. The patch has been tested with AVHRR data, using tps for georeferencing. The patch improves the georeferencing accuracy considerably.
comment:11 by , 10 years ago
MarkusM,
I'm reviewing the patch. I've scratched my head a bit before realizing that the part between line 707 and 738 (after patched applied) is now dead code, particularly the if(nDesiredGCPsPerLine < nGCPsOnThisLine && nGCPStep > 1 test that is always FALSE. So the intent is to have all available GCPs per line (51), and a sub-sampling of 51 GCP lines maximum, or every 40 (=2048 / 51) rows if nRasterYSize > nRasterXSize, or nRasterYSize if nRasterYSize < 51 ? It'll be interested (for me) to test with datasets where nRasterYSize > nRasterXSize since the sample datasets in the GDAL autotest have a very low number of lines. I'll take care of cleaning things up.
comment:12 by , 10 years ago
Cc: | added |
---|
comment:13 by , 10 years ago
Milestone: | → 1.10.2 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
I have made tests with my long-term test AVHRR scene:
In ticket #2388 is lagrange.c attached (Lagrange interpolation for NOAA Level 1B geo-location) which might solve it for sparse GCPs as appear in this image.
This AVHRR can be downloaded here (1.8MB): http://gis.fem-environment.eu/outgoing/A1726874.L2460388.gz