Talk:Tag:man made=bridge

New proposal for multi-level bridges and objects on bridges

I think this can be done much easier, without the relation and quite robust: Proposed features/Simplify man made=bridge mapping RicoZ (talk) 14:56, 20 June 2015 (UTC)

Covered=* under man_made bridge?

Discussion over at Talk:Key:covered#What_to_do_with_building.3Droof.3F.--Jojo4u (talk) 14:28, 4 October 2015 (UTC)

"Outline"=supported structure

In Stuttgart there is a unusual foot/bicycle bridge with a wide steel net supporting the path. The type is called "Seilnetzbrücke" by Structurae with only 3 worldwide and no one of the same design (OSM, Structurae). The steel net is very wide and should not be tagged man_made=bridge in my opinion. man_made=bridge should outline the the supported structure of the bridge.

Example: The Millennium Bridge in London does not include the supporting structure (OSM, Wikipedia).--Jojo4u (talk) 11:37, 25 October 2015 (UTC)

Would man_made=canopy be a good fit for this ? Somewhat described here building=roof. RicoZ (talk) 09:36, 9 June 2016 (UTC)

Ways below bridges as tunnels

Should ways that run below a man_made=bridge area be applied the tunnel=yes key? --Absay (talk) 06:19, 25 February 2017 (UTC)

No, use either tunnel or bridge. --geozeisig (talk) 06:34, 25 February 2017 (UTC)

Why not, when layer is correctly tagged

Many people like to use tunnel and bridge together or asked for covered. Why? They want the carto give transparant and dashed lines under the man_made=bridge to the way.
I read: Do not connect the ways running under the bridge to the outline. ([[1]])

The solution could be, to do so.
When man-made=bridge is tagged correctly, layer=1 and the underneath way is attached to the man_made=bridge, outline, this way does not have a layer, the render could calculate the length from the connecting points and make the underneath way dashed and transparent. I see this as a solution for a problem, that keeps coming up every time again.
There is a relation between the underneath way and the bridge.

Routing: with a connecting point to the outline, the underneath way, could give a hint like 500 meter go under the bridge.
Maxheight: could be set to the correct point. On node not a layer tag or lower then the bridge layer tag.

When I think about it this is also for the waterway line possible.
What are the disadvantage for connecting?

For me, this visualisation problem must be solved, but how? Can we do it this way?--AllroadsNL (talk) 07:54, 10 October 2018 (UTC)

You could indeed use "covered" for the way bellow a bridge. However, the rendering problem you mention is just a rendering problem and a renderer can fix it without changing the way it is mapped, in fact I suspect some renderers and other tools might break if we change it that way. As man_made=bridge is a bit new it may take renderers some time to figure out the optimal rendering, did you look at the bug trackers of the various renderers?

The answer to the philosophical question - why the ways are not connected in OSM - is because OSM considers bridges and the objects bellow them completely independent and the connection would break that assumption. This is often not a good model of reality but mostly works. RicoZ (talk) 21:33, 18 October 2018 (UTC)

man_made=bridge on small bridges

man_made=bridge is also useful with small bridges!
It give visual, the width of the bridge.
You could even calculate the width of the bridge.
A advise not to do so, is not correct!
People should decide by themselves, what they tag.
In the Netherlands we could import all the bridges from Government Data.
This gives a better topographic effect, then the route line sideline, it depends where you use it for.
--AllroadsNL (talk) 18:35, 30 November 2018 (UTC)

I suggest using the Key:width tag and a renderer which will render the bridge and adjoining roads/paths according to the given value instead. --Hjart (talk) 19:09, 30 November 2018 (UTC)

"Please note that this construction for simple bridges (mapped by a single way only) in most cases is overkill." This advice is wrong, it not a overkill. I would suggest delete it. People should make their own decision to do so. If people do not want it, do not render it.--AllroadsNL (talk) 19:31, 30 November 2018 (UTC)

