Opened 19 years ago

Closed 5 years 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

Description (last modified by Markus Neteler)

 

Change History (13)

comment:1 by warmerdam, 19 years ago

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 by matt.wilkie@…, 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 matt.wilkie@…, 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 matt.wilkie@…, 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 warmerdam, 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 matt.wilkie@…, 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 matt.wilkie@…, 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 warmerdam, 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 matt.wilkie@…, 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 Markus Neteler, 16 years ago

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

comment:11 by Kyle Shannon, 16 years ago

Cc: Kyle Shannon added

comment:12 by Even Rouault, 9 years ago

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 by Even Rouault, 5 years ago

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.