Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-29 Thread Volker Schmidt
May I injection another complication: In many jurisdictions the width
available to the moving traffic is defined by white lines on the tarmac
creating an additional safety/buffer zone between the marked parking spaces
and the flowing traffic.

On Tue, 29 Sep 2020, 12:52 Pieter Vander Vennet, 
wrote:

> Hey Alex,
>
> First of all, I didn't consult the community for this project, I just
> wanted to get it rolling. We pondered a long time about how to measure
> for our local situation, not about what would be the most appropriate
> tag for use worldwide. Sorry for that and again, if in these discussions
> a better consensus pops up, I'll retag.
>
> I included parking lane width, as in some cases there are no lines on
> the ground indicating where the parking lane begins. We just have a
> traffic sign indicating that parking is allowed. As a result, the area
> available for traffic can vary when a very small car or very wide car is
> parked - the main reason we went with a curb-to-curb distance -
> including parking-lanes.
>
> The actual width available for traffic is then calculated based on OSM
> data. Can cars go in one or two directions? Can bicycles go in one or
> two directions? Are sidewalks present?
>
> I understand that 'width:carriageway' is confused with the room
> available for traffic. On the other hand, parked cars are a 'carriage'
> as well ;)
> Furhtermore, in my opinion, saving a 'width:traffic_area' directly into
> OSM is unnecessary (as an indicative value can be calculated from the
> other, more objective properties) and is even a bit subjective and prone
> to change (e.g. due parked cars). Did you know that the avarage car has
> gotten ~30cm wider since 1960? This means that the calculation of
> 'traffic_area' should be changed every few years.
>
> Also keep in mind that in the city center of Bruges, where we did those
> measurements, we don't have the 'half-on-curb' rules and have only a few
> perpendicular/diagonal parking lanes (which I conveniently ignored).
>
> Anyway, I'm not planning on getting too involved in this discussion (I
> have other things to do). However, Alex, I would propose to turn around
> your logic: not to map the traffic area, but to map 'width:carriageway'
> as 'curb-to-curb' distance, and mapping the 'parking:lane:left:width'
> and 'parking:lane:right:width'-values. If the parking lane doesn't have
> lines (and thus the width isn't well defined), software can choose a
> sensible default for the region. This would also work for
> 'half-on-kerb': if there is a line, one can use the line to determine
> the width. If not, software can use a sensible default.
>
> The drawback of this scheme is that software which wants to work with
> this data should be somewhat complicated right from the start.
>
> --
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-29 Thread Pieter Vander Vennet
Hey Alex,

First of all, I didn't consult the community for this project, I just
wanted to get it rolling. We pondered a long time about how to measure
for our local situation, not about what would be the most appropriate
tag for use worldwide. Sorry for that and again, if in these discussions
a better consensus pops up, I'll retag.

I included parking lane width, as in some cases there are no lines on
the ground indicating where the parking lane begins. We just have a
traffic sign indicating that parking is allowed. As a result, the area
available for traffic can vary when a very small car or very wide car is
parked - the main reason we went with a curb-to-curb distance -
including parking-lanes.

The actual width available for traffic is then calculated based on OSM
data. Can cars go in one or two directions? Can bicycles go in one or
two directions? Are sidewalks present?

I understand that 'width:carriageway' is confused with the room
available for traffic. On the other hand, parked cars are a 'carriage'
as well ;)
Furhtermore, in my opinion, saving a 'width:traffic_area' directly into
OSM is unnecessary (as an indicative value can be calculated from the
other, more objective properties) and is even a bit subjective and prone
to change (e.g. due parked cars). Did you know that the avarage car has
gotten ~30cm wider since 1960? This means that the calculation of
'traffic_area' should be changed every few years.

Also keep in mind that in the city center of Bruges, where we did those
measurements, we don't have the 'half-on-curb' rules and have only a few
perpendicular/diagonal parking lanes (which I conveniently ignored).