The Key:bridge tag with most simple bridges & most renderers gives all the visuals you really need. I just think some mappers are really taking the man_made=bridge construction way too far. I think it should be either one or the other. --Hjart (talk) 20:06, 30 November 2018 (UTC)

"it should be either one or the other" why? Mateusz Konieczny (talk) 20:43, 30 November 2018 (UTC)

"The intended use of this tag is with complex bridges" was claimed in one of edit description. I want to say that restricting it to solely large bridges was not my intention (I initiated voting for proposal for this feature and was first to add rendering of this feature to a popular map style). If you are aware of consensus that really small bridges must not be tagged this way please link me to a discussion on this Wiki or to tagging mailing list Mateusz Konieczny (talk) 20:48, 30 November 2018 (UTC)

See https://wiki.openstreetmap.org/wiki/Proposed_features/man_made%3Dbridge#One_way.2C_one_level - proposal explicitly described this case. Marking area of smaller bridges is described as "It is possible but usually not necessary to specify the outline in this case.". And if anything changed then it went toward mapping also smaller and smaller bridges with man_made=bridge , not forbidding it Mateusz Konieczny (talk) 20:52, 30 November 2018 (UTC)

Please note that my sentence does not explicitly forbid anything, but merely notices that it (in maybe somewhat stronger language) is not necessary. I have until quite recently not seen it used with smaller bridges in the areas I watch (Denmark) and so far I'm definitely not a fan of it being used everywhere. --Hjart (talk) 21:19, 30 November 2018 (UTC)

bridge=* : can or should?

The tagging section is currently inconsistent. One sentence says "The key bridge=* can be used to indicate the type of the bridge.". Another sentence says that "Ways across the bridge should be tagged with the same values of layer=* and bridge=* as the outline.". This is contradictory since almost all bridge ways do have the bridge=* tag set (usually to yes). I'd like to resolve this. My suggestion is to delete the can option and adopt the style suggested in the should sentence. Any opinions on this? Martianfreeloader (talk) 19:48, 24 March 2021 (UTC)

The tag bridge=yes says something is on a bridge, so I would not set it for an object tagged as man_made=bridge but the layer of the bridge and the way on the bridge should be set explicitly and be the same. --Dieterdreist (talk) 22:42, 24 March 2021 (UTC)

Thanks for the explanation Dieterdreist and thanks for implementing this clarification in the article, Mateusz Konieczny. I've somewhat re-ordered the sentences to what seems more logical to me. Martianfreeloader (talk) 22:56, 24 March 2021 (UTC)

Extent of bridge

Where should a bridge begin and end? Sometimes I see bridge=yes ways extending to the abutment/pavement notch/expansion joint, where the bridge deck begins and the space opens up below, while other times I see these ways include the approach slab and embankment too. [2][3] I've been excluding the approach slab when it's possible to spot the expansion joint in aerial imagery or the abutment in street-level imagery. This is also how my state's highway department officially measures the length of a bridge. However, this article is silent on the matter, so I don't know if there are any arguments in favor of the other style. – Minh Nguyễn ^💬 09:49, 11 July 2021 (UTC)

I think your style of mapping makes a lot of sense. If no one disagrees, it would be useful to the community if you could document it as a set of unambiguous instructions in a new "How to map" section right after the intro. Martianfreeloader (talk) 12:44, 11 July 2021 (UTC)

It looks this is implied in the example photos. ---- Kovposch (talk) 04:44, 12 July 2021 (UTC)

@Martianfreeloader and Kovposch: Thanks, I added some photo examples. Hopefully the guidance I added isn't too specific to the U.S. or to road overpasses. – Minh Nguyễn ^💬 20:02, 12 July 2021 (UTC)

@Minh Nguyen: Very nicely done! This is crystal clear and fun to read. Great job!

