The data comes as a zip file containing a folder for each major OS grid square, further broken down in many (2,800+) zip files each containing a single 10 x 10km .asc elevation file. For example:
terr50_gagg_gb.zip/data/tq/tq00_OST50GRID_20130401.zip/TQ00.asc
Unfortunately, even with a SSD drive, unzipping all the zip files, as recommended in the user guide, took around an hour and just under 1gb of disk space. Luckily, there is a way to keep these further zip files compressed after the first, main zip file has decompressed and create a single, lean file of the entire British Isles for quick and convenient use in your GIS using the Terminal and GDAL.
The elevation data is ultimately stored in .asc files. I made a list of all the .asc file names stored within the zip folders by decompressing all the individual zip files then running the following command from the /data/ folder with the Terminal (OS X in my case):
find . -name "*.asc" > ~/GB.txt
this outputted a text file listing each individual .asc file. Here’s an excerpt:
./data/tq/tq00_OST50GRID_20130401/TQ00.asc
./data/tq/tq01_OST50GRID_20130401/TQ01.asc
./data/tq/tq02_OST50GRID_20130401/TQ02.asc
./data/tq/tq03_OST50GRID_20130401/TQ03.asc
./data/tq/tq04_OST50GRID_20130401/TQ04.asc
To save yourself this time consuming stage, the text file I generated is available here (note to Ordnance Survey, it would be great if you provided something similar with future releases!). If you carried out the first step the unzipped folders can now be deleted. With a couple of find/replace commands within a text editor, the file paths were altered to
/vsizip//[path]/terr50_gagg_gb/data/tq/tq00_OST50GRID_20130401.zip/TQ00.asc
/vsizip//[path]/terr50_gagg_gb/data/tq/tq01_OST50GRID_20130401.zip/TQ01.asc
/vsizip//[path]/terr50_gagg_gb/data/tq/tq02_OST50GRID_20130401.zip/TQ02.asc
/vsizip//[path]/terr50_gagg_gb/data/tq/tq03_OST50GRID_20130401.zip/TQ03.asc
/vsizip//[path]/terr50_gagg_gb/data/tq/tq04_OST50GRID_20130401.zip/TQ04.asc
where ‘[path]’ is the file path to the terr50-gagg-gb folder. Note that ‘/vsizip//’ and the ‘.zip’ extension were included to allow GDAL to read the many individual .asc files whilst they remain zipped and combine them into a single ‘virtual raster’ mosaic. This edited .txt file can then be fed into GDAL build virtual raster program:
gdalbuildvrt -input_file_list ~/GB.txt ~/GB.vrt
After a very short time the resulting .vrt file is 1.3mb, and accesses the partially compressed terr50 folder that now only occupies 160mb or so disk space. Most importantly, the .vrt file loads into QGIS in a few seconds and can be used exactly like the .asc files would.
You will have installed GDAL alongside QGIS. Your copy of the GDAL build virtual raster will probably be located at /Library/Frameworks/GDAL.framework/Versions/1.11/Programs/gdalbuildvrt depending on the version number.
Best Answer
You can use QGIS for this analysis but do not confuse line of sight calculations with viewshed analysis. They are related but
r.losreturns a raster whose values are null for not-visible or the vertical angle required by the view to see the location. The moduler.viewshedon the other hand returns a raster that simply marks a cell as visible or not (1 or 0). The advantage ofr.viewshedis that, if you have multiple turbines, you can calculate the visibility for each turbine and then simply add all your rasters together and that will give you the number of turbine tips (or hubs depending on the 'observer' height you use) that can be seen at any given location.BUT be careful! Remember that you are effectively doing things backwards if your 'observer' point is a turbine location. So you must set the target elevation to a normal viewer height (1.75m is a good value, though a value of 2m is often applied). The observer height is then set to the turbine tip height.
You need a decent DEM and I would recommend a resolution of 50m or better (50m is the minimum resolution permissible in the UK - you don't sday where you are based but if it is the UK then I reccomend the OS Terrain50 data set). SRTM is really not good enough away from the equator for serious viewshed analysis of planning-application quality (and therefore credibility).
If you have more than a couple of turbines, using GRASS will quickly become tedious due to all the additional steps, unless you script a solution to add them altogether afterwards. Fortunately there are a number of Windfarm packages out there designed to do just this and OpenWind is a free one which is easy to use. See this thread and this one for more discussion on using GRASS with multiple turbines. Also, here is a thread on how to use OpenWind.