1

I'm working thru QGIS trainings and ran into this: Task is to use both a low-res Rainfall SRTM (32733) and a higher-res DEM/SRTM (4326) to produce rainfall, slope, and aspect layers, combine them, then convert and intersect with a land-use vector layer for intersecting habitat.

Hillshade is for aesthetics but the slope and aspect conversions are suffering the same issue.

I think the trouble is arising with the resolution increase required prior to the hillshade, slope and aspect creations.

Hillshades work fine for straight SRTM's. The unreprojected 4326 isn't pretty but I understand that is expected. Once that DEM/SRTM is warp/reprojected from 4326 to 32733 UTM, the Hillshade works fine.

I'm using bilinear warp and I have re-set CRS at each step.

Next step is to set resolution on the Rainfall SRTM to 30m (from ~1730) and then align and set resolution on the DEM/SRTM to 30m (from 88m). No matter if I do these resolution bumps separately or during alignment, the resulting hillshades (and slope, aspect,...) have a windowpane checked pattern.

I've separated the alignment from the resolution bump for now.

The screenshot is of the DEM/SRTM with a GDAL hillshade just after the resolution was bumped from 88m to 30m via export/save as. The hillshade prior to the resolution bump was fine.

I'm out of ideas...

Hillshade from an SRTM after it's resolution was increased from 88m to 30m

4
  • 2
    Does this answer your question? What is the source of horizontal and vertical striping in USGS DEMs?
    – GBG
    Feb 4, 2022 at 22:29
  • This article addresses bilinear vs. near neighbor interpolation upon reprojection, which I am aware of and followed. The problem shows up after resolution increase.
    – DomO
    Feb 5, 2022 at 3:55
  • When you change the resolution, a resampling must also take place as the values have to come from somewhere. That is what @GBG is referring to.
    – Matt
    Feb 6, 2022 at 11:22
  • Does this look somehow similar github.com/OSGeo/gdal/issues/5155? It does not seem to affect all GDAL versions. What is your version?
    – user30184
    Feb 6, 2022 at 17:20

1 Answer 1

0

I have had it at extreme latitudes due to the Y distance (in metres) of a geographic cell approaching double the value of the width (in metres). If you look at the resampling methods (kriging, IDW, etc) and how they work you can begin to understand how this becomes a problem. In my head, if this was your problem it would affect the 90m hillshade as well though.

Anyways, I am sure there are better solutions, but try converting your 90m geographic DEM to as detailed contours as you can deal with given your extent and time available, then project those contours to your projected system and then convert the contours back to a DEM at your desired resolution. Make your hillshade from that.

3
  • Are you saying to increase the resolution of the geographic DEM before reprojecting to UTM?
    – DomO
    Feb 5, 2022 at 15:19
  • I'm saying convert your 90m geographic DEM to 20 m contours, then project those to your linear system and interpolate your 30m DEM from your reprojected contours and derive your hillshade and other products from this layer.
    – Mike
    Feb 7, 2022 at 21:52
  • Turns out the simplest was to bilinear warp resample/re-project from geographic 90 to UTM 30m in one step. I had separated the 2 steps, warp reprojecting but only export/save for 90m to 30m. The resulting cells were decimally larger that 30m so probably caused the pattern. Thanks tho!
    – DomO
    Feb 8, 2022 at 22:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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