Imagico.de

blog

atlas_w3_crop1

Use of high resolution SRTM in 3D views

| 2 Comments

The Atlas Mountains views introduced in the previous post are my first use of the SRTM high resolution data in 3d rendering. Here a higher resolution crop for comparison (first is the 1 arc second data, second 3 arc seconds):

This well illustrates what i have already written in my analysis – that the resolution gain from the new data is fairly small. There is a lot of noise coming with the higher resolution grid – not as much as with ASTER GDEM but still quite visible.

It is not so easy to quantify the actual resolution but various claims you can read on the internet now with triple resolution, nine times as much data, 30 meter elevation data etc. are exaggerated. Without making a specific quantitative claim it is fair to say that the gain from the old 3 arc seconds data to the newly released data is much less than from the new data to what would be possible in principle based on a 1 arc second grid. It is a bit like with the Megapixel inflation of digital cameras…

The noise can also be a problem in map rendering since it can severely affect readability of a map. When you generate relief shading or contour lines strait from the raw relief data this will be dominated by the small size features which is largely noise in case of the high resolution SRTM data. With proper processing the data can however be used for a better articulated depiction of relief.

2 Comments

  1. Looking at Mapbox’s posts about the SRTM update it seems that, on the contrary, there are great inprovements. For example:

    https://www.mapbox.com/blog/asia-terrain-update

    Specially in the last comparison image, it’s lear that there is an inprovement in showing the ruggedness of the terrain, which is good for outdoors maps.

    On a side note, could you talk a little about the hardware and software you’re using to generate the contour lines? I tried running gdal_contour in a nimbly laptop with 8GiB of RAM for a region as big as Europe and I run out of RAM, so I had to generate them in tiles of 1×1 degrees. Were those tiles overlap, I can see two hypsolines crossing each other, and I have no idea how to properly merge them.

    • Well – in the end it is a matter of taste of course and how you use the map. What you perceive as ruggedness is however mostly noise and no actual information. To me the Mapbox work on terrain depiction seems quite provisonal and unfinished so i do not think an in depth critique is actually warranted here at the moment. It is not that their original terrain style was particularly well readable in the first place but it is hard to perceive anything about the terrain structure with their new styling in many places – see for example

      https://www.mapbox.com/labs/terrain/#12/27.6530/88.2755

      This is however not at all unexpected – good relief rendering is one of the hardest things there is in map design and there are no patent remedies. On the bright side the challenges this presents are nothing new so studying the classical literature (like Imhof) can be really useful. Even now with all the digital processing and remotely sensed data what constitutes a well readable depiction is still the same.

      And yes, i will on occasion write a bit more about contour line generation. I already said that trying to generate contours from the raw, unprojected elevation data is never a good idea. In principle gdal_contour is perfectly fine for the contouring task itself, it is mostly how you process the elevation data before running it through gdal_contour and how you process the resulting contours afterwards what makes the difference.

Leave a Reply

Required fields are marked *.

*

CAPTCHA

*