5

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 and how can I avoid this?

Ideally there should be a command-line solution.

Improve this question
4
  • 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. Commented Dec 3, 2014 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. Commented Dec 3, 2014 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... Commented Dec 3, 2014 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. Commented Dec 9, 2014 at 16:17

1 Answer 1

Reset to default
5

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.

Improve this answer
1
  • 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. Commented Dec 9, 2014 at 21:27

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.