Proposal:Shrubbery/Explanatory Appendix

Why use natural=* for a landscaped feature?

During voting of the first iteration, a common critique was the use the natural=* namespace for a feature planted and maintained by humans (raised seven times).

We believe that this criticism stems from a misunderstanding of what natural=* means in OSM. Firstly, it is explicitly documented as allowing natural features maintained by humans, but secondly, and perhaps more convincing, is the fact that the two most used tags in this namespace are both used for cultivated as well as true natural use:

• natural=tree is predominantly used for trees planted and/or maintained by humans, usually in urban settings. Forests (natural or otherwise) tend to be mapped as areas instead (obviously).
• natural=water is used for all bodies of water, including naturally occurring and artificial ones.

Thus natural=* should not be read strictly in the sense of its tags being features that are part of (unmanaged) nature, but as features that are natural in origin, which may be planted, cultivated, or otherwise managed by humans.

On supplanting barrier=hedge plus area=yes

Most mappers can safely skip the following section, but anyone concerned about the barrier function of area-hedges might find this interesting.

A little over a year ago Carto dropped support for rendering barrier=hedge plus area=yes; i.e., hedges mapped as areas tagged with barrier=hedge. For the full background these issues explain the reasoning and standpoints of the Carto maintainers: #3844 and #4111.

Broken hedge rendering as reported to Carto in #4111.

This is a rather unique change in Carto, because it didn't just remove rendering (which happens occasionally), but actively broke rendering of hedges mapped as areas in accordance to the documented way of doing this. Several attempts have been made to reach a compromise in re-establishing rendering for this tag combination, but this does not appear to be an option.

So after a year, these are the options available to the OSM community:

• Keep using barrier=hedge plus area=yes, and:
  • keep insisting that Carto fixes rendering, or,
  • accept that rendering in Carto remains broken.
• Stop tagging hedges as areas altogether.
• Come up with an alternative tagging scheme acceptable to all.

When considering what a hedge is, and what defines its most distinguishing properties, it quickly became apparent that most hedges which act as barriers fall within the scope of natural=shrubbery; in particular when tagged with shrubbery:density=dense and an appropriate height=*. Thus this proposal offers a chance to fix a painful issue.

Concern: Bowing to Carto's demands is tagging for the renderer!

While strictly true, Carto has an immense influence on the project as it is the default rendering stylesheet often used as a reference implementation for other styles, and the first thing users see when visiting openstreetmap.org. While defining and using tags that are not rendered is not a problem (especially when there is a chance that they can get rendered in Carto with significant use), having a tagging scheme that results in broken rendering is different. The hedges mapped by mappers following convention and documentation now look broken, so inevitably other mappers will replace them with something that isn't, often (as in the case of using natural=scrub) losing details in the process.

Some community members have suggested that the Carto maintainers should somehow be made to see that they are wrong, and rendering should be restored, but our opinion is that this is not a realistic goal. If it was, this situation would not have endured for over a year. Our viewpoint is that natural=shrubbery offers a chance to introduce a better tagging scheme for barrier hedges mapped as areas in a way that addresses the concerns of the Carto maintainers, and that in the end, having a map with working rendering and a stable tagging solution is preferable to the current situation.

Concern: Losing the barrier=* semantics is a problem

One point of criticism raised in the first round of this proposal is that natural=shrubbery lacks the semantics of barrier=*, which may make routers treat these as impassable unless a gate or other type of entrance is mapped.

We've given this careful though, and conclude that this should not be a problem as long as this is addressed in the documentation for this tag.

The barrier=* tags represent a class of objects that impede progress. For barrier=hedge this means a hedge that cannot be walked/driven in a normal non-destructive manner without getting your clothes torn or soiled. While barrier=* is documented as being applicable to areas as well as nodes and linear ways, from the perspective of navigation software the barrier aspect is really only relevant for these latter two. When a linear barrier crosses a highway in OSM, that highway is may be mapped as a continuous uninterrupted way bisected by the barrier. This is not uncommon for linear barriers that in the real world have only a minimal thickness, and literally sit on top of the surface of the highway=*, such as this fence:

Depending on the intent and preferences of the mapper and actual situation they would usually choose one of these mapping solutions:

When the disjointed method is chosen the tags used for the barrier are not as relevant to the routing process: the ways are not connected, so most routers will not consider routing across it. When the way is contiguous and joined with a node at the intersection with the barrier though, the barrier=* tag informs router algorithms that routing through that barrier is not possible unless other tags (such as barrier=gate or access=* tags on the intersection node) allow for it.

With natural=shrubbery, this is not a problem. Like natural=wood, natural=water, and building=*, natural=shrubbery cannot be used on linear ways by definition, so the example above does not apply. But routers are not necessarily constrained to the mapped highways (although this is common). When navigating to a point of interest, a router may choose to make an effort to guide a user across potentially navigable terrain for the last stretch if no paths are present. So let's look at an example for what this means for natural=shrubbery.

Consider a user who wants to navigate from the edge of Knight's Copse to the firepit over at Roger the Shrubber's cottage. A router such as OSRM or GraphHopper might offer them the route shown below. Note that the router won't send you over the path that goes between the cottage and what is presumably the outhouse, because a barrier=hedge bisects it without a gate or other tags allowing passage. Of course in the case of a (linear) hedge the odds that the physical path actually continues underneath the hedge are small, but for the sake of the example:

But a router instructed to find shortcuts and forego explicitly mapped paths if beneficial might do this:

But that's not very useful to most users is it? A more sophisticated router would have to consider a body of water or a building as impassible unless a path goes across it (like a bridge or a ford in the case of a river). And here barrier=* plays a role too; fences, linear hedges, and other such barriers should be considered impassible (although a really, really clever router may offer the user a way to consider the height=* of such barriers). And as documented, natural=shrubbery should be considered impassible for the average user, so we may end up with this route:

Cutting across a bit of grass is reasonable for most users, and our hypothetical clever router might offer just such a solution. From the router's point of view, the map of barriers looks like this:

Note that natural=water and natural=shrubbery alike can be passed through if the mapper drew a path there, which is as expected, despite lacking the semantics of barrier=*.