Trees now block line of sight
A viewshed is the map of everything you could see from one point. Until now it stopped at bare ground, so a forest hid nothing. Tick "Include trees in simulation" and woodland from OpenStreetMap becomes solid canopy your sight line has to clear, 15 m tall by default. The 3D map draws those woods tree by tree. Free, in the browser, no account.
Why forest changes what you can see
A mature stand of spruce is 15 to 30 m of solid green. What your eye runs into is the canopy, the closed roof of foliage on top of the trunks. A person on the far side of that wood is simply not visible, even across flat, open ground. Climb a 30 m observation tower and you look straight over the same wood to the clearing behind it. Height decides it. Until now the map ignored the part of the height that is made of trees.
There is a second reason, and it sits in the elevation data. The AWS Terrarium tiles the simulator reads are a patchwork of national and global models, and they do not treat trees the same way. In the United States, Canada, Great Britain, Norway, Austria and New Zealand the heights come from national terrain models. Those describe bare ground, because the vegetation is filtered out when the model is built, not because the survey failed to see it. Most of Europe, Switzerland included, is covered by EU-DEM instead, the rest of the world by SRTM, and the land north of 60° by ArcticDEM. SRTM and EU-DEM leave part of the canopy standing in the ground they report, so a wooded slope there reads a few metres too high. The same slope is bare earth in one country and part tree in the next, and no elevation model tells you where the trees actually are. A summit viewshed for hikers was always honest about ridges and silent about the wood at the bottom of the slope. All of this belongs to the LOS / Viewshed mode. RF coverage is a separate calculation, and this switch does not touch it.
What the toggle does
In LOS mode the control panel now carries a box called "Include trees in simulation". Tick it and every wood the map tiles carry becomes a solid obstacle at the canopy height set in the same box. The default is 15 m, the field takes 1 to 150 m, and the same number drives the 3D display.
Two details matter more than they sound. Targets sit on top of the canopy, the way they already sit on roofs, so you see the treetops and not the ground under them. The observer is the exception. A carve-out of three by three pixels keeps the ground clear underneath. Someone standing in the wood is therefore measured from the forest floor, and the canopy around them hides them at once.
Buildings and trees compose rather than stack. A house inside a forest polygon ends at whichever is higher, roof or canopy, never at roof plus canopy. The rest of the obstruction behaviour is unchanged and written up in Including buildings.
The same viewshed, without and with trees
One observer, one run, one setting changed.
With trees off, the green runs across the valley floor and up the far slope, and only the terrain hides anything. With trees on, the wooded strips go dark, and what stays in view is the clearings, the meadows and the tops above the canopy. The terrain did not change. Only the surface the sight line has to clear did.
How the trees are drawn
From zoom 14 up, the 3D styles stop painting forest as a flat texture and draw individual trees. Each tree is placed inside the OpenStreetMap polygon on a grid of roughly 15 m, about 40 trees per hectare, and each stands on its own ground elevation, so a stand climbing a slope climbs with it. The placement is deterministic, so a tree never jumps when you zoom or pan, and the height follows the canopy setting. Below zoom 14, and in the 2D styles, it is a draped texture again.
All of it happens in the browser. Every forest tile already on screen becomes a tree tile on the fly, with no server and no download beyond the map tiles you had anyway.
What the engine actually does
It is the same trick that makes buildings block sight. A WebAssembly build of the Aether converter rasterises the forest polygons into the terrain tiles, raises the ground under that mask by the canopy height, and runs the ordinary viewshed on the result. Sight lines never learn about trees. They simply meet higher ground, at about half a second per 2048 by 2048 tile.
Where the data is good, and where it is not
The model is only as good as the polygons behind it. Tree cover comes from OpenStreetMap through the OpenMapTiles landcover layer, plus the boundaries of US national and state forests, which are assumed to be forested throughout. Adding those boundaries took a test tile over the Hoosier National Forest from 0 % to 97 % recall, meaning the share of real canopy that falls inside a mapped polygon. Coverage is all or nothing by area. Either a wood is mapped, or it does not exist here.
- Europe, Canada and Australia are well mapped. On fourteen test tiles checked against Global Forest Watch canopy for 2020, the European, Canadian, boreal and tropical ones caught 75 to 99 % of the tall canopy.
- The United States is all or nothing. Public land came out well once the national and state forest boundaries were counted, which lifted the Idaho Bitterroot and the Colorado Rockies from 0 % to 100 %. Private timberland is the gap: test tiles in Maine, Michigan’s Upper Peninsula, Alabama and Georgia returned no polygons at all.
- Japan and Kenya come in around 75 %.
- Much of the Global South is thinly mapped, so a result there will look more open than the ground is.
- Polygon edges land within about 5 to 20 m of the real treeline, which is fine for a viewshed and too coarse for a sight line grazing a forest edge.
- Heights are absent from the data entirely, which is why the canopy height is a number you choose.
So check the map first. Turn the forest layer on and look. If the wood you care about is not drawn, OpenStreetMap has no polygon there and the run cannot know about it. Adding it in OpenStreetMap fixes it for everyone. Tree cover is © OpenStreetMap contributors (ODbL), delivered as OpenFreeMap vector tiles in the OpenMapTiles schema.
What is not modelled
- RF coverage still ignores vegetation entirely. There is no foliage-loss model yet, ITU-R P.833 is a separate task for the engine, an RF result is not changed by this switch, and the RF tab has no trees box.
- Every tree is the same height. One assumed canopy stands in for young and old stands alike.
- Every polygon is solid. A leaf-off winter wood is see-through in places, and an old, open stand has more sky than green. The model hides everything behind it all the same.
- Targets under the canopy read at treetop height. Only the observer gets the ground carve-out, so a person on a forest path counts as visible unless you place them there.
Next come measured heights instead of assumed ones. A global canopy-height raster from Meta and the World Resources Institute (CC BY 4.0) gives a height per pixel.
How to try it
- Open the simulator and keep the mode on LOS / Viewshed.
- Tick "Include trees in simulation" in the control panel.
- Set the canopy height: 12 m for young or boreal woodland, 15 m as the default, 25 to 30 m for mature conifer or tropical forest, up to 150 m.
- Set the eye height, 1.7 m for a person on foot, more for a tower or viewing platform.
- Place the observer, run it, then untick the box and run again. The difference is what the forest costs you.
The legend under the result reads "Trees modelled as opaque obstacles (assumed canopy 15 m, OSM polygons + US national/state forests)", so a screenshot carries its own assumptions.
Related tools
For the quick answer without a map, three tools do the job. How far can you see turns an eye height into a horizon distance and shows how much of a distant summit the curve hides. The elevation profile draws the ground between two points with the sight line over it, settling one "is it visible from there" without a full viewshed. Distance and bearing gives the direction to look once you know the answer.
Run a wood you know
Pick a forested valley you have walked, run it both ways, and see how much of that green was really air.