3

I've downloaded 9 chunks of 1 arc-second NED in IMG format from the National Map. I'm trying to create a hillshade from them.

I'm using:

GDAL 1.10.0, released 2013/04/24

First, I combine them and change the projection:

gdalwarp -t_srs EPSG:900913 n40w111/imgn40w111_1.img n40w112/imgn40w112_1.img \
n40w113/imgn40w113_1.img n41w111/imgn41w111_1.img n41w112/imgn41w112_1.img \
n41w113/imgn41w113_1.img n42w111/imgn42w111_1.img n42w112/imgn42w112_1.img \
n42w113/imgn42w113_1.img uinta-projected.tif

Then I create a hillshade from uinta-projected.tif:

gdaldem hillshade -compute_edges -co compress=lzw uinta-projected.tif uinta-hillshade.tif

However, when I take a look at my shiny new hillshade, it looks like this: ugly hillshade

Does anybody have any ideas what might be causing this grid artifact? I've tried using gdal_merge.py instead of gdalwarp and I end up with the same result.

gdalinfo uinta-projected.tif:

Driver: GTiff/GeoTIFF
Files: uinta-projected.tif
Size is 9253, 12173
Coordinate System is:
PROJCS["Google Maps Global Mercator",
    GEOGCS["WGS 84",
        DATUM["WGS_1984",
            SPHEROID["WGS 84",6378137,298.257223563,
                AUTHORITY["EPSG","7030"]],
            AUTHORITY["EPSG","6326"]],
        PRIMEM["Greenwich",0],
        UNIT["degree",0.0174532925199433],
        AUTHORITY["EPSG","4326"]],
    PROJECTION["Mercator_1SP"],
    PARAMETER["central_meridian",0],
    PARAMETER["scale_factor",1],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]]]
Origin = (-12579287.992128284648061,5161229.105774102732539)
Pixel Size = (36.130094040215752,-36.130094040215752)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (-12579287.992, 5161229.106) (113d 0' 6.00"W, 42d11'34.83"N)
Lower Left  (-12579287.992, 4721417.471) (113d 0' 6.00"W, 39d11'11.36"N)
Upper Right (-12244976.232, 5161229.106) (109d59'54.57"W, 42d11'34.83"N)
Lower Right (-12244976.232, 4721417.471) (109d59'54.57"W, 39d11'11.36"N)
Center      (-12412132.112, 4941323.288) (111d30' 0.29"W, 40d42'24.63"N)
Band 1 Block=9253x1 Type=Float32, ColorInterp=Gray
  • 3
    I have similar issues at the fixed it by avoiding nearest neighbor in favor of bilinear as the resampling algorithm. The artifacts are not present if you do your analysis on the original unprojected versions of the DEM, but come out after you project them using nearest neighbor (gdal default). The flag in gdalwarp is [-r sampling_method] "bilinear". – Mr.ecos Nov 22 '13 at 19:57
  • 1
    Related to: gis.stackexchange.com/questions/107477 – Hugolpz Mar 1 '15 at 23:50
  • Got the same artifact. It seems, also, after reprojection. @Mr.ecos: could you write down an answer with a clean command example ? gdalwarp -of GTiff -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear input.tif reproj.tif did NOT made it for me. See also gdalwarp – Hugolpz Mar 1 '15 at 23:52
4

-r bilinear

Did your hillshade worked if reprojected using

gdalwarp -of GTiff -s_srs EPSG:4326 -t_srs EPSG:3857 -r bilinear input.tif reproj.tif

? It didn't for me.

Resizing

After some tests :

  1. data => hillshade : fine (good)
  2. data => resizing => hillshade : stripped (bad)
  3. data => resizing => reprojected => hillshade : stripped (bad)

Commands for 3. :

gdalwarp  -s_srs EPSG:4326 -t_srs EPSG:4326 -te -5.8 41 10 51.5 \
    -ts 1980 0  input.tmp.tif resized.tmp.tif # looks good but data is somehow corrupted
gdaldem hillshade resized.tmp.tif shadedrelief-resized.tmp.tif -s 111120 -z 5 -az 315 -alt 60 -compute_edges  # stripes visible

after some further processing we see a lightly stripped hillshade (larger version):

enter image description here

I'am resizing the input.tmp.tif gis data from 819*791px into 1980*1912px. My common resizing is to get the large GIS into smaller size. But if my memory is correct, both resizing up and down create strip artifacts. To avoid the strip I sorted my commands in a different way, from resizing => hillshade => reprojection (bad) into reprojection => hillshade => resizing (good).

The cost is more processing at native data quality, which is usually 10 to 100 times more massive than the resized file.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.