Timeline for Losing resolution of my DEM/TIFF when converting from HGT
Current License: CC BY-SA 3.0
21 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Jun 5, 2017 at 0:37 | vote | accept | Magno C | ||
Jun 4, 2017 at 2:29 | answer | added | Magno C | timeline score: 0 | |
Jun 4, 2017 at 0:28 | history | edited | Magno C | CC BY-SA 3.0 |
added 211 characters in body
|
Jun 3, 2017 at 23:35 | comment | added | Magno C |
@Michael Miles-Stimson please tell me more about the pixel size. I'm playing with the -tr XRes YRes and discovered lower is better. changing to a small value like 0.00005 seems to improve the resolution but the file size become huge.
|
|
Jun 3, 2017 at 1:42 | history | edited | Magno C | CC BY-SA 3.0 |
added 187 characters in body
|
Jun 2, 2017 at 18:52 | history | edited | Magno C | CC BY-SA 3.0 |
added 267 characters in body
|
Jun 2, 2017 at 18:00 | comment | added | Magno C | Or this: gis.stackexchange.com/questions/12833/smoothing-dem-using-grass | |
Jun 2, 2017 at 16:03 | comment | added | Magno C | This may help : gis.stackexchange.com/questions/144535/… | |
Jun 2, 2017 at 14:26 | history | edited | Magno C | CC BY-SA 3.0 |
added 226 characters in body
|
Jun 2, 2017 at 14:01 | history | edited | Magno C | CC BY-SA 3.0 |
added 157 characters in body
|
Jun 2, 2017 at 13:59 | comment | added | Magno C |
Same poor results. Trying now with gdaldem hillshade test.vrt test.tif -z 1 -s 80000 and got better result but far from what I need. See my edit. Seems I need to play with z and s parameters but have no idea what I'm doing...
|
|
Jun 2, 2017 at 3:13 | comment | added | Michael Stimson | -tr (starting from gdal 2.0) set target resolution. The values must be expressed in georeferenced units. Both must be positive values. This is mutually exclusive with -outsize and -a_ullr. What version is your GDAL? You might need to get a more recent version; multiple GDAL installs can happily coexist, I use 2.1 x64 and am quite happy with it but have older versions installed for dependent software. In the older versions you could still use -outsize. | |
Jun 2, 2017 at 3:09 | comment | added | Magno C |
Can't find -tr option in my gdal_translate . Didn't you mean gdal.org/gdalwarp.html ?
|
|
Jun 2, 2017 at 3:06 | history | edited | Vince | CC BY-SA 3.0 |
loose->lose
|
Jun 2, 2017 at 3:03 | comment | added | Michael Stimson | Your pixel size is 0.000277777777778 so a -tr 0.001389 0.001389 will resample to 5 times the cell size, you might need to go higher than 5 so it might be a good idea to try only one of your downloaded images resampling coarse and back to fine until you're happy with the output then run it on the whole VRT. | |
Jun 2, 2017 at 2:58 | comment | added | Magno C | See my edit for gdalinfo result. | |
Jun 2, 2017 at 2:58 | history | edited | Magno C | CC BY-SA 3.0 |
added 1190 characters in body
|
Jun 2, 2017 at 2:52 | comment | added | Michael Stimson | After you've created the VRT use GDAL_TRANSLATE gdal.org/gdal_translate.html with -tr XRes YRes -r bilinear to convert the VRT into a single image (I would recommend -of HFA or GTIFF) to resample the raster. It's not clear what your original cell size is but you can get it with GDALINFO gdal.org/gdalinfo.html | |
Jun 2, 2017 at 2:48 | comment | added | Magno C | I'm a complete newbie on this. I'll appreciate some code examples. I'll consider as nice something like this:blog.mastermaps.com/2012/06/… or this i.sstatic.net/b6i3y.jpg | |
Jun 2, 2017 at 2:45 | comment | added | Michael Stimson | It looks like your DEM is bumpy and needs to be smoothed, though looking nice isn't a quantitative term, you could try resample to 5 times the cell size using bilinear then back to the original cell size with the same resample method to smooth the raster prior to creating the hillshade. Just remember the DEM is now inaccurate, you will loose the peaks and dips, so don't do anything with it except for hillshade. | |
Jun 2, 2017 at 2:39 | history | asked | Magno C | CC BY-SA 3.0 |