Anyway, I'm not planning on getting too involved in this discussion (I
have other things to do). However, Alex, I would propose to turn around
your logic: not to map the traffic area, but to map 'width:carriageway'
as 'curb-to-curb' distance, and mapping the 'parking:lane:left:width'
and 'parking:lane:right:width'-values. If the parking lane doesn't have
lines (and thus the width isn't well defined), software can choose a
sensible default for the region. This would also work for
'half-on-kerb': if there is a line, one can use the line to determine
the width. If not, software can use a sensible default.

The drawback of this scheme is that software which wants to work with
this data should be somewhat complicated right from the start.

-- 
Met vriendelijke groeten,
Pieter Vander Vennet

<>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-29 Thread Peter Elderson
What about the many streets and roads where the kerb or lining is bended
and curled to cut the parking lane into sections?

Best, Peter Elderson


Op di 29 sep. 2020 om 11:40 schreef Supaplex :

> Now I am a little confused.
>
> As I understand Pieter, you used "width:carriageway" in Bruges in a way
> that includes parking:lanes (although you can estimate later how much is
> effectively not available for flowing traffic if using parking:lanes).
>
> My initiative for a clarification of the tagging was motivated among other
> things to find a distinction between width *with* and *without* parking
> lanes in order to not only indirectly estimate the effective width but to
> measure it directly. Personally, I had understood "width:carriageway" to
> mean only the effective width available for flowing traffic. But maybe this
> is exactly the right term for the measurement from curb to curb and we
> still need a new term for the effective width ("width:traffic_area")? Or is
> it anyway illusory to specify the effective width of a roadway, because it
> has no "fixed limit" (parking cars are changeable) and you can only
> estimate it anyway by a combination with "parking:lane"...?
>
> I think it would be helpful to be able to specify an effective width if
> needed. After all, this is the most interesting parameter for assessing the
> quality/usability of a street. Even with a full parking:lane-tagging the
> estimation is worse than simply measuring it directly. For example, in the
> case of "half_on_kerb" parking it is not clear to assume that exactly half
> the average vehicle width is "lost" on the carriageway - sometimes there is
> only one tire on the sidewalk and two thirds of the vehicle occupies the
> roadway. Also global assumptions for the loss of width when parking
> "diagonal" or "perpendicular" seem unrealistic to me. De facto, parking
> lanes almost always occupy a constant area, and the effective width of the
> carriageway can be specified to within a few decimeters on site or on
> aerial photographs.
> What do we do now? My (new) suggestion: "width:carriageway" means the
> total road width from curb to curb or from edge to edge of the road
> surface. "width:traffic_area" (or another suitable term; so far nothing
> comparable is in use as far as I see) could be used to indicate the
> effective width available for flowing traffic.
>
> Alex
>
>
> Am 27.09.20 um 22:47 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>
> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  
>  wrote:
> This width was tagged with 'width:carriageway'.
>
>
> I think this is a good tagging decision, being explicit about which width you 
> have measured seems the way to avoid ambiguity. (and it still leaves room for 
> the next project which could measure sidewalk widths ;-) ).
>
> Cheers Martin
>
>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-29 Thread Supaplex
Now I am a little confused.

As I understand Pieter, you used "width:carriageway" in Bruges in a way
that includes parking:lanes (although you can estimate later how much is
effectively not available for flowing traffic if using parking:lanes).

My initiative for a clarification of the tagging was motivated among
other things to find a distinction between width /with/ and /without/
parking lanes in order to not only indirectly estimate the effective
width but to measure it directly. Personally, I had understood
"width:carriageway" to mean only the effective width available for
flowing traffic. But maybe this is exactly the right term for the
measurement from curb to curb and we still need a new term for the
effective width ("width:traffic_area")? Or is it anyway illusory to
specify the effective width of a roadway, because it has no "fixed
limit" (parking cars are changeable) and you can only estimate it anyway
by a combination with "parking:lane"...?

I think it would be helpful to be able to specify an effective width if
needed. After all, this is the most interesting parameter for assessing
the quality/usability of a street. Even with a full parking:lane-tagging
the estimation is worse than simply measuring it directly. For example,
in the case of "half_on_kerb" parking it is not clear to assume that
exactly half the average vehicle width is "lost" on the carriageway -
sometimes there is only one tire on the sidewalk and two thirds of the
vehicle occupies the roadway. Also global assumptions for the loss of
width when parking "diagonal" or "perpendicular" seem unrealistic to me.
De facto, parking lanes almost always occupy a constant area, and the
effective width of the carriageway can be specified to within a few
decimeters on site or on aerial photographs.

What do we do now? My (new) suggestion: "width:carriageway" means the
total road width from curb to curb or from edge to edge of the road
surface. "width:traffic_area" (or another suitable term; so far nothing
comparable is in use as far as I see) could be used to indicate the
effective width available for flowing traffic.

Alex


Am 27.09.20 um 22:47 schrieb Martin Koppenhoefer:
>
> sent from a phone
>
>> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  
>> wrote:
>> This width was tagged with 'width:carriageway'. 
>>
>
> I think this is a good tagging decision, being explicit about which width you 
> have measured seems the way to avoid ambiguity. (and it still leaves room for 
> the next project which could measure sidewalk widths ;-) ).
>
> Cheers Martin 
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-27 Thread Martin Koppenhoefer


sent from a phone

> On 27. Sep 2020, at 13:45, Pieter Vander Vennet  wrote:
> This width was tagged with 'width:carriageway'. 
> 


I think this is a good tagging decision, being explicit about which width you 
have measured seems the way to avoid ambiguity. (and it still leaves room for 
the next project which could measure sidewalk widths ;-) ).

Cheers Martin 

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


[Tagging] "width" on streets: Time for a recommendation

2020-09-27 Thread Pieter Vander Vennet
Hi everyone,

After seeing the message on the weekly, I had to chime in.

We recently did the same exercise for the city of Bruges  and we
measured the width of every street in the old city center. The reason is
that the cycle lobbying group wants to change legislation in the city
center to be more bike friendly. Thé argument for this is that the
streets are to narrow for cars and that the "cyclestreet"-legislation
should apply everywhere.

But politics aside, I helped a lot measuring the street widths! It
resulted in a nice map:
https://pietervdvn.github.io/MapComplete/index.html?layout=width=51.21=3.2229

But of course, this is the tagging mailing list, so let's discuss the
technicalities.

First of all, most of the measurements are made with a laser distance
meter. In order to be very objective, we measured from /curb to curb/.
Curbs don't move, where as parking lanes, lines indicating parkings, ...
can move. (If no curb is present, wall of the houses was used). As we
are mainly interested in the /conflict**/arising, we measured at the
narrowest point of the street (but ignoring obstacles as street
furniture). In a few places, the GRB (belgian topographic map with
houses) was used (which is very accurate too).

This width was tagged with 'width:carriageway'.

(Apart from that, we also added parking lane information, which is used
to deduct how much room of the carriageway is used for car parking, how
much for driving, how much for cycling. Based on that, we can calculate
in which streets there is too little space).

