> On 15. Aug 2020, at 12:43, Martin Koppenhoefer <dieterdre...@gmail.com> wrote:
> > On 15. Aug 2020, at 07:32, Volker Schmidt <vosc...@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.


Regards


_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Reply via email to