Opened 15 years ago

Closed 8 months ago

#793 closed defect (wontfix)

USGS DEM Export messes up border.

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

Change History (13)

comment:1 Changed 15 years ago by warmerdam

warmerda@gdal2200[10]% gdal_translate -of USGSDEM baltimore-e out.e
warmerda@gdal2200[11]% gdalchksum.py baltimore-e
47560
warmerda@gdal2200[12]% gdalchksum.py out.e
46330

The checksums should *not* differ.  A visual inspection suggests all
the borner pixels are getting set to the nodata value.  Gillian suggests
that while this happens with the default bilinear interpolator, it does not 
happen with nearest neighbour resampling so it may well be a warper bug. 


comment:2 Changed 15 years ago by matt.wilkie@…

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 Changed 15 years ago by matt.wilkie@…

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 Changed 15 years ago by matt.wilkie@…

yup, projection is not necessary "gdal_translate  -outsize 25% 25% dem_dd
25percent.tif" yields:

Computed Min/Max=-340282346638528860000000000000000000000.000,5950.848

comment:5 Changed 15 years ago by warmerdam

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 Changed 14 years ago by matt.wilkie@…

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 Changed 14 years ago by matt.wilkie@…

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 Changed 14 years ago by warmerdam

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 Changed 14 years ago by matt.wilkie@…

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 Changed 12 years ago by Markus Neteler

Cc: Markus Neteler added; neteler@… removed
Description: modified (diff)

comment:11 Changed 11 years ago by Kyle Shannon

Cc: Kyle Shannon added

comment:12 Changed 4 years ago by Even Rouault

Priority: highnormal

All those tickets have more than one year and nobody has acted on it, so the priority is not so high

comment:13 Changed 8 months ago by Even Rouault

Milestone: closed_because_of_github_migration
Resolution: wontfix
Status: reopenedclosed

This ticket has been automatically closed because Trac is no longer used for GDAL bug tracking, since the project has migrated to GitHub?. If you believe this ticket is still valid, you may file it to https://github.com/OSGeo/gdal/issues if it is not already reported there.

Note: See TracTickets for help on using tickets.