A View From A Hill

Getting Your Data Up on a Hill: A Practical Guide to Viewshed Analysis

A viewshed analysis determines what's visible from a given point or area on a landscape. You input a digital elevation model, set your observer height and target height, and the software spits out a raster showing which cells can see the point and which are blocked by terrain. That's the whole thing. People make it sound more complicated than it is. I spent about three years working with this stuff for telecom site planning before moving into environmental impact work. The concepts are the same, the applications just shift. The most important thing to understand upfront is that a viewshed is only as good as your elevation data. Garbage in, garbage out, basically. If your DEM has artifacts, no amount of parameter tweaking will fix it.

The Basics of A View From A Hill

At its core, this technique traces straight lines from an observer point out across a terrain model. If a line passes above the ground surface all the way to a target cell, that cell is visible. If the line intersects the terrain at any point before reaching the target, it's blocked. Simple geometry. The complexity comes from handling edge cases and understanding what your results actually mean in the real world. Here's what most beginners get wrong: they treat the output as a definitive map of what can be seen. It isn't. It's a mathematical model based on assumptions about terrain, atmospheric conditions, and observer height that are rarely all correct at once. The output should be treated as a screening tool, not evidence. I've seen reports where people cited viewshed results as proof that a development would be invisible from certain vantage points, and then the actual site visit showed the opposite because they'd used outdated lidar data with a 10-meter cell size in a hilly area.

Setting It Up Properly

You need three things to start: a quality digital elevation model, a point or set of points representing your observer location, and the software to run the analysis. QGIS with the Processing Toolbox works fine for basic cases. For anything requiring legal defensibility or multiple observer scenarios, ArcGIS Pro's Spatial Analyst extension is the standard, though it's not free. Both handle the core calculation the same way. Let me walk through a concrete example. Say you're evaluating whether a proposed 30-meter cell tower would be visible from a trailhead. You'd use a LiDAR-derived DEM at 1-meter resolution minimum if available. Place your observer point at the trailhead elevation, set the observer height to roughly 1.7 meters for an average person's eye level, and set the target height to 30 meters. Run the analysis. The resulting raster will show pink or red cells where the tower would be visible and blue or gray where it wouldn't. Everything is relative to your observer point, so if you need to evaluate visibility from multiple trailheads, you either run multiple analyses or set up the tool to accept a feature class of observer points. One detail that matters a lot and nobody mentions enough: curvature of the earth. At short distances under 10 kilometers it barely matters, but if you're doing regional-scale viewshed work, you need to turn on the curvature correction in your software. Leaving it off will slightly overestimate visibility at range, though the error is usually small enough to ignore for most practical purposes. Atmospheric refraction is the bigger issue and also the one you can't really solve. Standard refraction models exist but they're approximations. On days with temperature inversions, visibility extends significantly farther than the model predicts. I learned this the hard way when my modeled viewshed for a wind farm assessment showed minimal visibility from a valley floor, and then during a morning site visit with a strong inversion layer, every turbine was clearly visible at distances the model said were impossible.

Common Pitfalls and What to Do Instead

The biggest problem people run into is vegetation. Standard viewshed analysis uses bare-earth DEMs, which means trees and buildings aren't factored in unless you specifically add them. If you're doing this for a visual impact assessment, you need to add a land cover layer and adjust the observer or target height to account for canopy. Some workflows use a canopy height model derived from LiDAR classification and add that to the terrain. It's more work but it makes the results actually useful. Without it, you're calculating visibility through trees, which is almost never what anyone wants. Another issue is the distance limit. Most viewshed tools let you set a maximum analysis distance. Setting it too low cuts off valid visible areas. Setting it too high wastes processing time and can introduce edge artifacts. A reasonable default is 10 to 15 kilometers for most site-scale work. Beyond that, the terrain curvature and refraction uncertainties dominate and the results become less reliable regardless of your input data quality. I had a project last year where the client wanted to know if a ridge-top development would be visible from a state park forty kilometers away. The raw viewshed said yes, scattered cells along the corridor were visible. But the model assumed perfect atmospheric conditions and no vegetation screening along the way. I ran a secondary check using a hillshade overlay and manually flagged the specific ridgeline segments that would actually break the horizon from the park's main overlooks. Turns out three small knolls in the middle distance blocked most of the development from the primary viewing areas. The full model would have overstated the impact significantly. Always do a sanity check against actual topography, not just the output raster.

Interpreting the Output

When you get your viewshed raster back, don't just export it and call it done. Look at the actual data. Check the zone statistics to see how many cells are visible versus blocked. If nearly zero cells are showing as visible, either your observer point is wrong, your elevation data has issues, or you set the maximum distance too low. If nearly everything is visible in a mountainous area, your DEM resolution is probably too coarse to capture the ridges blocking the view. For reporting purposes, converting the raster to a polygon layer of visible zones makes it much easier to work with in cartographic layouts. You can then merge those polygons with your study area boundary and calculate the percentage of the area within view. This gives you a single number that's easier to communicate than a colorful raster map, though the raster is better for showing exactly where visibility occurs. The limitation nobody wants to hear about is that viewshed analysis tells you nothing about how noticeable something actually is. A structure might show up in the viewshed but be visually insignificant because it's small, blends with the terrain colors, or is partially screened by vegetation that isn't in your model. Conversely, a structure just outside the modeled viewshed might be plainly visible on a clear day due to atmospheric conditions your model didn't account for. I always recommend combining viewshed analysis with actual photo simulations from key viewpoints when the stakes are high. The photo work takes more time but it catches the things the math misses.

There's also the question of cumulative visibility. A single structure might fall within a small visible area, but add ten more structures in the same ridge line and the visible footprint grows non-linearly. Running individual viewsheds for each feature and then merging the results is the standard approach, but it gets computationally expensive fast. If you're dealing with dozens or hundreds of potential features, consider using a simplified approach: classify the terrain by slope and aspect, identify which terrain classes would be visible from your observer points, and then only run detailed viewsheds for the plausible candidates. I've cut processing time on large projects from several hours down to about twenty minutes using this filtering step.

What Works in Practice

My workflow starts with downloading the latest DEM data from the appropriate source. In the US, the 3D Elevation Program provides 1-meter and 3-meter LiDAR data for most populated areas. Outside the US, national mapping agencies typically offer similar datasets. Download the bare-earth version, not the DSM, unless you specifically need to include buildings and vegetation in your analysis. Then I reproject it to the appropriate local coordinate system before doing anything else. Working in geographic coordinates with unprojected data will give you incorrect distance calculations and skewed results. After setting up the data, I place my observer points and run an initial viewshed with a moderate distance limit to check that the results look reasonable. I compare the visible area against my knowledge of the terrain. If something looks wrong, I go back and check the DEM, the observer point coordinates, and the parameters. Getting this right early saves a lot of rework later. For the final deliverable, I produce both the full viewshed raster for reference and a simplified map showing only the visible areas clipped to relevant boundaries, with a legend and scale bar. I also include a brief methods section noting the DEM source, resolution, observer heights, and maximum distance used. Anyone who's familiar with the area can quickly verify whether the results match reality, and if they don't, the methods documentation gives them enough information to identify where the model might be off.

Look, it's a useful tool but it's not a crystal ball. The output depends entirely on your inputs and assumptions. Use it to narrow down where to focus your attention, not to prove a point conclusively. And for the love of it, verify your results against actual field conditions whenever you can. The difference between a competent analysis and a misleading one is usually just someone taking the extra hour to check whether the model matches what they can see standing on the ground.