[Tagging] Streets with gradually increasing widths

Sebastian Gürtler sebastian.guertler at gmx.de
Thu Aug 17 22:29:38 UTC 2023


Am 16.08.23 um 06:33 schrieb Kashish via Tagging:
> Thanks for the responses, everyone.
>
> It's not too important to me that we use the median width for width=*, so if we use width:start=*/width:end=*, we can continue using width=* for the minimum width.
>
> Tagging way nodes with width=* or width:carriageway=* was actually my first attempt at a solution, but I preferred pbnoxious' suggestion of width:start=*/width:end=* - that way, what is arguably a property of the way is associated with the way rather than its nodes. There's another issue - way nodes may be shared by multiple ways, resulting in ambiguity.
>
> The workaround of splitting up the way at different points and adding different width=* tags to each segment is inelegant, but has many things going for it - namely compatibility with existing routers and preventing existing editors from messing up data.
>
> Now I'm thinking of documenting two solutions on the wiki -
>
> 1. width:start=*/width:end=*, optionally with width=* for the minimum width of the street, and with a word of warning about the results of editors splitting ways.

I'd really discourage this. The word of warning is useless. Whom do you
want to warn? The mapper? The data consumer? The programmer of an
editor? And what should each one do precisely after having been warned?

The data in such tags just won't be reliable. Splitting of ways is very
common. Just think about the algorithms you would have to implement to
check the validity of the tags width:start and width:end: for using the
data you would have to go back in the history to the time where the tags
were set initially, then look for the consistency of the way.

Then you would need an algorithm to estimate the width at the splitting
point. Just assuming that the width has a linear relationship to the
length of the way, you would have to calculate the length of the parts
of the former way to calculate this estimate. Then maybe you would like
to rewrite the corrected data to the osm database? (read about automated
edits!) Or would you like the editors to do this calculation? But: the
values at the splitting point are no more measurements but
extrapolations, you should document this in the data.
source:width:start=extrapolated ?!?! or adding an automated fixme=width
estimated automatically, please measure again on the ground.

This seems a lot of automated data needed with little use and less accuracy.

The suggestion of putting width=xyz into a node looks better at first
sight, but doesn't work for nodes at crossings. But this would be not so
bad, in the algorithms you only need to ignore a width-tag on a
crossing, by the cost of checking for multiple usage of a certain node
by different ways.

Cheers, Sebastian

>
> 2. Splitting the way and using existing width=* etc tags on the segments, and noting the benefits of this approach.
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging



More information about the Tagging mailing list