Proposal:Shade
| Shade | |
|---|---|
| Proposal status: | Draft (under way) |
| Proposed by: | EdH |
| Tagging: | shade=* |
| Applies to: | node, way |
| Definition: | a proposal to record whether a way or node is shaded |
| Statistics: |
|
| Rendered as: | * |
| Draft started: | 2011-07-04, continued July 2021 |
| RFC start: | not_yet |
| Vote start: | not_yet |
| Vote end: | not_yet |
Motivations
Shaded streets, footways, benches, bus stops, and other features are much more pleasant to use on a mid-summer day than similar features lacking shade. People often will forgo sitting on a bench at a bus stop in order to stand in the shade cast by the shelter roof if the sun angle places the bench in the sun. During winter, people may prefer to avoid shade and stand in the sun for warmth.
The purpose of this tag is to record whether a feature has shade during the heat of the day, so that the information can be used for routing. One of the developers of OpenTripPlanner has expressed interest in using shade as a routing criterion for walking, and thinks it it would take less than a dozen lines of code to do so.
The existence of shape also carries implicit information about the 3D structures of surrounding buildings or vegetation, and can therefore support QA and prioritisation of 3D mapping. Shade, its direction, and source is also visible in high resolution imagery, and therefore provides indirect remotely mappable information about object height.
Approaches to mapping shade
As 3-D modeling becomes more common within OpenStreetMap, shade could become a calculated attribute, using position, dimensions of structures and trees, season of year, and time of day, e.g. F4 Map already renders shade from 3D data.
The existing tag covered=* implies shade, as does building=roof, amenity=shelter, particularly with certain roof materials, e.g. roof:material=shadecloth.
This proposal starts from the premise that there are forms of shade for which covered=* and similar tags may be inappropriate, and that recording shade as an attribute of features that are shaded has the potential to be more practical than relying on high accuracy 3D mapping.
The proposal tackles to interrelated issues: 1) differences in shade related to the object casting shade, 2) differences in shade over time. While shade could be tagged as a simple yes/no, there is some value in knowing the source of the shade. For example:
- the roof of a shelter at a bus stop will cast a small area of shade that will move as the day progresses, leaving the shelter itself unshaded for much of the day, and forcing patrons to choose between standing in the shade or sitting on an unshaded bench. On the other hand, if the bus stop is shaded by trees with broad canopies, shade may be continuous throughout the entire day. Tagging shade=roof for the bus stop would indicate that there is a roof (and shelter during rain), but tagging shade=trees would indicate a shadier stop; the apparent conflict for tagging bus stops with shelters and shaded by trees is easily resolved by tagging shelter=yes, shade=trees.
- Shade trees provide additional cooling via transpiration.
- Long porticoes, such as those in Turin, Italy, can provide cooling via the thermal mass of the structure.
- Pergolas provide an element of visual delight and perhaps, depending on plantings, fragrance.
Shade changes over time depending on the position of the sun east-to-west during the day and above the horizon through the seasons (for calculation of position of the sun, see e.g. http://suncalc.net/). In the absence of 3D data, a place can still be described in terms of the directions from which it could be shaded at a given time of the year, indicating that there is an object of the right shape and height in that direction.
If shade is mapped for a specific time of day, the tag name will need to reflect it, e.g. summer_midday_shade. The risk of proliferation of other tags, e.g. winter_midday_shade would need to be considered.
Mapping direction of shade shares similar issues, e.g. presence of shade will typically still depend on the season.
As with lit=*, shade properties potentially vary at very fine spatial scale, but it is not typically appropriate to capture the full level of detail in Openstreetmap due to limits on precision of positions and angles. Mapped shade should be considered approximate. For example, small errors in directions and heights of distant objects can have a big influence on whether shade is actually observed. At the edge of shadows, small changes in length of shade over time may mean that shade is not observed. Shadows may also exist for only short periods of time, e.g. long shadows cast by short objects near sunrise and sunset. Shade should generally therefore be considered a property of existing objects rather than being explicitly mapped in detail. The tagging scheme should make it easier to specify that partial shade exists than it would be to (inaccurately) micro-map shade.
Proposed changes
In progress: see Discussion page.
Examples
Examples currently provide test examples for any potential tagging scheme.
In Example 1, buildings cast shade on footways and bus stops.
- Tagging scheme should capture times of year and times of day that shade is cast.
- Entire footway segments between intersections would be marked as shaded, even if sections within them are not. The tagging scheme could indicate this is the case.
- All segments between intersections in this image would be long enough to be marked as shaded as necessary.
- Bus stops would be marked as shaded as well as covered, as the shadow pattern of the bus stop roof is different from that of the building.
- Only objects for which shade information has an explicit use would be marked, e.g. lamp posts should not be marked as shaded.
In Example 2, a playground is partially shaded.
- Only parts of the playground are shaded, which the tagging scheme could acknowledge.
- The swing (brown box without an icon) is in the shade, as is the bench nearest the tree.
- Other benches and play equipment cannot be mapped as not experiencing shade from this image alone - shade may be cast at other times of day or year.
- Time of day is particularly important, and interpretation of whether shade is desirable will depend on the time of year
- Shade would not be marked for any footway here. The shaded footway to the playground is short and only for access to the destination. The other footways likely have patchy levels of shade throughout the day and year: they cannot be assumed to be shaded or sunny in summer or winter. Marking sub-segment patches of shade is likely to provide low quality of information and is strongly discouraged. Routing would consider shading information irrelevant for these segments.
In Example 3, walking paths are partially shaded by trees.
- In this case, splitting the ways makes sense because the ways are sufficiently long and information about walking conditions is relevant to the use of these tracks.
- The wood to the north-east is sufficiently dense that it can be considered shaded at most times. The clearing would not be taken into account, and the path would be split at the edges of the wood.
- The wood to the south-east is not as dense, and the segment crossing it would be marked as partially shaded. Shade of individual trees should not be micro-mapped.
- Unless the bench is fully shaded at some times, it would likely be marked as sometimes partially shaded without specifying any direction of shading.
- Path segments without trees would be marked as not shaded, even if occasional trees are present.
Rendering
It is not anticipated that shade would be rendered in the main OpenStreetMap renderers, although specialized applications might do so.
Tag values
Values related to type of object casting shade (from 2011). Summer midday shade was implied in this proposal and would need to be made explicit. Overlap with covered=* would also need to be discussed.
| Key | Value | Element | Comment | Rendering | Photo |
|---|---|---|---|---|---|
| shade | none |  
|
The node or way has been checked and is not shaded during the heat of the day.. | ||
| shade | trees |
|
The node or way is shaded by trees during the middle of a summer day. For a node, this could be by a single tree. A footway or other way should be tagged with shade=trees only if there is reasonably complete shade along its length. | ||
| shade | pergola |
|
The way is shaded by a pergola http://en.wikipedia.org/wiki/Pergola supporting vegetation. | ||
| shade | portico |
|
The way is shaded by a portico http://en.wikipedia.org/wiki/Portico or colonnade running the length of a building (more common in Europe than in North America). | ||
| shade | building |
|
The node or way is close enough to the north side of a building that it is shaded at midday during the summer. | ||
| shade | roof |
|
The node or way is shaded by some other impervious structure (awning, roof, or similar canopy other than a portico) capable of providing shade and shelter from rain. If a way runs beneath an archway or tunnel through a building, code the walkway with “breezeway=yes” instead of “shade=roof.” |
Related discussion
See also
- covered=*