If a consensus is reached that this should be some other tag, I'm fine
with retagging this for Bruges - but not in the coming month; the
interactive map has to be widely published the coming days and weeks.

-- 
Met vriendelijke groeten,
Pieter Vander Vennet

<>___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-22 Thread Jan Michel

Hi,
I think that's fine, with two remarks from my side:

You write "shoulder:width" but "sidewalk::width". It should be 
made clear that  (left,right,both) can be used in all cases, but 
is optional. E.g. there is no difference between sidewalk:width and 
sidewalk:both:width.



"If the width cannot be measured exactly, but is only an estimation, 
est_width=* should be used."
I disagree here - the obvious problem is how to define "exactly" and 
"estimation". Why should the tag change depending on how precise the 
mapping is? Should we have a "est_building" tag if we can't draw a 
precise outline? How is "width" different?





On 21.09.20 15:52, Supaplex wrote:
As a result of this discussion I would like to add a clarifying 
paragraph on the corresponding wiki page. The core statement is: "To 
avoid these ambiguities, some tags are in use to specify the width of 
different elements: ..." See the Talk Page: 
https://wiki.openstreetmap.org/wiki/Talk:Key:width#.22width.22_on_streets.2Fhighway


Maybe someone has time and motivation to make a proposal(?) to directly 
define "width" in these cases. Since there are different opinions on 
this, I would leave it at a clarifying paragraph for now.


- Alex -




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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-21 Thread Supaplex
As a result of this discussion I would like to add a clarifying
paragraph on the corresponding wiki page. The core statement is: "To
avoid these ambiguities, some tags are in use to specify the width of
different elements: ..." See the Talk Page:
https://wiki.openstreetmap.org/wiki/Talk:Key:width#.22width.22_on_streets.2Fhighway

Maybe someone has time and motivation to make a proposal(?) to directly
define "width" in these cases. Since there are different opinions on
this, I would leave it at a clarifying paragraph for now.

- Alex -


Am 14.09.20 um 20:34 schrieb Supaplex:
> Hey all,
>
> again and again there are discussions about which parts of a street
> (sidewalks and cycle paths, parking lanes, carriageway) should be
> considered when determining the width of a street. There does not seem
> to be a consensus and therefore information on street widths is
> difficult to interpret or is not even mapped. The following variants are
> common/are discussed:
>
> 1) Width of the actual carriageway, without parking lanes and sidewalks
> 2) Width between curbs / edges of the road without sidewalks, but with
> parked cars when they are on street
> 3) Width including sidewalks / roadside paths
>
> I tend to option 2):
> - The width can be clearly defined and measured
> - The width of the actual carriageway can be determined by using
> "parking:lane" scheme correctly (or alternatively/supplementarily by
> specifying the width of parking lanes). "width:carriageway" (or
> "width:lanes", if there are marked lanes) also could be used to map this
> width directly.
> - The width of roadside paths can optionally be specified with
> "sidewalk:width" etc.
>
> Wouldn't it be time to document a recommendation in the Wiki to reduce
> further ambiguities? Which variant is the most recommendable? Anyway,
> the width of a street is a significant value to evaluate its suitability
> or safety for certain modes of transport or to determine the speed that
> can be expected there.
>
> Thanks for your comments,
> Alex
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-20 Thread Tobias Zwick
>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. 

I don't think this is true anymore. Did you try out "Measure" or any other 
ARCore/ARKit-based measuring app? Example:

https://m.youtube.com/watch?v=qz0YJ0s4JLM

Am 20. September 2020 00:01:00 MESZ schrieb Volker Schmidt :
>Some thoughts that trouble me...
>
>To me it seems obvious that width values, independently on how they are
>measured, are at best estimates, as measuring them is in most cases
>dangerous or requires good technical equipment. I guess that most width
>values in the database are reality estimates (I don't think that this
>is an
>unjustified extrapolation from my own mapping - 99.9% of my width
>tagging
>based on estimates). Estimates are relatively easy for narrow roads if
>you
>have street-level photographs. They become much more unreliable for
>wider
>roads. I solve this by using only lanes count for wider roads. Precise
>width measurements are difficult to impossible, but fortunately they
>are
>also less important than the lanes count for the end user.
>
>The discussion about including/excluding sidepaths/sidewalks becomes
>also
>irrelevant if we were only to use the lanes count as that counts only
>motor
>traffic lanes.
>
>Would also overcome another aspect of the width definition: If we use
>width
>for the entire road, i.e motor-traffic lanes, shoulders, sidewalks,
>cycle
>lanes/tracks/paths, tree rows between foot and cycleway, ... we do in
>the
>end not know enough about the the actual widths of the different
>component
>"lanes".
>
>Width values are useful and easy to estimate from street-level
>photographs
>for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m
>precision.
>
>We need in any case a good system for regrouping parallel ways that
>belong
>to the same street.
>A relation seems to me the better option, but in any case, whatever
>approach we pick now, we will face an nearly impossible amount of
>retrofitting work. Anything we do on this from now will not make the
>problem go away with the existing stock of data.
>
>Volker
>
>
>
>
>
>
>
>
>
>Virus-free.
>www.avast.com
>
><#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>On Fri, 18 Sep 2020 at 22:35, Tobias Knerr  wrote:
>
>> On 17.09.20 02:35, Taskar Center wrote:
>> > This is yet another example why "sticking" the sidewalks onto the
>> > highway (as a tag) rather than mapping them as separate ways is
>> > appearing to be less and less practical. Please see our sidewalk
>schema
>> > proposal
>> >
>
>> > from several years ago.
>>
>> Your sidewalk proposal unfortunately doesn't really address the
>crucial
>> shortcoming of separately mapped sidewalks: The lack of a reliable
>> mechanism for figuring out which section of road a given sidewalk way
>> belongs to.
>>
>> I agree that we should be able to give sidewalks their own geometry,
>but
>> we _also_ need the relationship between sidewalk and road. So far,
>all
>> the proposals attempting to support the former end up sacrificing the
>> latter.
>>
>> There have been some promising discussions recently around the
>> sidepath_of idea, but that's still just brainstorming. Until a
>practical
>> solution is found and actually used in the database, sidewalk mapping
>> will remain a choice between two options that are broken in different
>ways.
>>
>> As for the main issue of the thread: I would welcome a clear
>definition
>> for the meaning of width. In my own mapping and when writing the
>> relevant code in OSM2World, I have counted sidewalks etc. as part of
>the
>> road's width if they are mapped as tags on the main way. But I would
>of
>> course change that if there finally was a documented and widely
>> agreed-upon recommendation. I don't care so much which one it is -
>but
>> we need one.
>>
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-19 Thread Volker Schmidt
Some thoughts that trouble me...

