Width ambiguities on highway

[flohoff]

Hi,
after 10 years i came back to systematically update/set widths on all line objects.

So i again had a look at the whole definition of width on streets and it seems someone at least tried to pull together what we have. Still - there seems to be a lot of ambiguities in with definition for highways.

I am referring to:

https://wiki.openstreetmap.org/wiki/Key:width#Width_of_streets

I was under the impression that width defines the usable width of a street for driving. So that all stuff like shoulder, verges, cycle lanes, sidewalks come extra.

To my surprise this was not the case (anymore?). It seems that width defines basically anything flat from side to side. Whether it includes cycle lanes, shoulders, markings on the sides whatever.

I had also used width=* in OSRM profiles to make assumptions on road usability but this now comes up as orders of magnitude more complex. As now to get the real usable driving width one would need to use width (or width:carriageway?) and substract the widths of the shoulders, outer lane/road markings (if exist) for example.

I would have understood the width setting if it would include the complete width of the object represented by this linestring. E.g. including kerb, sidewalk, cycleways etc.

Now it feels really halve-baked as some elements are include, some not, and to get the width of the driveable surface informations are missing line outer road markings etc.

Am i right in my observation? Are there any further documentation on the progress of definition of width? Is anyone working on a better concept?

Flo

[Supaplex030]

Your interpretation is correct: width on a road now refers quite clearly to the width of the carriageway (i.e. the width from kerb to kerb or edge to edge). If there are cycle lanes, parking lanes etc. on the carriageway, they are included in the width value.

There are various options to derive the effective usable width for traffic:

1. width:lanes[:forward/backward] can be used to specify the width of lanes,
2. using the difference between width and the width of its individual parts (e.g. cycleway:*:width, parking:*:width etc., or default values if not specified),
3. two or three mappers (I am one of them) use width:effective to explicitly specify the usable width for flowing traffic. Maybe it’s worth to better document/propose this tagging. (Just noticed that there is a bit strange wiki page for width:effective since some month; definitely needs more clarification about it’s meaning.)

After years of complete disagreement (some mappers used width to mean the usable width for cars, some the width of the carriageway, some even included sidewalks, etc.), I’m quite happy that there is now more clarification on this. In practice, this came with StreetComplete, which “created facts” after some community discussions. But maybe there is still a lack of clear documentation and editor support.

(width:carriageway is btw. obsolete, since it now is the same as width.)

[OSM_RogerWilco]

@Supaplex030

width on a road now refers quite clearly to the width of the carriageway (i.e. the width from kerb to kerb or edge to edge).

Is the street gutter also included in the width of the carriageway?

[flohoff]

@Supaplex030

After years of complete disagreement (some mappers used width to mean the usable width for cars, some the width of the carriageway, some even included sidewalks, etc.), I’m quite happy that there is now more clarification on this. In practice, this came with StreetComplete, which “created facts” after some community discussions. But maybe there is still a lack of clear documentation and editor support.

The point i was seeing was a different one. I see the disagreement but i also see a brokenness concerning the OSM data model and the current thin definition of width.

In our mixed-model we have no physical dimension for ways. So declaring a “width” on a way should describe the full physical dimension of all objects in the real world represented by this way/linestring in OSM.

Right now the linestring/way in OSM represents the whole of the street including kerb, verge, shoulder, cycleways, lanes etc - but width only includes lanes + shoulder. This is so mindboggling inconsistent IMO.

For me it would be the easiest if width would only include the usable road surface but i wouldnt propose that as it is insonsistent concerning the OSM data model aswell.

I’d be happy to simply replace width by width:lanes but the definition definition in the mentioned Wiki article is pretty thin as it could also mean width:lanes only defined one lanes width, or should contain “|” like in turn:lanes.

Flo

[dieterdreist]

|
|

• | - |

The point i was seeing was a different one. I see the disagreement but i also see a brokenness concerning the OSM data model and the current thin definition of width.

In our mixed-model we have no physical dimension for ways. So declaring a “width” on a way should describe the full physical dimension of all objects in the real world represented by this way/linestring in OSM.

+1, it seems logical that “width” (or any other property) is refering to the object that is represented, but this means that in our datamodel, the same road must have different widths, depending on the context, e.g. whether there is an explicitly mapped cycleway or cycleway=track, or whether the sidewalk is mapped explicitly or implicitly included in the highway, and when you map a sidewalk as its own way, you would have to adjust the width of the highway nearby. Is this desirable? IMHO not.

Right now the linestring/way in OSM represents the whole of the street including kerb, verge, shoulder, cycleways, lanes etc - but width only includes lanes + shoulder. This is so mindboggling inconsistent IMO.

