New answers tagged srtm
This is problem in the GDAL library. It appears that GDALSuggestedWarpOutput() is giving weird output for width and height of the output file. I haven't found a way to work around this yet.
The Dolphin file team? also believes that the file manager is detecting the wrong file type based on "magic numbers", see: https://forum.kde.org/viewtopic.php?f=224&t=124038&p=325861#p325861 Again, thank you looking into this and hopefully it will provide an answer for others. pitney
I can reproduce TeX and TGA type displays, but not the text file, in Nautilus file manager on ubuntu 12.04 LTS: SRTM3 v2.1 downloads from USGS: S35E147.hgt.zip, S36E117.hgt.zip, N33E006.hgt.zip I think there is nothing wrong with the files themselves. It's probably the way Linux is detecting file types that goes wrong in some cases here. HGT (stands for ...
You might try the USGS SRTM FTP site. I can assure you that each of the tiles you list as examples are there in their proper .hgt format and there are no suspicious files in the associated zip file. And here is the tile S35E147, buffered with the surrounding eight tiles as well:
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 ...
Top 50 recent answers are included