zoran-cuckovic
commented
3 years ago Hello,
Yes, this is correct - the output has the same size (in pixels !) as the input DEM. This facilitates the integration of the result with other models, made for the same DEM. This has not changed since the first version.
Note that your result may even be larger in memory footprint than the DEM, depending on the compression method. In fact, what changed between 1.5 and 1.6 versions is the compression method - I had to remove it for large DEMs because it was causing a strange disk bloat. FYI, it was gdal LZW option, but I'm unaware of the causes for this problem (I have to study gdal code ...). Therefore, I chose to remove compression until I test it more thoroughly.
Anyway, you can always manually compress (right click on Layer -> Save as).
Best, Zoran
Hello, First of all, thank you for this very well made plugin. I am doing batch viewshed analysis for a study in the Eastern Desert of Egypt for roman towers. I just have updated the plugin version from 1.5 to the last 1.6 and noticed that now the output viewshed have the same disk space as the input DEM whatever the visibility radius. The viewshed spatial extent remains the same as that of the DEM with nodata for areas outside the visibility radius. To reduce the disk space of the output, we should now cut the DEM around the observation point (with a square buffer for example) before launching the viewshed analysis. However, the analysis works very well. Best regards.