I believe man_made=bridge should include the whole bridge, including the "anchor" part of a bridge, i.e. the pylons should be included, towers should be included, etc. For bridge=yes on roads or railways, it makes sense to limit it like you described: "each end of the bridge should correspond to the point where the bridge's abutment ends and an opening begins below the bridge.", but for man_made=bridge, the whole "bridge" should be tagged, including structural parts beyond the opening. —Dieterdreist (talk) 08:26, 13 July 2021 (UTC)

Not saying I necessarily disagree, but the example screenshots will need to be changed if there has been a consensus somewhere. I can't find anything on Proposed features/man made=bridge for the definition yet. ---- Kovposch (talk) 10:13, 13 July 2021 (UTC)

"I can't find anything on Proposed features/man made=bridge for the definition yet" - sorry. I have not really considered it, and at that time my primary motivation was to stop using building=* to be used for bridge outlines. What at that time was the most popular form of tagging for renderer among experienced mappers, in real danger of becoming an accepted practice. Mateusz Konieczny (talk) 06:56, 14 July 2021 (UTC)

For reference, here is a picture of an example bridge where the answer to what is the bridge? (i.e. what I believe man_made=bridge is about) would likely include the pylons and also extend behind at least to the anchor blocks.

--Dieterdreist (talk) 12:36, 14 July 2021 (UTC)

I guess it boils down to answering the question what exactly we want to describe by man_made=bridge:

* A certain type of contiguous artificial structure, called "bridge"? This would include pillars, achors, etc. The focus of this definition would be on architecture.

* A module of that structure that is mechanically largely independent of its surrounding? For this, Minh Nguyen's expansion joint definition would be most suitable. The focus of this definition would be on physical behaviour, including information on how prone certain areas are to e. g. premature freezing (compared to the surrounding).

* The part of the structure that has an opening underneath it? This would be Minh Nguyen's "where the bridge deck begins and the space opens up below" definition. The focus of this definition would be on topology (where are underpasses possible, where is shelter?). Martianfreeloader (talk) 15:09, 13 July 2021 (UTC)

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘

First of all, I appreciate Mateusz Konieczny bringing this tag to a successful vote. One of my motivations for mapping bridge areas is to discourage abuse of tunnel=yes or covered=yes on the underpass. Another is to collect the roadway and separately mapped sidewalks into something visually unified. (A novice mapper once went around deleting the sidewalk bridges out of disgust at their separate rendering.) These considerations primarily relate to road overpasses, most of which lack piers, anchors, and ornamentation that would affect the bridge area.

I do like the idea of including everything structurally related to the bridge, so that man_made=bridge can be a straightforward analogue to building mapping. However, anchors and guardrails would contort some bridges' shapes so as to be unrecognizable in a 2D renderer (see version 1 of this bridge). To determine the extent of a partially buried abutment, I would need to field-survey many of the bridges I've mapped, even though some are off-limits to pedestrians, or even try to find architectural drawings. Maybe it would be better to map things like that as separate features, joined by a bridge relation, similar to how portes cochères are mapped as separate building=roof areas because they aren't part of the building's footprint.

 – Minh Nguyễn ^💬 01:42, 18 December 2021 (UTC)

I also map bridges as objects to discourage tunnel on the lower way, but believe that covered=yes is ok, although not needed it seems like a valid description. More advantages of explicit bridges are having an object for the bridge where things like name, architect, start_date can be put, and which makes it possible to see when several carriageways run over the same bridge.—Dieterdreist (talk) 10:00, 18 December 2021 (UTC)

Bridge expansion joints

Perhaps mention how to map bridge expansion joints, as seen in air photos. Jidanni (talk) 20:22, 6 November 2022 (UTC)

There is none. My Idea User:Kovposch/Proposed_features/More_bridge_structural_details#Expansion_joints (maybe not man_made=*, but as mentioned it may have use elsewhere) that I have been doing. -- Kovposch (talk) 04:21, 7 November 2022 (UTC)