Tag `width` asked, when `width:lanes` is already present about streetcomplete HOT 7 CLOSED

on which object?

All of them, except Werderstraße.

from streetcomplete.

I came across this changeset, which added width tags, while the tag width:lanes was already present a long time

on which object?

from streetcomplete.

width includes also e.g. parking lanes, bike lanes and shoulders while width:lanes only includes full-width through-traffic lanes. This means that adding width on a road with already width:lanes set is not necessarily superfluous. In the changeset you linked for example I see some bike lanes.

(Could it be that width:lanes was actually tagged incorrectly in the place you linked? On the bing aerial imagery, I don't see two lanes, I see only one, plus the bike lane. The documentation on width:lanes is quite scarce - which might be the source of the issue -, but I assume it follows the lanes-schema. Neither parking lanes nor bike lanes should be mentioned in lanes according to the wiki).

from streetcomplete.

Oh nevermind, width:lanes actually uses the *:lanes schema, so, includes bike lanes.

But I don't read anything about shoulders and parking lanes. I suppose the schema only covers through-traffic lanes?

from streetcomplete.

I suppose the schema only covers through-traffic lanes?

I guess, so, as the German Wiki Page also suggests: "The :lanes subkey covers all types of lanes (= flowing traffic) for all types of vehicles [...]". There's nothing about lanes without flowing traffic.

But nevertheless, if there are no shoulders and/or parking lanes, the sum of all width:lanes values is width. So maybe the more correct description is:

Expected Behavior
The question about width of streets is not shown, if the width:lanes is present, except shoulder!=no or (parking:right!=no and parking:left!=no and parking:both!=no) is present.

from streetcomplete.

Plus shoulder:right/left/both != no. Plus, some parkings are completely off the road, while others are half-on-the-road. In the end, it is going to be a pretty long filter to achieve the behavior described in the starter post.

That's fine, if it was really important to exclude asking for the width of roads where width:lanes is already tagged. At the moment, I don't really see it. As width is the vastly more used tag by 3 orders of magnitude, I would expect many data consumers to disregard such relatively fringe tags when processing width data for one use case or another. So, also recording width in addition to width:lanes may actually be useful, and at worst, just superfluous.
The fringe-ness of width:carriageway is the reason why SC also disregards it and asks users to measure the width anyway, even if the mentioned tag is present.

I also wonder how the area in between the outermost lane and the kerb (/ end of paved area) is tagged... i.e. the gutter ... probably not at all because it is usually not broad enough to be considered by most mappers as a shoulder and usually there is no outer lane marking when there is a kerb. Might depend on the country though. At least in (parts of) London, I remember there are lines like that.
In a nutshell, even when there is no parking lane and no shoulder there might still be a difference between width and the sum of all width:lanes albeit probably small (I guess usually 20cm to at most half a meter - anything beyond that would probably be tagged as a shoulder).

Taking a step back, it looks like the issue came up first due to another issue: A user quite grossly mismeasured the width of a road. He tagged "4" but it should be "5", at least according to width:lanes tagged earlier. That is more than 20% difference.

So IMO this is really a separate issue: It looks like the user should rather correct whatever measuring method he is using (again: if the previous width:lanes was correct). It appears that he wasn't using StreetMeasure to measure it (otherwise a source:width=ARCore is set), was he just estimating?

from streetcomplete.

Anyway, I will close this as will not fix.

from streetcomplete.