Talk:Key:dual carriageway

Not all motorways are dual carriageways

There can be short stretches of motorway that are two-way and single-carriageway. This can occur with on/off ramps which run together. --Csmale (talk) 12:46, 20 February 2020 (UTC)

Tag addresses the wrong issue

The real challenge is to work out which carriageways are associated with each other. In "free space" between two junctions, it is usually relatively easy to do this geometrically. But around complex junctions it is not so easy to do this with geometry alone, and this tag doesn't make it any easier. It would take a hierarchy of relations: one threading the route together in one direction, a second for the opposite direction, and then a relation to connect the other two together as "two halves of the same road". --Csmale (talk) 12:51, 20 February 2020 (UTC)

It is helpful to tag this property first, before making relations similar to Relation:street (there was Relation:dual_carriageway. To me, the "wrong issue" the tag is addressing is the fact that there are triple and quadruple carriageways (or even more). Something like divided_highway=* would be more general. I don't know any semantically similar UK terminology ("multiple carriageway"???). This depends on US meaning and usage on other terms viz "dual-divided" (quadruple). -- Kovposch (talk) 13:19, 20 February 2020 (UTC)

The name of the tag is not the core of my point. Its intention is to indicate a topology, that a single "road" is composed of two (=dual) "linestrings" in opposing direction. Simply indicating that a linestring participates in some "multi-carriageway road" is not enough to recreate the topology of the entire "multi-carriageway road". You are right that the number of carriageways can be any number > 1; there are many cases of a motorway having "through carriageways" and "distributor carriageways" in the same direction, all being parts of the same "road". --Csmale (talk) 14:28, 20 February 2020 (UTC)

How about something direct like carriageways=2 (for when the road hasn't been fully mapped separately) and carriageway:count=2? Similar to tracks=* and passenger_lines=* respectively. There's already carriageway_ref=*. There are quite many https://taginfo.openstreetmap.org/keys/carriageway uses. -- Kovposch (talk) 11:31, 21 February 2020 (UTC)

My understanding is that "divided highway" is American English for "dual carriageway" (British English). I am not aware if British English speakers would use this term for a highway that was divided by 2 or 3 "central reservations" or short concrete walls so that there were 3 or 4 carriageways. So far this tag has mostly been used for highways with 2 carriageways, since that is by far the most common number (after 1). If "dual carriageway" can also be used to describe divided highways with 3 or 4 carriageways, then I suppose this tag can also be used for that situation. --Jeisenbe (talk) 05:37, 21 February 2020 (UTC)

While there is a tag type=dual_carriageway which is used mainly on relations, in addition to type=street, I am not aware of a need for a relation. What would be the use case for that relation type? --Jeisenbe (talk) 05:37, 21 February 2020 (UTC)

Let's turn that around; what semantic value does the presence of this tag add to a way, that cannot be derived from other information (such as oneway=yes and the geometric proximity of a similar road in the other direction)? When is knowing that a road is part of a dual carriageway important? For whom is it useful? The relation could be useful by indicating which oneway ways could be reduced to a single way to simplify the road network for routing purposes or rendering at low zooms. Not all adjacent pairs of ways in opposing directions are dual carriageways, and using a relation would allow the relationship to be expressed explicitly. Now remind me again, what problem does "dual_carriageway=yes" address? --Csmale (talk) 17:13, 21 February 2020 (UTC)

For comparison, I would like to add that there are route=tracks and route=railway in use on railways (subject to ongoing debate). I mentioned relation:street only because it is used on road, which it is actually not exactly the same (describing all objects, buildings or addresses assigned to a street). If relation:street is used, then a new relation for carriageways and pathways of a "road" may not be needed. -- Kovposch (talk) 10:13, 22 February 2020 (UTC)

" Let's turn that around; what semantic value does the presence of this tag add to a way, that cannot be derived from other information" - fact that given oneway road is part of dual carriageway. I found no way to get it automatically from other data (that is why I tagged it manually) and that is why AB Street is using this tag Mateusz Konieczny (talk) 11:07, 5 May 2021 (UTC)

redirect

@Mentor: Can you explain me why you are redirecting this page? What is the benefit of that? Mateusz Konieczny (talk) 04:58, 18 July 2022 (UTC)

Try to imagine that you are using the wiki and want the information on the page that it is redirected to. Mentor (talk) 22:53, 28 July 2022 (UTC)

In such case the worst possible case is that one more click is needed Mateusz Konieczny (talk) 23:25, 28 July 2022 (UTC)

So? Mentor (talk) 00:00, 29 July 2022 (UTC)

Negative effects of redirecting (loss of taginfo description for example) are greater Mateusz Konieczny (talk) 06:01, 29 July 2022 (UTC)

How to deal with dual carriageways across large intersections?

Take the following example: A long boulevard with a physical separator, that is a perfect candidate to add dual_carriageway=yes. The ways have been split in multiple parts because of bus relations. The question is: should the blue ways also get this tag (which will defeat the idea of having a physical separator) or not (which will defeat the idea to use the tag to indicate one-way roads running in parallel)? Bxl-forever (talk) 22:18, 20 December 2023 (UTC)

I use junction=intersection without the physical carriageway=* that I prefer. I'm of the opinion dual_carriageway=* should be legal, in Talk:Tag:dual_carriageway=yes and as earlier section .
—— Kovposch (talk) 05:56, 21 December 2023 (UTC)