[Tagging] new page for tree_lined=*

Christian Müller cmue81 at gmx.de
Tue Aug 18 03:21:17 UTC 2020

> On 15. Aug 2020, at 12:43, Martin Koppenhoefer <dieterdreist at gmail.com> wrote:
> > On 15. Aug 2020, at 07:32, Volker Schmidt <voschix at gmail.com> wrote:
> >
> > I do see these issues with adding sidewalks and cycle paths, where we have a similar choice between mapping as separate objects or as road property.
> it is often perceived as an either or choice, but there is no reason to not do both.

+1 for doing both. If the data is filtered, e.g. just road data extracted, data consumers will still get generic cycle track information which otherwise will be lost or demands for lots of data preprocessing, i.e. nearby-queries to supplement highway=* tags.

(below info irrelevant to people in a hurry)

Another benefit of this is that the partly redundant data can be used by validators to cross check either
* "osm way has cycleway:left=track, but no geometry found nearby" or
* "cycling track nearby highway with id #1234 found, but no cycleway:*=* tags present"

A small downside is that people may argue that this violates "one feature, one osm element" principle, i.e. if the cycling infrastructure is perceived as an atomistic part of the highway as a whole.  The variation count of different cycling structures (varying in track width, gap width to road, etc.) makes it hard to properly abstract these ground setups in a meaningful/just way.

If we were to define that the separate geometry satisfies that "one osm element", then we should also define that the tags on the nearby highway, describing the same feature, are a) redundant, but encouraged  and  b) do not re-iterate _all_ tags of the feature, but merely a very basic extent.

For example, we have smoothness=*, surface=*, traffic_sign=*, etc.  If these were to be re-iterated all the time this can get quite messy considering cycleway:, cycleway:left, cycleway:right prefixes mentioned, yet potentially adding sidewalk: or footway: prefixes.

IMHO, if a cycleway is mapped as a separate osm geometry, then there should be no more than the usual cycleway=, cycleway:left=, cycleway:right= tags on the highway=* nearby.  I.e. surface tags and the like should not be re-iterated.  There may be data-consumers dissatisfied with such recommendation, but a recommendation should seek to balance usability for data producers, consumers, re-searches and re-validators alike.

The most vital feature in map rendering software may be coloring highway edges according to the presence of cycling infrastructure.  For this use case it is totally sufficient to limit redundant info in the osm db to the three tags bespoken.  More complex consumer use cases will need to preprocess/mine the separate osm geoms for cycleway tracks.


More information about the Tagging mailing list