To me it seems obvious that width values, independently on how they are
measured, are at best estimates, as measuring them is in most cases
dangerous or requires good technical equipment. I guess that most width
values in the database are reality estimates (I don't think that this is an
unjustified extrapolation from my own mapping - 99.9% of my width tagging
based on estimates). Estimates are relatively easy for narrow roads if you
have street-level photographs. They become much more unreliable for wider
roads. I solve this by using only lanes count for wider roads. Precise
width measurements are difficult to impossible, but fortunately they are
also less important than the lanes count for the end user.

The discussion about including/excluding sidepaths/sidewalks becomes also
irrelevant if we were only to use the lanes count as that counts only motor
traffic lanes.

Would also overcome another aspect of the width definition: If we use width
for the entire road, i.e motor-traffic lanes, shoulders, sidewalks, cycle
lanes/tracks/paths, tree rows between foot and cycleway, ... we do in the
end not know enough about the the actual widths of the different component
"lanes".

Width values are useful and easy to estimate from street-level photographs
for sidewalks, cycle paths/lanes/tracks, certainly to within 0.5m precision.

We need in any case a good system for regrouping parallel ways that belong
to the same street.
A relation seems to me the better option, but in any case, whatever
approach we pick now, we will face an nearly impossible amount of
retrofitting work. Anything we do on this from now will not make the
problem go away with the existing stock of data.

Volker









Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Fri, 18 Sep 2020 at 22:35, Tobias Knerr  wrote:

> On 17.09.20 02:35, Taskar Center wrote:
> > This is yet another example why "sticking" the sidewalks onto the
> > highway (as a tag) rather than mapping them as separate ways is
> > appearing to be less and less practical. Please see our sidewalk schema
> > proposal
> > 
> > from several years ago.
>
> Your sidewalk proposal unfortunately doesn't really address the crucial
> shortcoming of separately mapped sidewalks: The lack of a reliable
> mechanism for figuring out which section of road a given sidewalk way
> belongs to.
>
> I agree that we should be able to give sidewalks their own geometry, but
> we _also_ need the relationship between sidewalk and road. So far, all
> the proposals attempting to support the former end up sacrificing the
> latter.
>
> There have been some promising discussions recently around the
> sidepath_of idea, but that's still just brainstorming. Until a practical
> solution is found and actually used in the database, sidewalk mapping
> will remain a choice between two options that are broken in different ways.
>
> As for the main issue of the thread: I would welcome a clear definition
> for the meaning of width. In my own mapping and when writing the
> relevant code in OSM2World, I have counted sidewalks etc. as part of the
> road's width if they are mapped as tags on the main way. But I would of
> course change that if there finally was a documented and widely
> agreed-upon recommendation. I don't care so much which one it is - but
> we need one.
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-18 Thread Tobias Knerr
On 17.09.20 02:35, Taskar Center wrote:
> This is yet another example why "sticking" the sidewalks onto the
> highway (as a tag) rather than mapping them as separate ways is
> appearing to be less and less practical. Please see our sidewalk schema
> proposal
> 
> from several years ago.

Your sidewalk proposal unfortunately doesn't really address the crucial
shortcoming of separately mapped sidewalks: The lack of a reliable
mechanism for figuring out which section of road a given sidewalk way
belongs to.

I agree that we should be able to give sidewalks their own geometry, but
we _also_ need the relationship between sidewalk and road. So far, all
the proposals attempting to support the former end up sacrificing the
latter.

There have been some promising discussions recently around the
sidepath_of idea, but that's still just brainstorming. Until a practical
solution is found and actually used in the database, sidewalk mapping
will remain a choice between two options that are broken in different ways.

As for the main issue of the thread: I would welcome a clear definition
for the meaning of width. In my own mapping and when writing the
relevant code in OSM2World, I have counted sidewalks etc. as part of the
road's width if they are mapped as tags on the main way. But I would of
course change that if there finally was a documented and widely
agreed-upon recommendation. I don't care so much which one it is - but
we need one.

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-17 Thread Martin Koppenhoefer
Am Do., 17. Sept. 2020 um 02:37 Uhr schrieb Taskar Center :

