4

Here is my workflow for importing individual SRTM tiles into postgis using the GDAL utils and rendering a png using mapnik:

  1. gdal_fillnodata.py -srcnodata -32768
  2. gdal_contour -i 10 -a ele -snodata -32768
  3. ogr2ogr -f PostgreSQL -nln srtm3 -append -t_srs 'EPSG:900913'
  4. (some SQL to split the data into 10m, 50m and 250m tables)
  5. nik2img.py [stylesheet] [file] --srs 900913 -d [width] [height] --no-open -f png -v --center [center] --zoom [zoom]"

Most of the time this works perfectly. However, large areas with mountainous terrain are often completely distorted: enter image description here

enter image description here

Huge swaths of landscape are covered with strange (often linear) patterns that shouldn't be there. No way the SRTM data is that messed up. What am I doing wrong? How can I avoid this? Ideally there should be a command-line solution. Thanks in advance!

  • I have found 'smoothing' the input raster produces more 'pleasing' contours (the opposite of accurate). You can do this by resampling the raster and then if needs be resample back.. for 1m cell I resample to 2m then back to 1m. You can do this using either GDALwarp or GDAL_Translate. – Michael Stimson Dec 3 '14 at 5:22
  • Thanks for the tip! Which resampling method do you suggest? I get some smoothing with the "smooth" option in Mapnik, but GDALwarp should be more accurate. Still wondering about those huge artifacts though. – kontextify Dec 3 '14 at 9:47
  • Do they align with cell boundaries? I use bicubic resampling (not in GDAL) which should be similar to cubic or cubicspline resample method. Perhaps it would be better to go with smaller cells by half, third or quarter to smooth out the bumps. Are the contours being created in geographic coordinates? Perhaps the slope is overflowing because the cells are so small, try in an appropriate UTM projection... – Michael Stimson Dec 3 '14 at 22:10
  • Thanks. I tried cubic, cubicspline and bilinear. The contours are mostly smoother but can also be jagged and "pixely". The ogr2ogr command takes care of proper projection. I found that the problem is in the data and posted the details in my answer. – kontextify Dec 9 '14 at 16:17
4

Here was my problem:

No way the SRTM data is that messed up.

The SRTM data IS that messed up. The warping above is actually in the DEMs in the SRTM3 dataset (downloaded from http://dds.cr.usgs.gov). After examining DEMs from the improved SRTM4 dataset (available here) I found that most of these "gaps" were filled by interpolation but other issues (including strange "pixelation" in mountainous areas) remain.

I don't think SRTM is a good solution unless you inspect every tile you or your users see (not possible for me). I am now looking at ways to process the ASTER data instead.

  • There really is no substitute for good data. There are tricks to try to improve bad data but as the saying goes you can't make a silk purse from a sows' ear. – Michael Stimson Dec 9 '14 at 21:27

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.