r.skyline can output up to 5 raster maps and 1 plain text CSV file, as described here.
The skyline_index map records, for each cell in the viewshed, the difference between the inclination of the line-of-sight from that cell back towards the viewpoint and the inclination of the line-of-sight from the viewpoint towards the point on the horizon opposite the cell in question. If this skyline index is positive, then the viewpoint would appear to be raised above the skyline, whereas if it is negative then it would appear below the skyline. This option requires two input viewshed maps, viewshed and viewshed2, which must both record inclination values (the default output from r.viewshed and the only ouput from the older r.los). Note that the validity of the skyline index depends upon the user setting appropriate observer (viewpoint) and target offsets when creating the input viewsheds - see NOTES for important information about how to use this function.
The hoz_azimuth map identifies the cells that fall on the horizon and records the azimuth at which they appear from the viewpoint. The horizon depicted on this map may include cells that occur at the maximum viewing distance from the viewpoint and/or at the edge of the current region. Since such cells may not really represent the point beyond which no more land is visible it may be prudent, depending on the purpose of the analysis, to generate a hoz_type map.
The hoz_inclination map identifies the cells that fall on the horizon and records additional data derived from the input viewshed map. If that map was computed with r.viewshed then the hoz_inclination map will record either the inclination (r.viewshed default), simply '1' meaning that the cell was visible (r.viewshed -b flag), or the elevation difference between the viewpoint and horizon cell (r.viewshed -e flag). If the input viewshed map was computed with the olderr.los then the hoz_inclination map will record the inclination at which the horizon cells appear from the viewpoint. Note that in all cases the horizon depicted on this map may include cells that occur at the maximum viewing distance from the viewpoint and/or at the edge of the current region. Since such cells may not really represent the point beyond which no more land is visible it may be prudent, depending on the purpose of the analysis, to generate a hoz_type map.
The hoz_type map records the kind of horizon represented by each horizon cell. This distinguishes horizon cells as follows:
Note that type 1 horizon cells might not really fall on the true horizon if increasing the maximum viewing distance used when calculating the viewshed would also increase the viewshed size. Type 2 and 3 horizon cells might or might not fall on the true horizon - there is no way for this module to determine that.
The edges map records all viewshed edges, which may be of interest when the viewshed in not contiguous (i.e. there is more than one 'patch' of visible land). In this case a marked cell may represent one of the following: the point at which land becomes visible; the point at which land becomes temporarily invisible before becoming visible again; the point beyond which no more land is visible. We refer to case 2 as a 'near horizon' and case 3 as a 'far horizon'. The hoz_azimuth, hoz_type and hoz_inclination maps, and the profile only record 'far horizon' cells. The edges map uses the same coding scheme as the hoz_type map.
The plain text CSV file profile records various properties of the 'far' horizon cells. This is sorted by increasing azimuth, so is useful for plotting horizon profiles clockwise from North.
It is important to understand that the validity of the skyline index requires careful consideration of the observer (viewpoint) and target offsets used to create the two input viewshed maps. r.skyline supports the use of 2 different viewshed maps to ensure that the correct inclination values are used for the horizon and line-of-sight back towards the 'viewpoint'. The following example explains how these may be used. Suppose you wish to calculate the skyline index for all locations in the landscape from which a 3m high building is visible, in other words whether the top of that building appears above, on or below the horizon behind it. There are three steps:
The code does not deal with Lat/Long databases.
The module only runs when the current region has integer resolution (since the algorithm is not robust in cases where resolution is non-integer).
The skyline index emerged out of conversations with Barney Harris, UCL Institute of Archaeology, University College London, UK.
© 2003-2021 GRASS Development Team, GRASS GIS 7.8.6dev Reference Manual