> This is yet another example why "sticking" the sidewalks onto the highway
> (as a tag) rather than mapping them as separate ways is appearing to be
> less and less practical.
>


why should these be mutually exclusive alternatives ("rather than")? The
sidewalk tags on the road are a property of the road that tell if there is
a sidewalk, and on which side. This does not prevent you from mapping the
sidewalk explicitly as highway=footway and footway=sidewalk.

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-17 Thread Alan Mackie
On Thu, 17 Sep 2020, 01:37 Taskar Center,  wrote:

> Hi,
>
> This is yet another example why "sticking" the sidewalks onto the highway
> (as a tag) rather than mapping them as separate ways is appearing to be
> less and less practical. Please see our sidewalk schema proposal
> 
> from several years ago.
>
This is all well and good for roads without tree cover in areas where the
imagery is good. At other times a tag on the road is the best option if you
don't want to just make up geometry.

>
> I think @Mark brings up really relevant width distinctions, and I believe
> that once we agree that sidewalks require their own geometry, we should
> have a similar discussion about the interpretation of width in the
> sidewalks context.
>
> I look at this issue from the perspective of routing. Routers are
> interested in functional width (which would be Mark's 'driven path'
> option). Even with the consideration of transiency of both of the last two
> of Mark's definitions, 'maintained' and 'driven path' width, this is a much
> better approximation for additional considerations than routing- it can be
> an indicator of traffic stress, it can provide information for the 'slow
> streets' movement, it can also provide a means of reconciling improper
> imports that labeled all roads as 'primary' when they should not.
>
> My last comment has to do with the separation of sidewalks from streets-
> in that in many locales the responsibility of street maintenance falls on a
> different entity than sidewalk maintenance (for example, in Seattle, the
> sidewalk is the responsibility of the homeowner, rather than the
> municipality who IS responsible for the street infrastructure). So it is
> actually advantageous to have these mapped as separate entities so we can
> keep track of infrastructure maintenance.
>
> Best regards,
>
> Anat
>
>
>
> Sent from my mobile. Please excuse brevity and typos.
> On Wed, Sep 16, 2020 at 1:23 AM Supaplex  wrote:
>
>> I expect the "width" of a way to be the actual width of the object it
>> represents.
>>
>> It depends on how we define "highway" in the OSM sense. You could also
>> assume that sidewalks etc. are "sticking" on the highway merely for
>> pragmatic reasons. Depending on the point of view, sidewalks and highways
>> represent different entities. (There is no law definition here, I only find
>> a German court decision that deals with street widths and thus means the
>> distance between the curbs, with carriageway and parked vehicles, so as
>> definition 2 above.)
>>
>> But I agree that it would be better to always specify which width is
>> meant exactly when mapping widths on streets (especially to use
>> "width:carriageway" for the rating of traffic suitability). Nevertheless, a
>> default, which meaning of "width" is meant without a prefix/suffix, would
>> still be helpful. Fun Fact: On the wiki highway page - in contrast to what
>> is discussed here - it says since 2012 that "width" means the width of the
>> carriageway (but it does not look like this paragraph has ever been
>> discussed):
>> https://wiki.openstreetmap.org/wiki/Highways#Surface.2C_width_and_lighting
>>
>> Alex
>> ___
>> Tagging mailing list
>> Tagging@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Taskar Center
Hi,

This is yet another example why "sticking" the sidewalks onto the highway (as a 
tag) rather than mapping them as separate ways is appearing to be less and less 
practical. Please see our sidewalk schema proposal from several years ago.

I think @Mark brings up really relevant width distinctions, and I believe that 
once we agree that sidewalks require their own geometry, we should have a 
similar discussion about the interpretation of width in the sidewalks context. 

