Proposal:Key:spacing=*
| spacing | |
|---|---|
| Proposal status: | Inactive (inactive) |
| Proposed by: | Pelderson |
| Tagging: | spacing=number |
| Statistics: |
|
| Draft started: | 2018-04-19 |
| RFC start: | 2018-05-05 |
Proposal
Proposed feature is a new key:spacing=N to indicate estimated average spacing (or it's counterpart: density), of objects along a way or on an area.
The key is proposed as part of a rendering proposal for natural=tree_row, but it's easy to see how it can be applied to any case where objects are more or less grouped or arranged together with a kind of regularity. In that respect spacing=* is a general purpose dimension tag like height, width, length and ele. Think of the spacing of trees in a tree_row or in a forest, or a barrier consisting of lengths of fence between poles. These objects are often described verbally as "very dense", "a tree every 10 feet" or "widely spaced, about 50 meters apart".
The goal is to give a measurement of the spatial distribution along the way or over the area, rather than an exact measurement of distances between separate actual objects. If a tree is a destination or otherwise important object in itself, rather than being just part of a tree_row or forest, it should be individually mapped and tagged as natural=tree. Individual trees may be attached to a tree_row way or on a forest or other natural areas.
Because of the definition as an average, there is no need to worry about the dimension or shape of single objects, or that in fact some are 9 m apart and others are 11 m apart. Measurement is simple: take a sample length of the way divided by the number of sections (= #objects minus one). For areas e.g. forest or orchard, do this measurement in different directions. The more ou measure, the more accurate the average becomes.
Rationale
The need or wish for a method to indicate spacing / density / number of elements per unit of area or per unit of distance has been expressed many times. There is currently no key for this purpose. The distance key might be a candidate but is dedicated to a. total length of routes relations (distance covered). b. distance applied to a node, giving the actual value on a milestone. Using distance=* for spacing/density would be stretching current usage too far, also would not be suitable for an area.
number=* has been suggested. If you know the number of objects, dividing the length of the way by the number of objects minus one gives the average spacing. This would work for small ways, maybe an orchard, but for a row of trees stretching 10 Km along a regional road estimating the number is a problem in itself. For areas e.g. forest it's even more complicated. Another problem would arise when the way is split up: you would need to divide the numnber as well. The spacing value simply remains the same for both parts when splitting up a way or area. No need to alter any tools there.
Average spacing in m can be easily estimated bij pacing two or three objects. This goes for ways and areas alike. More accurngacy could be achieved by pacing more objects.
Possible use of this parameter: vegetation maps or apps, walking maps/planners (allows estimation of possible passage). It allows estimation of number of objects along a way or in an area, which could be useful in maintenance planning. However, the main purpose is adaptive rendering.
NB: The spacing dimensional key does not give or imply exact positions of elements. It specifies the observed density of elements along a way or over an area by measuring or estimating average hart-to-hart spacing.
Examples
(pictures of single/double/triple tree_rows of e.g. poplars, pruned willows, tree_rows on pavement, tree hedges, fences, forest, row of bollards, ?windmill park? showing range of variation).
Tagging
spacing=N where N is average space between points representing objects (e.g. average heart-to-heart distance between trees)
units are in m unless otherwise specified (N u).
Use with natural=tree_row, natural=wood, landuse=forest, landuse=orchard, natural=scrub, barrier=hedge, or any other way or surface with more or less regularly spaced objects.
Note that the key gives spacing for the whole way or area. It is not an attribute of the objects themselves and does not imply exact positions of the distributed objects.
Applies to
- linear ways representing a loosely or densely spaced row of objects, exemplified by a tree_row. Other examples: a row of bollards, a row of stepping stones to cross a waterway, a row of street lights.
- areas representing a surface loosely or densely covered with objects, exemplified by a forest or an orchard. ?Windmill park?
Rendering
The spacing value allows the renderer to adjust the rendering style to show actual average spacing, without having to know exact positions. E.g. the color of a forest on the map could be darker green for lower values of spacing, presumably by applying a conversion of the range of values to e.g. a 3 or 5 point scale, at the discretion of the renderer. Or the tree symbols on a forest could be spaced more closely for lower values.
It is the job of the renderer to avoid the suggestion of exact location of the objects. Cf the tree symbols on a forest area.
For a tree_row, repetitions of a rendering pattern (say a small green cloud+a brown hyphen) could be rendered closer together for lower values. This would give a more realistic impression, while still preserving the symbolic nature of the tree_row rendering: At low values very closed like a hedge, at high values more like a row of green crown-clouds with intermediate stem-hyphens over the landuse or landcover or surface of the area.
A very crude illustration is shown here to the right, just to get the idea. It shows rendering of tree_row using 5-scale spacing, first on grass. The middle one is the default. The upper one would be used for a very widely spaced row of poplars along a motorway. The lower one of the five would be like a hedge with trees every 1 m. The second set shows the same, using different surface colours (e.g. pedestrian area covered with shell grit, or even water) beneath the tree_row.
Note that the key is optional, so the solution is backwards compatible.Leaving it out just means default rendering, same as now.
Rendering aspects for tree_row are discussed in a separate proposal for the OSM carto renderer community. It will involve replacing the "fat green band" with a more suitable repetitive pattern, which would allow more adaptive rendering. The need for change is recognised in the rendering communitiy, but unlike tagging proposals, rendering proposals need designing and coding capacity....
If the spacing=N key (or a comparable dimensioning key) is implemented, it will be introduced there as well.
Features/Pages affected
(2Bcompleted fully when approved)
The proposed key can be added as an optional key to several features (naturals, landuses, barrier, ...?). It does not replace or obsolete anything and there are no conflicts with any other keys or values. The feature is backwards compatible. Problems with mapping tools (e.g. when splitting or extending the way or area) and validation tools are not expected (this was tested on a smal scale).
External discussions
Current: Dutch osm-community, [tagging] list, earlier discussions and proposals on spacing in forests and tree_rows
Comments
Please comment on the discussion page