it is ultimately a question of definition. We also map building:levels and do not include underground levels or roof levels for example. You can have a building with building:levels=0 when it has only 1 roof level and a few underground levels

Or more mindboggling, count the number of building levels that do not exist and add them (building:min_level).

For me it would be the easiest if width would only include the usable road surface but i wouldnt propose that as it is insonsistent concerning the OSM data model aswell.

what is “usable”, do you refer to drivable, with a car?

Another issue I have with road widths: they rarely change abrupt, usually there is some kind of curve where one width converges to another, how can we map the kind of curve/transition (linear, as a step, curved, …), or are we to add an infinite number of steps between the two widths?

[Supaplex030]

@flohoff

Right now the linestring/way in OSM represents the whole of the street including kerb, verge, shoulder, cycleways, lanes etc - but width only includes lanes + shoulder. This is so mindboggling inconsistent IMO.

IMHO this is quite consistent, because as for other ways (which are not designed for public motorized traffic), the width refers to the total usable width for traffic (usually the (un-)paved surface), regardless of the mode of transport or whether stationary or moving traffic. As the verge is not intended for traffic, it is not included. You can argue about an (unpaved) shoulder, but I think we still lack a consensus on the topic of paved/unpaved shoulders anyway.

@OSM_RogerWilco

Is the street gutter also included in the width of the carriageway?

IMHO this depends on the kind of road/existence of kerbs. If the gutter is on the road side of kerbs (like the first one below), I would consider them part of the carriageway, if they are at the road edge without kerbs (like the second one), they might not considered as part of the carriageway.

@dieterdreist

usually there is some kind of curve where one width converges to another, how can we map the kind of curve/transition (linear, as a step, curved, …), or are we to add an infinite number of steps between the two widths?

There are the :start and :end suffixes in use (e.g. width:start=8, width:end=12), even if they are rarely used in context of width so far. This allows at least a linear approximation, which should be sufficient for most use cases/applications.

[dieterdreist]

@Supaplex030

There are the :start and :end suffixes in use (e.g. width:start=8, width:end=12), even if they are rarely used in context of width so far. This allows at least a linear approximation, which should be sufficient for most use cases/applications.

This is indeed a start, although from looking around, it seems the width is often changing in a curve and not a linear transition (e.g. 2 in this picture).

I also wonder how to treat roads that merge, e.g. 1 in the picture. Do you decrease the width, or will the roads overlap?

[Supaplex030]

@dieterdreist

I also wonder how to treat roads that merge, e.g. 1 in the picture. Do you decrease the width, or will the roads overlap?

They have to overlap, since the width value on a linear feature is just a generalization to know how wide the road/lanes are in every direction of travel on your way from one intersection node to another intersection node. If somebody needs it more exactly, they need to use area features (area:highway polygons).

[flohoff]

@Supaplex030

IMHO this is quite consistent, because as for other ways (which are not designed for public motorized traffic), the width refers to the total usable width for traffic (usually the (un-)paved surface), regardless of the mode of transport or whether stationary or moving traffic. As the verge is not intended for traffic, it is not included. You can argue about an (unpaved) shoulder, but I think we still lack a consensus on the topic of paved/unpaved shoulders anyway.

Its not - I am not talking about mode of transportation or semantic meaning of this linestring within OSM.

I am talking between the link of reality to an osm way.

So if the way e.g. linestring is using cycleway:left=track, width does not include it. If its cycleway:left=lane it IS included. So the width is basically useless from a standpoint of usability in a data consumer. The complexity to get to something like the total width, or only the width for a certain mode of transportation is basically impossible without using another truckload of other tags.

Flo

[skyper]

Usability depends on the data consumer. If I am interested in the total width between curbs to render or for exceptionally wide transport it is useful. If I am interested in the width for common vehicles, I have to take a look at width:lanes in case of more than one lane.

@flohoff

I’d be happy to simply replace width by width:lanes but the definition definition in the mentioned Wiki article is pretty thin as it could also mean width:lanes only defined one lanes width, or should contain “|” like in turn:lanes.

Yes, width:lanes should be used like turn:lanes with numbers for each lane and “|” as value separator. This would include cycle lanes.

[osmuser63783]

What I find hard is when to include space reserved for parking in the width. If I understand the Wiki correctly, this should be based on whether it’s a “parking lane” (include in width) or “streetside parking” (exclude).

The distinction can be hard to draw. But maybe it doesn’t matter too much for data consumers as long as you tag parking when you tag width?