I look at this issue from the perspective of routing. Routers are interested in 
functional width (which would be Mark's 'driven path' option). Even with the 
consideration of transiency of both of the last two of Mark's definitions, 
'maintained' and 'driven path' width, this is a much better approximation for 
additional considerations than routing- it can be an indicator of traffic 
stress, it can provide information for the 'slow streets' movement, it can also 
provide a means of reconciling improper imports that labeled all roads as 
'primary' when they should not. 

My last comment has to do with the separation of sidewalks from streets- in 
that in many locales the responsibility of street maintenance falls on a 
different entity than sidewalk maintenance (for example, in Seattle, the 
sidewalk is the responsibility of the homeowner, rather than the municipality 
who IS responsible for the street infrastructure). So it is actually 
advantageous to have these mapped as separate entities so we can keep track of 
infrastructure maintenance.

Best regards,

Anat



Sent from my mobile. Please excuse brevity and typos.
> On Wed, Sep 16, 2020 at 1:23 AM Supaplex  wrote:
>> I expect the "width" of a way to be the actual width of the object it 
>> represents.
> It depends on how we define "highway" in the OSM sense. You could also assume 
> that sidewalks etc. are "sticking" on the highway merely for pragmatic 
> reasons. Depending on the point of view, sidewalks and highways represent 
> different entities. (There is no law definition here, I only find a German 
> court decision that deals with street widths and thus means the distance 
> between the curbs, with carriageway and parked vehicles, so as definition 2 
> above.)
> 
> But I agree that it would be better to always specify which width is meant 
> exactly when mapping widths on streets (especially to use "width:carriageway" 
> for the rating of traffic suitability). Nevertheless, a default, which 
> meaning of "width" is meant without a prefix/suffix, would still be helpful. 
> Fun Fact: On the wiki highway page - in contrast to what is discussed here - 
> it says since 2012 that "width" means the width of the carriageway (but it 
> does not look like this paragraph has ever been discussed): 
> https://wiki.openstreetmap.org/wiki/Highways#Surface.2C_width_and_lighting
> 
> Alex
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Jeroen Hoek
On 15-09-2020 10:09, Martin Koppenhoefer wrote:
> Am Mo., 14. Sept. 2020 um 20:37 Uhr schrieb Supaplex
> mailto:supap...@riseup.net>>:
> indeed, mapping the width generally requires measuring the width, and it
> is often not practical (unless you are willing to spend a lot of time or
> have very good aerial imagery at hand).

It will vary a lot per country and the available resources. In the
Netherlands we are blessed to have both yearly 25cm satellite imagery,
and municipal topography outline layers available. Those two, combined
are really quite nice to have.

In JOSM it looks like this:

http://jeroenhoek.nl/temp/josm-dutch-bgt.png

Measuring the width of a street (option 2) is often trivial with these;
in this case it seems to be a neat 6m.

I wonder if it is feasible to have JOSM render the width, optionally, as
a sort of semi-transparent background beneath the way-line. It would
make aligning these to the middle of the street even easier, and tagging
the width less error prone too due to the visual feedback.

Jeroen Hoek

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Grzegorz Szymaszek
On Wed, Sep 16, 2020 at 07:02:26PM +0200, Jeroen Hoek  
wrote:
> I wonder if it is feasible to have JOSM render the width, optionally, as
> a sort of semi-transparent background beneath the way-line.

JOSM can already do it:
https://josm.openstreetmap.de/wiki/Styles/Lane_and_Road_Attributes

-- 
Grzegorz


signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Jan Michel

On 16.09.20 10:30, Martin Koppenhoefer wrote:

On 15. Sep 2020, at 19:05, Jan Michel  wrote:

If you want to tag how much space there is for some kind of vehicle moving in 
some direction, there are the specific width tags like width:lanes, 
sidewalk:width, cycleway:width, shoulder:width, verge:width
and so on.


following your initial statement (all parts), you would include the verges in 
the width?


That's a difficult point. I'm not a friend of the 'verge' tag at all (as 
opposed to the 'shoulder' which is an area traffic can make use of). It 
was somehow invented and put to use in 2016, but as far as I know never 
discussed. I definitely prefer to tag verges as separate objects - even 
one of the examples in the Wiki shows a ~5m wide park like area with 
trees to be tagged as verge. I think it's really far-fetched to call 
this a part of the highway.


To answer your question - no, because I don't see verges as part of the 
road.




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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Martin Koppenhoefer


sent from a phone

> On 15. Sep 2020, at 19:05, Jan Michel  wrote:
> 
> If you want to tag how much space there is for some kind of vehicle moving in 
> some direction, there are the specific width tags like width:lanes, 
> sidewalk:width, cycleway:width, shoulder:width, verge:width
> and so on.


following your initial statement (all parts), you would include the verges in 
the width?


Cheers Martin 
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-16 Thread Supaplex
> I expect the "width" of a way to be the actual width of the object it
> represents. 
It depends on how we define "highway" in the OSM sense. You could also
assume that sidewalks etc. are "sticking" on the highway merely for
pragmatic reasons. Depending on the point of view, sidewalks and
highways represent different entities. (There is no law definition here,
I only find a German court decision that deals with street widths and
thus means the distance between the curbs, with carriageway and parked
vehicles, so as definition 2 above.)

But I agree that it would be better to always specify which width is
meant exactly when mapping widths on streets (especially to use
"width:carriageway" for the rating of traffic suitability).
Nevertheless, a default, which meaning of "width" is meant without a
prefix/suffix, would still be helpful. Fun Fact: On the wiki highway
page - in contrast to what is discussed here - it says since 2012 that
"width" means the width of the carriageway (but it does not look like
this paragraph has ever been discussed):
https://wiki.openstreetmap.org/wiki/Highways#Surface.2C_width_and_lighting

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Martin Koppenhoefer


sent from a phone

> On 15. Sep 2020, at 21:39, Mark Wagner  wrote:
> 
> Which one is "the" width of the road?


not only from year to year but also with the seasons...

Cheers Martin 

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Mark Wagner
On Tue, 15 Sep 2020 10:09:17 +0200
Martin Koppenhoefer  wrote:

> on unpaved
> roads, measure the extent of the maximum width that vehicles actually
> use, on a medium to narrow part of the highway (i.e. do not add the
> smallest width to a long stretch of highway if it only occurs for a
> short part, rather split the highway in this case of tag the narrow
> exceptions explicitly while using a medium value for longer
> stretches).

In my experience, unpaved roads don't have a well-defined width.
Typically, you've got the following options, roughly from widest to
narrowest:

1) Obstacle-free width: the distance that's clear of fences, trees,
ditches, brush, boulders, and other obstacles.  Not well-defined for
roads in farm country, which may be obstacle-free all the way
to the next road, and misleading in ranch country, where the nearest
obstacle is usually the fence marking the edge of the right-of-way.

2) Vegetation-free width: the distance clear of any vegetation.
Usually the easiest to spot and measure, but may include things such as
spoil from road maintenance which are unsuitable for driving on.

