Data with a View

This post covers viewsheds – raster grids that indicate which areas are visible from a specific location. (Updated May 2021 for Pro.)

Some of you may remember that stately Timeball Station in Lyttelton:

Coming out of the tunnel and into Lyttelton, it was hard to miss the structure above the port. The castle-like building stood on the ridge above Lyttelton from roughly 1876 until the magnitude 6.3 aftershock on 13 June 2011 reduced it to yet another pile of rubble. The building served two main purposes. Well before the advent of GPS, ships at sea determined their longitude using marine chronometers, highly accurate clocks that could withstand the vagaries of changing temperatures, pressures, and humidities at sea. Knowing the time difference between local noon and noon at Greenwich, England would allow for the calculation of longitude, so at 1.00 every day, (go to the 5 minute mark, footage before this is of the old signal station at Adderley Head) the timeball was dropped so all the ships in the harbour could set their chronometers. The development of marine chronometers and determining longitude is a fascinating story in and of itself (see Dava Sobel’s 1995 book, Longitude, for the in-depth story) but it’s the Timeball Station’s second purpose that concerns the rest of this post. One could easily ask why it sat where it did (it pains me to talk about this in the past tense…). The main reason? The view!

As you can see from the first picture and the one above, the location of the timeball gave it visibility of the ships in port as well as out to Adderley Head at the entrance to Lyttelton Harbour. The entrance to the harbour is not visible from the port itself so the harbourmaster needed a way to know which ships were coming in and to be able to tell them which wharf to tie up to. Prior to radio communications, this was done with flags and semaphore. The location of the Timeball allowed the port a commanding view over the harbour with an impressive viewshed (including Adderley Head where another siting station was set up). Viewsheds are the areas that are visible from a point on the landscape. And here’s the view looking back to Lyttelton from the top of Adderley Head – the stump is the remnant of the signal station’s flagpole:

Below, a zoomed in view with the location of the timeball indicated:

When ships were sited coming in from the sea, the signalmen at Adderley Head would raise flags which could be read at the timeball, giving the name of the ship.  The timeball would then communicate with the harbourmaster, get the berth which the ship should tie up at and send that message back to Adderley Head, where they could then convey it to the ship (exhausting…).  By 1877 there was a telegraph line installed to make communication easier, superceded by a telephone link in 1880 (NZ’s first submarine telephone service according to DOC).

Given the right data, we can use GIS to calculate viewsheds (and I acknowledge that back in the day, they probably just climbed up on the ridge and figured out that this was the right spot).

The data needed for a viewshed are about the earth’s surface (a digital elevation model to be specific) and locations of interest. We can then use GIS to identify which areas are visible from an observation point and which are hidden due to topography. We can also take into account how the visibility changes as we get higher off the ground. For example, the view from the top of Auckland’s SkyTower is a bit more expansive than the one from its base. Here’s how it works.

We start out with a raster grid of elevations (a digital elevation model, or DEM) such as this one for Lyttelton Harbour (this is actually a hillshade map but it’s based on the DEM):

The location of the Timeball is shown as a large red not (not quite to scale of course…). Here it is rendered in 3D with the topo maps for a bit of context

The Viewshed tool is in ArcToolbox > Spatial Analyst Tools > Surface > Viewshed:

Make sure you use a DEM as the input raster – there’s no reason you can’t use any raster grid as your input but the only sensible results will come from a DEM. Next specify the point or line layer (you could derive the viewshed for a road, for example, though it will be calculated from the vertices of the road rather than the line segments) that shows your observation points. Finally, save the output to a safe place. There are options to take into account the curvature of the earth, but that usually only comes into play when looking at larger areas, say several hundred square kilometers. The output from a viewshed analysis is a raster grid with two values, 0 and 1 (this is called a binary map), where 0 for a grid cell means it’s not visible from the observation point and 1 means that it is. For the DEM and observer point shown above, the viewshed is calculated as:

That’s the 2-D version. The blue bits are the cells that are visible from the Timeball location (I’ve made the non-visible cells completely transparent). Draping the viewshed over the DEM and the topo maps gives you a better sense of why it looks the way it does – again the blue bits are visible. (Gosh – this would be a great place to be able to embed a 3D model for you to play around with but I haven’t quite worked out how to do that yet.) Compare this against the picture looking out to Adderley Head above.

If we look closely, my viewshed above doesn’t include Adderley Head when I know from an earlier picture that it should be.  Why’s that?

Two important things to note about this viewshed – 1) given the way we’ve set it up, it’s been determined from ground level, and 2) the DEM is essentially a “bare earth” model, i.e. it doesn’t take into account buildings or trees or features on the landscape.  The top of the timeball is around 10 m above ground level but, happily, I can take that into account.

Viewsheds from above ground level

Often we’ll need to calculate the viewshed from some distance off the ground. For example, we might assume an average eye level for people, say 1.6m, to determine what’s visible to most people, rather than ants. Or we might be determining the viewshed from a tower some distance off the ground. We can take this account to account by adding a new field into our observation point’s attribute table. The name of this field MUST be “OffsetA” (though it’s not case sensitive) and it could be either an integer or float type but it must be a number field. Fields can be added to the table by clicking on Add Field.

This opens up a new window, the Fields View, where I can add in details at the bottom:

Make sure you click Save, , when you’re done.

Once the field has been added you can add new values to the table by right-clicking on the field name and go to Calculate Field. So if I’m finding the viewshed from a 10 m tall above ground, I would add a 10 into this field.

When the viewshed is calculated, Pro will first check and see if an OffsetA field is present. If it is, it will add the value in OffsetA to the elevation at the observer point location (taken from the DEM) and then calculate the viewshed. It gets a bit tricky when you’ve got multiple points so it’s sometimes best to do this point by point by selecting a record in the table and then doing your viewshed.  In the case of the Timeball, adding the height above the ground can make a huge difference- it makes Adderley Head visible at that height of about 10 m above the ground:

There’s also an OffsetB field that could be added, which could take into account the height of another object. A value in OffsetB adds that value to EVERY cell in the grid. So an example might be if you’re doing a viewshed analysis from the point of view of the wind turbine, you would create an OffsetA field for the height of the tower and the for OffsetB you might add a value that represents the average height above the ground of peoples’ line of sight (roughly 1.5 m [though some use 1.65 m]). Check the helpfiles in ArcGIS for a much more complete (though slightly confusing) background. Offsets are just one aspect of control you have over specifying viewsheds.

Bare Earth DEM

This is a much trickier problem to address. Our off the shelf DEM for the country has a 25 m x 25 m resolution (grid cell size), which is 1) quite coarse, and 2) bare earth. To take into account things like buildings or trees, you need to somehow add those into your DEM, or acquire data that explicitly has those features. The closest we come to that second option right now is through the use of LiDAR (Light Detection and Ranging) data; very high resolution elevation data gained from lasers in airplanes (another post in itself), which is becoming more readily available but has patchy coverage and can be a challenge to work with ( just ask Don Royds). In lieu of that, you could use polygon data of building footprints and (if you’re lucky) building heights, and add those heights onto the DEM (leading to buildings taking up entire grid cells – those would be more like warehouses than houses). Trees would be much harder to deal with that way, but a similar approach could be taken.

Viewsheds are a powerful way of determining visibility on the landscape. As with any GIS analysis, you’re ultimately limited by the scale and resolution of your input data. Viewsheds can have an impact wherever visibility is an important consideration, so it gets used in planning, resource management, military applications, siting of transmission towers, siting of landfills and evaluations of the impacts of windfarms. I’ve even come across an example where NASA used viewshed analysis to find appropriate landing spots for several Mars rovers.

C