Opened 19 years ago
Last modified 5 years ago
#793 closed defect
USGS DEM Export messes up border. — at Version 10
Reported by: | warmerdam | Owned by: | warmerdam |
---|---|---|---|
Priority: | normal | Milestone: | closed_because_of_github_migration |
Component: | GDAL_Raster | Version: | unspecified |
Severity: | normal | Keywords: | |
Cc: | Markus Neteler, matt.wilkie@…, Kyle Shannon |
Description (last modified by )
Change History (10)
comment:2 by , 19 years ago
When resampling while projecting, nodata values are included. For the source arcinfo dem_115a the elevation values are: Computed Min/Max=1240.000,5950.848 However the output is Computed Min/Max=-32764.000,2940.000 Computed Min/Max=-32763.000,1272.000 for east and west halves respectively (stats from 'gdalinfo -mm ...') ((it's alright that the source Max is larger, it's outside the area of interest for 115c01)) gdal_translate --optfile yt_cded.opt \ -co NTS=115c01e -co InternalName=115c01_DEMe \ dem_115c 115c01_e.dem yt_cded.opt: -of USGSDEM -co Product=CDED50K -co Resample=CubicSpline -co DEMLevelCode=1 -co OriginCode=YT -co ProcessCode=8 -co DataSpecVersion=1020 -co Producer="Yukon Environment Information Management & Technology" ftp://ftp.geomaticsyukon.ca/Users/matt/gdal-resamp-err.zip (55mb)
comment:3 by , 19 years ago
I projected the source dem to Decimal Degrees in ArcInfo, which does seem to preserve nodata correctly when projecting. When I gdal_translate dem_dd there are still negative numbers in the output: Computed Min/Max=-32763.000,2933.000 That indicates to me that the error is not in the warping but in the resampling (or both).
comment:4 by , 19 years ago
yup, projection is not necessary "gdal_translate -outsize 25% 25% dem_dd 25percent.tif" yields: Computed Min/Max=-340282346638528860000000000000000000000.000,5950.848
comment:5 by , 19 years ago
These problems have arisen because of another bug fix where UInt16 files are now treated through the general case. The general case has had two (or more?) errors for some time: 1) The edge pixel logic was backwards, so bilinear results could lose one pixel around the edges, and cubic could lose two. 2) rounding of pixel values to integer in GWKSetPixel() was *not* doing rounding so sometimes resampled values that were epsilon below an integral value was round down. Both problems fixed now in CVS.
comment:6 by , 19 years ago
I'm still getting negative values in the output. I've downloaded and compiled the daily cvs tarball on cygwin (kudos for this working right out of the box!!). Input grid is decimal seconds with pixel size 0.00020833 and Computed Min/Max=480.000,4805.732 Output is same projection and pixel size with Computed Min/Max=-32761.000,3026.000
comment:7 by , 19 years ago
I removed '-co Resample=CubicSpline' from the options file and are no longer any negative values in the output dem. Sorry for wasting your time. -matt
comment:8 by , 19 years ago
Matt, This is still a bug I need to fix in the cubic resampler. I appologise for having neglected it so long. In the meantime I think you will find similar (good) effects from bilinear warping without the bug. I am reopening since I still need to fix the cubic resampler.
comment:9 by , 19 years ago
Bilinear seems to work okay with the current data I'm using this for. As a side note, I didn't get a bugzilla report for your comment even though I'm in the cc list. Dunno if it's because our mail server spam filtering is over zealous or because it didn't get sent.
comment:10 by , 17 years ago
Cc: | added; removed |
---|---|
Description: | modified (diff) |
Note:
See TracTickets
for help on using tickets.