3) Maintained width: the distance that's kept smooth, level, and firm
through regular maintenance.  This is probably the closest to the
"curb-to-curb" or "edge-to-edge" width of a paved road.  This has the
problem that it can change from year to year as graders take different
routes eg. around curves, and is difficult to tell apart from the
vegetation-free width. It also has the problem that many roads are not
maintained except for removal of fallen trees and other obstacles.

4) Driven path: the portion of the road regularly used by drivers.
Unpaved roads frequently develop a well-defined set of ruts that are
easy to measure.  However, this width varies rapidly with road
conditions.

Which one is "the" width of the road?
-- 
Mark

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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Jan Michel

On 15.09.20 10:52, Martin Koppenhoefer wrote:

Looking at width tag variants:
https://taginfo.openstreetmap.org/search?q=width

here are those with more than 1K uses


Please be careful with such a list. E.g. width:shoulder stems
from a user in Finland and from something that looks like an old
(un-)organized edit in Nepal that used several other uncommon tags as 
well. The documented tag is 'shoulder:width'



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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Jan Michel
I expect the "width" of a way to be the actual width of the object it 
represents.

This obviously changes depending on the mapping style applied, e.g.

- if it's a highway with sidewalk and cycleway tags, it's the width of 
all of it


- if it's just a road with footways mapped as separate ways next to it, 
then it's the width of just the road.


If you want to tag how much space there is for some kind of vehicle 
moving in some direction, there are the specific width tags like 
width:lanes, sidewalk:width, cycleway:width, shoulder:width, verge:width

and so on.

Jan


On 14.09.20 20:34, Supaplex wrote:

1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with 
parked cars when they are on street

3) Width including sidewalks / roadside paths



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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Mateusz Konieczny via Tagging



Sep 14, 2020, 20:34 by supap...@riseup.net:

>
> Hey all,
>
>
> again and again there are discussions about which parts of a  street 
> (sidewalks and cycle paths, parking lanes, carriageway)  should be 
> considered when determining the width of a street. There  does not seem 
> to be a consensus and therefore information on  street widths is 
> difficult to interpret or is not even mapped. The  following variants are 
> common/are discussed:
>
>
>
> 1) Width of the actual carriageway, without parking lanes and  sidewalks
>  2) Width between curbs / edges of the road without sidewalks, but  with 
> parked cars when they are on street
>  3) Width including sidewalks / roadside paths
>
>
>
>
> I tend to option 2):
>  - The width can be clearly defined and measured
>  - The width of the actual carriageway can be determined by using  
> "parking:lane" scheme correctly (or alternatively/supplementarily  by 
> specifying the width of parking lanes). "width:carriageway" (or  
> "width:lanes", if there are marked lanes) also could be used to  map this 
> width directly.
>  - The width of roadside paths can optionally be specified with  
> "sidewalk:width" etc.
>
>
>
> Wouldn't it be time to document a recommendation in the Wiki to  reduce 
> further ambiguities? Which variant is the most  recommendable? Anyway, 
> the width of a street is a significant  value to evaluate its suitability 
> or safety for certain modes of  transport or to determine the speed that 
> can be expected there.
>
>
>
> Thanks for your comments,
>  Alex
>
>
>
I would also expect (2)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Volker Schmidt
On Tue, 15 Sep 2020 at 10:34, Tobias Zwick  wrote:

> I plan to soon implement a "What is the width of this road" quest in
> StreetComplete where the user can measure the width of the road using his
> or her smartphone (similar to the app Measure from Google [1]). The app
> will need to instruct the user very clearly what should be measured.
>

With the satellite photos that OSM can legally use, we usually have a
resolution problem. In most cases it will be tricky to get to a precision
better than one metre, which in my view is not enough.
Alternative: use est_width=  or width= plus source.width=estimated
Another problem are the contrast enhancement filters that most satellite
images are subject to. They oftenwiden the roads to some extent or create
an artificial limiting line, depending on the filtering algorithm.
In case there are Mapillary Mapillary photos you can, in many countries,
count the stripes of zebra crossings (in Italy they are 0.5m wide) to
measure the width of urban roads.



Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Martin Koppenhoefer
Am Di., 15. Sept. 2020 um 10:34 Uhr schrieb Tobias Zwick :

> I was under the impression that the wiki already defined it like 2).
>


If it were like this it would be fortunate, because we already have nearly
1,9 million highways tagged with "width", and if we could reasonably expect
that these are following the definition, we would maybe not have to resort
to yet another key like width:carriageway

Looking at width tag variants:
https://taginfo.openstreetmap.org/search?q=width

here are those with more than 1K uses (ignoring yh:WIDTH which is leading
even before the main tag, but clearly not a recommendable format for tags,
as it isn't self explaining and has uppercase letters, and ignoring those
that do not seem to refer to roads):

cycling_width
cycleway:est_width
shoulder:width
width:lanes
width:street
sidewalk:width
sidewalk:right:width
width:lanes:forward and backward
cycleway:width
crossing:width
cycleway:left:width
sidewalk:left:width
width:shoulder
sidewalk:both:width
width:average

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Tobias Zwick

Absolutely high time! Thank you for bringing this up.

I was under the impression that the wiki already defined it like 2). 1) 
is not practical because parking lanes can be informal or can change 
quickly, 3) is also not practical because sidewalks + additional 
greenery/space between road and sidewalk can vary a lot.


I plan to soon implement a "What is the width of this road" quest in 
StreetComplete where the user can measure the width of the road using 
his or her smartphone (similar to the app Measure from Google [1]). The 
app will need to instruct the user very clearly what should be measured.


The instruction "curb to curb" is pretty clear. However, there is one 
more problem to solve, what about if there are no curbs? For example, 
track-like roads that just consist of either one strip of asphalt 
surface or are not paved at all? I see two possible definitions:


1. Width of the paved surface (if paved)
2. Usable width of the road

1 has the advantage that there is no room for interpretation, but falls 
short of what to do with unpaved roads. 2 leaves some room for 
interpretation but also covers cases where the usable width of the road 
is much different from the width of the paved part of the road.


Tobias

[1] https://play.google.com/store/apps/details?id=com.google.tango.measure

On 14.09.20 20:34, Supaplex wrote:


Hey all,

again and again there are discussions about which parts of a street 
(sidewalks and cycle paths, parking lanes, carriageway) should be 
considered when determining the width of a street. There does not seem 
to be a consensus and therefore information on street widths is 
difficult to interpret or is not even mapped. The following variants 
are common/are discussed:


1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with 
parked cars when they are on street

3) Width including sidewalks / roadside paths

I tend to option 2):
- The width can be clearly defined and measured
- The width of the actual carriageway can be determined by using 
"parking:lane" scheme correctly (or alternatively/supplementarily by 
specifying the width of parking lanes). "width:carriageway" (or 
"width:lanes", if there are marked lanes) also could be used to map 
this width directly.
- The width of roadside paths can optionally be specified with 
"sidewalk:width" etc.


Wouldn't it be time to document a recommendation in the Wiki to reduce 
further ambiguities? Which variant is the most recommendable? Anyway, 
the width of a street is a significant value to evaluate its 
suitability or safety for certain modes of transport or to determine 
the speed that can be expected there.


Thanks for your comments,
Alex


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


Re: [Tagging] "width" on streets: Time for a recommendation

2020-09-15 Thread Martin Koppenhoefer
Am Mo., 14. Sept. 2020 um 20:37 Uhr schrieb Supaplex :

> again and again there are discussions about which parts of a street
> (sidewalks and cycle paths, parking lanes, carriageway) should be
> considered when determining the width of a street. There does not seem to
> be a consensus and therefore information on street widths is difficult to
> interpret or is not even mapped.
>


indeed, mapping the width generally requires measuring the width, and it is
often not practical (unless you are willing to spend a lot of time or have
very good aerial imagery at hand).



> The following variants are common/are discussed:
>
> 1) Width of the actual carriageway, without parking lanes and sidewalks
> 2) Width between curbs / edges of the road without sidewalks, but with
> parked cars when they are on street
> 3) Width including sidewalks / roadside paths
>
> I tend to option 2):
> - The width can be clearly defined and measured
> - The width of the actual carriageway can be determined by using
> "parking:lane" scheme correctly (or alternatively/supplementarily by
> specifying the width of parking lanes). "width:carriageway" (or
> "width:lanes", if there are marked lanes) also could be used to map this
> width directly.
> - The width of roadside paths can optionally be specified with
> "sidewalk:width" etc.
>



I agree that 2 could be a reasonable definition for urban areas, what I can
see could be brought up against it:
the tags should generally apply to the mapped object. As we see a highway=*
to include the sidewalks, it would be somehow odd to not include them in
width. But I agree, through definition, we could define it to mean only the
road (including parking alongside), and we are already pursuing a similar
approach with regard to lanes (only car lanes, no bike lanes or sidewalks
counted).

when there aren't kerb stones, how would you suggest to proceed? (my
suggestion: measure from the middle of the wide lateral boundary lines if
there are, otherwise measure the paved width, on unpaved roads, measure the
extent of the maximum width that vehicles actually use, on a medium to
narrow part of the highway (i.e. do not add the smallest width to a long
stretch of highway if it only occurs for a short part, rather split the
highway in this case of tag the narrow exceptions explicitly while using a
medium value for longer stretches).

I would definitely not include widths of separated ways (e.g.
cycleway=track) in the highway width on the main way. For these, properties
like cycleway:width or footway:width could be added (or map the separately,
avoiding too many splits of the main highway)

Wouldn't it be time to document a recommendation in the Wiki to reduce
> further ambiguities?
>


yes

Cheers
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] "width" on streets: Time for a recommendation

2020-09-14 Thread Supaplex
Hey all,

again and again there are discussions about which parts of a street
(sidewalks and cycle paths, parking lanes, carriageway) should be
considered when determining the width of a street. There does not seem
to be a consensus and therefore information on street widths is
difficult to interpret or is not even mapped. The following variants are
common/are discussed:

1) Width of the actual carriageway, without parking lanes and sidewalks
2) Width between curbs / edges of the road without sidewalks, but with
parked cars when they are on street
3) Width including sidewalks / roadside paths

I tend to option 2):
- The width can be clearly defined and measured
- The width of the actual carriageway can be determined by using
"parking:lane" scheme correctly (or alternatively/supplementarily by
specifying the width of parking lanes). "width:carriageway" (or
"width:lanes", if there are marked lanes) also could be used to map this
width directly.
- The width of roadside paths can optionally be specified with
"sidewalk:width" etc.

Wouldn't it be time to document a recommendation in the Wiki to reduce
further ambiguities? Which variant is the most recommendable? Anyway,
the width of a street is a significant value to evaluate its suitability
or safety for certain modes of transport or to determine the speed that
can be expected there.

Thanks for your comments,
Alex

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