Talk:Key:bridge

Canal bridges

I notice that bridge symbols don't appear for canals. There is a section of the Forth and Clyde Canal where it goes over a road. This is [ here]. Bruce89 21:16, 11th February 2007 (UTC)

Naming

An issue with bridges is what the name=* tag should be, should it be the name of the road that is going over, or should it be the name of the bridge? The second option seems best to me, but if a bridge doesn't have a name, then should the bridge's name=* tag have the name of the road going over it? What about ref=* as well, should there not be a ref=* value for bridges, or should they be the same for the road going over it? Bruce89 22:32, 18th February 2007 (UTC)

I think we can use name=* for the name of the road over it and bridge_name=* (or something like this) for the name of the bridge.

So when we see name=* we know that it is for the road name. But in Bruce89 idea, when we see a name=* over a bridge we can not understand if it is the name of the bridge or it is the name of the road over it (and the bridge doesn't have a name!

--Messi 11:52, 9th April 2007 (BST)

Fair enough, the name_bridge=* idea seems reasonable, I would extend it to bridge_ref=* too. Just to clarify, my comments above were questions, not statements.-- Bruce89 12:30, 9th April 2007 (BST)

I agree with the above, name=* should be for a named road above the bridge, and bridge_name=* for the name of the bridge itself. --Cohort 04:34, 24th May 2007 (BST)

Note: There is now a much clearer description in the article about the various ways to name a bridge in different circumstances. PeterIto 03:31, 6 January 2012 (UTC)

Currently (2020/3) we read one option is

Use the street/road name for name=* field and put the name of the bridge in bridge:name=*. This approach has the disadvantage that it will not get rendered.

Well, yes, we must do Tagging for the renderer, else it would be crazy for the say well known Nibbles Memorial Bridge to just be labeled Turd St. So we will instead choose

Use name=* tag itself to hold the name of the bridge rather than the name of the road itself. This approach has the advantage that it will get rendered.

However, we cannot tell a lie, and must admit that Nibbles Memorial Bridge is yes officially part of Turd St. So maybe we should add a tag highway:name="Turd St." in addition to name="Nibbles Memorial Bridge"? Jidanni (talk) 02:04, 23 March 2020 (UTC)

@Jidanni, the name of a bridge nowadays gets on the bridge outline, tagged as man_made=bridge, which to your enjoyment is rendered in the Carto style. Thus having the road being tagged bridge:name=* is sufficient for all the other data consumers beyond Carto. --Polarbear w (talk) 07:58, 23 March 2020 (UTC)

@Polarbear, the iD editor is making bridge=yes highway=residential layer=1, not man_made=bridge. Should a bug be filed against it? Jidanni (talk) 06:50, 25 March 2020 (UTC)

Not sure what you mean with "is making". The bridge outline is a separate object from the road over the bridge. You draw the outline and tag it man_made=bridge. AFAIK you can enter any tag you like in iD.--Polarbear w (talk) 20:05, 25 March 2020 (UTC)

@Polarbear https://github.com/openstreetmap/iD/issues/7469 Jidanni (talk) 06:35, 27 March 2020 (UTC)

Splitting up roads

So do I understand correctly that a road is always split in three parts when there is a bridge in it? For instance, I've got a nice long motorway and a tiny service road is going underneath it, making it a bridge there (this is because the motorway is elevated, so I can't make the service road a tunnel, unfortunately). Do I have to split the motorway in three parts just because of this service road? Is there no way to leave it intact? Mtcv 17:22, 3rd July 2007 (BST)

The method you describe (splitting the way) seems to be what is (currently) suggested in this article. However, Editing Standards and Conventions#Drawing Guidelines says to simply make a way for the segments that constitute the bridge (and tag them accordingly), which implies that you do not have to split the way for the road, railroad, or whatever feature that is carried by the bridge. The latter method is a lot more logical to me, as it more accurately models the real world. For example, a motorway that is carried on a bridge does not logically "split" at the bridge abutments — it is a contiguous entity over the bridge, so why should its way be split? Also, the latter method works for the case where there are multiple entities carried by the bridge (say, a road and a footpath). SixSix 03:46, 1st August 2007 (BST)

In fact a bridge is always splitted in three parts : with dilatation joints... --PhilippeP 08:57, 1st August 2007 (BST)

OK, true, there is a physical break at the bridge abutments, but, I said logically there is no break: it is the same street, the same railroad, etc. on the bridge that it is on either side of the bridge. I suppose what is confusing me is how ways are being used to mix logical and physical features. SixSix 18:05, 3rd August 2007 (BST)

The convention is indeed to split the way into three parts. Making a second way using the same segments is not standard, so far as I understand it. There's really no problem with splitting a way up, it's a matter for software to interpret the data and realise that it's all still part of one road / path / canal / etc. TomChance 10:26, 1st August 2007 (BST)

OK, I can accept that, but if this, indeed, is the convention, it needs to be made more clear in the editing standard for bridges article. I reread that article and think that it could be interpreted either way (hence the fact that I thought it suggested adding a new way at the bridge). Maybe I'll take a stab at editing it. SixSix 18:05, 3rd August 2007 (BST)

That's an old discussion. It now is very clear on Editing Standards and Conventions#Bridges, and yes it very much is the convention that you split the way at the beginning and end of a bridge. This presents some problems for data users (e.g. how download and manipulate a zoomed-out motorway network) but as far as mapping is concerned... that's what we do -- Harry Wood 13:30, 8 February 2012 (UTC)

Bridge shared by multiple routes

How should be tagged bridge used by more than one route? For example railway and road/footway. Using bridge=yes for both railway and road renders two bridges which is wrong because there is only one bridge and it also usually looks ugly because railway and road are too close. --Jttt 08:02, 7th May 2008 (UTC)

Proposal related to this problem - Relations/Proposed/Bridges_and_Tunnels --Jttt 14:34, 24th May 2008 (UTC)

How does one best model two ways (a motorway) going above another two ways (another motorway)? Must each parallel way be a bridge on its own, or is it possible to make a common bridge? --LA2 08:34, 26th March 2007 (BST)

You can use Relations/Proposed/Bridges_and_Tunnels for this or make each way a bridge of its own. The latter does not provide the information that they share the same bridge, of course. --Tordanik 15:44, 8 August 2009 (UTC)

Layer

Why isn't bridge rendered above the other way if layer=1 is not set?

A bridge is per definition over something else. I don't think the additional layer=1 should be necessary but is implied by "bridge". Same as highway=residential implies foot=yes, but highway=motorway does not. --Itschytoo 19:37, 27th June 2008 (UTC)

bridge=yes tells us: one thing (street, river) is upper than something

tunnel=yes tells us: one thing (street, river) is under than something

Therefore we don't use a "layer"-attribute.

In layer we can read the OSM-Mantra:

Do not use this tag to correct some render behaviour and let the output look better.

Bridge with layer=+1 is like animal=white horse+color=white...

--Markus 11:32, 3rd September 2008 (UTC)

Discussion at Talk:Key:layer#Layer. --Eimai 12:37, 3rd September 2008 (UTC)

How great, basically nothing is decided. Taginfo says 71% of the bridges contain layer=* tag so 30% is untagged, which means about 400000 untagged bridges around. The linked discussion leaded nowhere, there was a rejected proposal about default, so… This is pretty bad. Either we kindly ask everyone to use layer=1 instead of relying on the defaults or we document that we assume that bridge=* implies layer=1 unless stated otherwise. Not documenting anything about it is unacceptable: mappers have no way of knowing. I was about to open a bug at JOSM because verification "sometimes" complain about crossing ways but maybe they just don't know either.

As far as practice concerned I see mappers imply default layer=1 when mapping (at least 30% of the edits related), so there is a strong point to use this default.

Some people reinterpreted the whole problem as "layer tag is useless" and they reached the "conclusion" that it isn't. Obvious. But that wasn't the question at all, it's about the defaults of layer when using bridge tag... *sigh* --grin ✎ 10:09, 6 October 2012 (BST)

I'm not sure what's unclear about it. Current status: There is no special default layer for bridges. Some people think it would be good to change this, but it hasn't been changed, so omitting the layer tag for bridges remains incorrect. --Tordanik 12:34, 6 October 2012 (BST)

So, 7 years later: layers are implied, but also required. Why? —S. Jevtić ^talk·OSM 21:18, 14 August 2019 (UTC)

Layer is implied because nobody wants to break existing objects where mappers forgot layers, however this is not like a default layer which would break other bridges in other situations. It is highly encouraged to use an explicit layer for clarity and to simplify error checking. BTW software does ignore even an explicit layer if it thinks it is wrong in a special situation.. pretty complex situation. RicoZ (talk) 17:12, 15 August 2019 (UTC)

Tagging bridge numbers

In NRW/Germany it seems to be the situation, that every bridge has a number. Black numerical digits on a white ground sign in two rows. The upper one with four numerical digits, the lower one with three numerical digits. I would like to record it with ref=xxxx xxx. --HoH 13:43, 16th July 2008 (UTC)

Similarly for road bridges in the Czech and Slovak republics. Five digits for the road number followe by a hyphen and a running number for the bridge. Ipofanes 04:16, 13th October 2008 (UTC)

If we record the government's bridge numbers with the ref= tag, they'll end up being rendered as the number of the highway. Therefore a special tag needs to be invented for bridge reference numbers themselves. Jidanni (talk) 03:29, 28 November 2022 (UTC)

One way bridges

OK, I've searched for this and no joy. There are lots of one way bridges I need to map in New Zealand and I'm pretty sure I've seen them in other countries. These bridges require traffic from one direction to wait for the other, before entering and crossing the bridge. The "preferred" direction changes from one bridge to another. In some cases, I noted the preferred direction and would like to be able to expose this to the map.

I have used oneway=shared and direction=1|-1. "Shared" indicates that traffic can flow in two directions , but there's only one lane (maybe I should just use lanes=1??). Maybe "shared" isn't quite the right term. The direction property is something I've seen applied elsewhere: with (1) or against (-1) the direction of the way.

Thoughts about this? Did I miss something?

Hubne 12:40, 13th August 2008 (UTC)

Is the word you're looking for "priority"? I suppose this could be coded as oneway=priority? Or perhaps as something like priority-direction=yes. The direction in this case should be the direction which has priority.

I guess this has implications if you're using the map for automatic navigation. Maybe there is somewhere that could be discussed (I'm new here). - Notmyopinion 19:50, 16th August 2008 (UTC)

Sounds the same as speed restrictions you get in the UK where the road has been narrowed (for only a metre of so) and oneway has priority. I think oneway=priority would be good if a route planner wanted to implement it. Doesn't really need to be displayed on most maps. - LastGrape 09:17, 19th August 2008 (UTC)

I suggest to add (only) the tag priority=forward (after testing, and reversing if necessary, the "way" direction by temporary adding a oneway=yes to should the way direction arrows). If you wish the entire road to continue in the same basic direction, and not have reversed segments here and there for different bridge priority directions, then of course you can use priority=backward in those cases, instead of reversing the direction of the way (road segment). Whatever you do, to apply varying tags to different segments, you cannot avoid to split the way each time before/after, but of course you already know that only too well... Regarding the actual count of lanes, I do not see any real solution, but that is not a major hurdle: just mapping the priority direction is already very good useful information, no matter what the physical constraints may be in-situ to warrant such prioritisation - if rendered then it is already enough of a warning to beware of the exact sign-posting when the road-user arrives at that point. It may also be useful for routing, so that when multiple paths are available, then the router should prefer the path with the lowest number of counter-priorities. You could maybe tag the bridge with lanes=forward + lanes=backward, but I strongly advise against this as it will likely be treated as a hard-and-fast oneway=yes, which is not at all the same. Please refer to the page on priority=* by Pink Duck.

--Neil Dewhurst, Lyon France 09:05, 12 October 2012 (BST)

oneway=reversible Mateusz Konieczny (talk) 12:22, 15 January 2021 (UTC)

maxheight vs height

There seems to be varying views whether bridges should be given additional tag maxheight or height. I believe both camps are trying to achieve same goal: to tell the height of vehicles that can safely drive under a bridge. This maximum height is often seen on warning sign right above the road.

In page [ revision history] Tordanik tells maxheight should only be given to roads below bridges (bridges given tag "height" instead). Is this really done in practice? Should one also split the roads below bridges to tell this? Feels quite complicated to me and I can't find a recommendation for or against in wiki.

I've always thought maxheight should be a feature of bridges (not roads) and it's used this way according to tagwatch. Lazzko 13:57, 22nd October 2008 (UTC)

Well, I'll try to explain how I see this. maxheight is an access tag. Key:access states the purpose of access tags as “For describing the legal accessibility of an element” – which likely refers to the tag being relevant for the element it is put onto. This is where it logically belongs to: A maxweight tag tells me the maximum weight of a vehicle on the way. Maxspeed tells me the maximum speed of a vehicle on the way. And so on. So why should maxheight refer to the maximum height of a vehicle passing under the way?

Putting a maxheight on the bridge rather than the way under it makes using the information more difficult for software (as it requires intersection tests to find out about the vehicles that can use a road then), and it clearly does not fit in with the concept of an access tag (as described above). Splitting ways, on the other hand, is common practice where other information (speeds, names, …) changes, so I cannot see where it is a complicated concept, especially as "height" seems to be an appropriate key name for describing the height of a bridge.

--Tordanik 22:11, 23rd October 2008 (UTC)

Looks well thought and reasonable approach to me. I just think we should document this better (which tags goes where and how to split the ways below and above). There's some more questions, though.

1) Is "maxheight" of a road (below) to be considered the same as "height" of a bridge (above)? I think maximum height given in warning signs are somewhat less than the actual height of bridges (safety margin). Should we just accept "maxheight" to be close enough or add some 0.5m to get bit closer? Please correct if my assumptions are plain wrong (haven't done truck driving nor bridge designing).

2) Should "height" of bridges reflect to the ground level or to the upper most road below bridges? Naturally, this distinction is probably only needed in case of complex bridges (two or more bridges crossing each other). Lazzko 10:10, 25th October 2008 (UTC)

1) I'd use the warning signs as maxheight. For the bridge's height I'd use the most accurrate information I can get – in most cases, this will be the value of the warning sign, too, but if you have knowledge about some reliable + x meters rule or even access to measurement equipment, it can be more precise.

2) I do not have a strong opinion on that one. I'd accept either one, as long as it is clearly defined. That doesn't seem to be the case so far, though. --Tordanik 16:47, 26th October 2008 (UTC)

To me the tagwatch figures look like about one in twenty uses of maxheight is on a way making up the bridge and the rest are on the road going under the bridge. Personally I think that if the road going under the bridge is split anyways near the blocking bridge (at the next intersection, at most), there's no need to split the way any further to make a 20 meter way for just the section under the bridge. Alv 05:42, 24th October 2008 (UTC)

What's the discussion here? maxheight=* means that the way with that tag doesn't allow vehicles that are higher than indicated. It's well possible to both have a maxheight=* on the bridge itself (which would mean for example beams over the road of the bridge itself like on []), and on the road under it. --Eimai 13:54, 25th October 2008 (UTC)

This from Eimai is perfectly clear, but it does need really spelling out somewhere (if not already done). Unless you know how routers work (I didn't) it's far from intuitive: what one sees on the ground is a maxheight sign stuck on the bridge, usually above the roadway. --Eteb3 (talk) 19:03, 31 August 2019 (UTC)

bridge=humpback

I think we need to start marking up humback brides due to their unsuitability for some long vehicles. Any objections to : bridge=humpback? --Pobice 17:02, 3rd May 2009 (UTC)

Go ahead. I do bridge=pontoon without asking for permission. "Be bold" applies here, as everything unless no is rendered as a bridge. --Ipofanes 15:03, 13 August 2009 (UTC)

height:sailing

For Marine Mapping‎ purposes, maybe a height:sailing=* might be of interest, to show safe sailing height under a bridge. This is often a little lower than the maximum height of a bridge, and often marked on bridges crossing canals, or marked in marine maps. There is a rule of how to measure this sailing height, as it should be refered to a reference water-level, and have a certain width or % of the span. --Skippern 18:29, 3rd May 2009 (UTC)

There is a tag that will do this, based on the totally comprehensive IHO system. See https://wiki.openstreetmap.org/wiki/Seamarks/Bridges#Clearances [By now (+10 years!) and your profession, you may know this... For the benefit of others!] Eteb3 (talk) 19:13, 31 August 2019 (UTC)

Bridge junctions

The page says "If the bridge ends in a junction, you'll need a small non-bridge way between bridge and junction". This seems to be there purely to prevent messy rendering. Surely it's the responsibility of the renderer to fix this, rather than the underlying positional data? --Pinkduck 13:26, 28 July 2009 (UTC)

The non bridge way is at the centerline of that road; the bridge starts (almost always anyway) some or tens of meters away from the intersection midpoint. Alv 13:35, 28 July 2009 (UTC)

I know of an intersection that sort of starts on the bridge, the bridge widens a bit at the far end. I have tagged it as if the bridge and the two roads share the same node. AFAICT that is the best way to solve that. --Skippern 04:10, 6 October 2009 (UTC)

bridge=low_water

Hello, the Bridge definition is: structure built to span a valley, road, body of water, or other physical obstacle, for the purpose of providing passage over the obstacle.

The ford definition is: a place in a watercourse (most commonly a stream or river) that is shallow enough to be crossed by wading, on horseback, or in a wheeled vehicle. A ford is mostly a natural phenomenon, in contrast to a low water crossing, which is an artificial bridge that allows crossing a river or stream when water is low.

A Low water crossing is an artificial structure similar to a bridge, mostly built over tertiary roads, because they're less expensive than a regular bridge. The difference between a bridge and a low water crossing is that a low water crossing can be unaccessible in some period of the year, for example after heavy rain but a bridge is always accessible (except in case of natural disasters).

Until now i tagged this kind of crossing as highway=ford, but I think that a tag bridge=low_water can be a great improvement over the readability of the map, and also can be useful for the purpose of routing.

The waterway=ford tag is not a good description for at least two reasons:

1) a ford implies that you wet your tires (feet) except for a few days on a year, a low water crossing is supposed to be dry in normal conditions so you will not wet your tyres (feet) except for few days on a year

2) a ford is usually a natural place on the river , a low water crossing is built, so highway=ford does not well describe the way the obstacle (river) is passed. A routing algorithm should avoid to let you pass a ford with a city car, but it can drive you through a low water crossing on a highway=primary if doing so might shorten your trip by an hour ... or if there is no other choice... the routing software just have to warn you about the possibility of flooding, so if there's heavy rain you may decide to instruct the software to try another way.

the standard bridge=yes is not useable because it'sambiguous, the routing software should warn you that the bridge may be unusable in case of heavy rain, I'm not talking about exceptional flooding, talking about simple heavy rain like it may happen 3/4 times per year.

This behaviour of the routing software may also be accomplished using any other kind of warning or restriction but the fact is that a low_water bridge is structurally different by a standard bridge and should not tagged as brige=yes, in doubt I think it is safer to tag it as a ford, but would be better to use a more specific information like bridge=low_water

I'm sorry of being so verbose but before to add a proposal I wanted to discuss it here.

I add a simple [example here]: the crossing between the stream "Stura" and the unclassified road is tagged as a ford. It is not a ford it is a low water bridge, if the weather is clear is safe even for a small city car to use it. If it is rainy it is very dangerous to pass it over, two years ago two young men died trying to pass it over with a Defender 4x4 because (probably says the investigators) they did not see where to put their weels on the darkness and fell into the water of the swollen stream.

Little resume: I would like to tag a low water crossing as bridge=something_like_low_water_crossing instead of have to choose between bridge=yes (that means that this is a regular bridge) and highway=ford that means that you are supposed to wet your weels, that kind of bridge may have a layer default = 0 instead of layer=1.

I believe that a suitable tagging would be to apply highway=* + ford=yes + bridge=yes to the way (road segment). An optional extra might be layer=0 to indicate that the bridge decking is NOT raised above normal ground level (this is totally redundant, since layer=0 is the deafult, but leaves a visible clues for future mappers - he won't automatically assume that layer=1 is correct but was forgotten). You should also consider adding tags such as ford:seasonal=yes (when there is a noticable dry-season/wet-season, be they tropical or simply summer and winter) and/or ford:intermittent=yes (when rainfall is sporadic and/or when runoff is rarely sufficient to flood the roadway. No extra tagging is required on the watercourse, other than watercourse=* and probably boat=no (for just the segment around the low-water-bridge, indicating a portage for canoe/kayak). But you could add layer=-1 to indicate that the watercourse is below ground or, again explicitly (redundantly), tag as layer=0 to indicate that it this NOT the case. Another possibilty would be to add a tunnel=culvert on the watercourse segment (probably implies foot=no + boat=no - even though these do not yet seem to be formally specified?). Finally, don't forget to make the areas around-abouts as lake, marsh or whatever as the case many be (seasonal? intermittent?) and/or to also tag the approache roads to that low-water-bridge as also being ford=yes if they be subject to flooding (seasonal? intermittent?). Any roadway covered by shallow water is by definition a ford - with or without being so voted by the local government authorities!!

--Neil Dewhurst, Lyon France 10:07, 12 October 2012 (BST)

Wikipedia explains that at a low water crossing "Under high flow conditions, water runs over the roadway and precludes vehicular traffic", "Once the water level rises to the point where it crosses the bridge surface the bridge is generally unsafe to use...", and explains why a low water crossing is not a ford. This leads me to believe that flood_prone=yes is more appropriate than ford=yes for low water crossings. --Biff (talk) 06:49, 29 July 2013 (UTC)

Endpoints

When there exists aerial imagery of sufficient resolution, bridges should be mapped as ways. What I'm wondering is where should we define the endpoints? Here's my thinking:

If you know the location of the abutments, then use those as the endpoints.
If you can identify a change in surface (asphalt->concrete->asphalt), then use the points of change as endpoints.
If you have sufficient resolution, judge the ends of the bridge by inspecting rails or other components of the bridge structure.
Otherwise, map the bridge as a node.

Please let me know what standards you apply, as it would be nice to have some guidance we can provide, especially to newer mappers. -- Joshdoe 12:21, 24 March 2011 (UTC)

I Agree to the first 3 points. With the last point, there is the problem that if you map a bride as node, you are not able to define what is the upper and the lower way. --Langläufer 15:42, 24 March 2011 (UTC)

(Almost) nobody maps bridges as nodes. Bridges were mapped as ways even when we didn't have any aerial imagery at all. If you don't know exactly where it ends, simply start the bridge way a bit before the first object below the bridge and end it a bit after the last object below the bridge. --Tordanik 15:46, 24 March 2011 (UTC)

As of right now, there are 895 ,824 ways and 12 ,258 nodes tagged as bridge=yes, so only 1.3% are tagged as nodes. However if you really have no idea how long a bridge is, then I think it's better to map it as a node. -- Joshdoe 03:35, 2 April 2011 (BST)

And 74.90% of these bridge nodes are tagged "ncat" and limited to a very small geographical area, which means that they are likely just import artifacts; not something that humans have mapped. If you have no idea at all how long the bridge is and have no idea what is below the bridge (because that information - what is below the bridge - is not available for evaluations if you use just a node), then a node could express the avaliable information (or rather lack of it). However, a way with bridge=yes + fixme=bridge length unknown works, too, and I don't really see a reason to burden applications with yet another special case if there is virtually no demand for it. --Tordanik 09:20, 2 April 2011 (BST)

I wasn't aware of "ncat", and forgot to account for overlapping ways. Indeed I would replace my step 4 with what you've said about overlapping ways and using a fixme tag. Thanks for the feedback. -- Joshdoe 02:04, 3 April 2011 (BST)

Moveable Bridges

As far as I can see, there is actually no guideline for tagging moveable bridges. So I took a look at a famous example: the tower bridge. There this problem is solved by setting it bridge=lifting. In my opinion it would be better, to have the information if and how a bridge is moveable in a separate tag, maybe moveable=lifting, folding, retractable etc. For a list of possible values, cf. Moveable Bridge on Wikipedia. How do you think? Bbauer 11:43, 23 September 2011 (BST)

Edit: As you can see here, there are two bridges "Hörnbrücke" and "Ersatzbrücke" mapped with bridge=folding resp. bridge=retractable. Those are not rendered by mapnik and also the free navigation software navit doesn't treat them as bridges which leeds to the funny fact that in pedestrian mode navit recommends to take a harbour sightseeing ship to get to the other side.

I agree that we should come up with a standard for tagging movable bridges. I don't think a separate tag is that useful, since I can't think of any non-bridge structures where the tag would be used. The fact that the bridge=... tag isn't rendered / used by routing software correctly is no good argument for introducing a new tag. --Hobbesvsboyle 17:44, 3 October 2011 (BST)

Agree that rendering should by default treat "bridge=*" as a bridge and that "bridge={type}" would be ok to run with. --Ceyockey 22:04, 3 October 2011 (BST)

Proposal for expansion

I'm considering writing up a proposal (or two closely related proposals) to expand our tagging of bridges, and I'd like to run them through here before I formalize them. The proposal largely deals with the function and type of construction of bridges; proposed values have been inspired by a combination of current Taginfo, Wikipedia and Wikimedia Commons bridge classification categories, and Paul Mallery's "Bridge and Trestle Handbook" (4th ed.) While it should handle the vast majority of cases, it is not, of course, completely comprehensive; I have tried to limit it to those values I thought most valuable to define.

The first is to document and extend the "bridge_type" key, which at present seems to be largely used by one of the Haiti mapping projects. I would propose the following values for it: arch, humpback, beam, cable-stayed, cantilever, girder, box_girder, plate_girder, suspension, trestle, and truss. (The meanings are, I trust, obvious to the readership here.) Some values presently used on the "bridge" key would be transferred to the "bridge_type" key, particularly "suspension" and "humpback". The "bridge_type" key would be applied to the objects (largely ways) tagged with the "bridge" key.

The second proposal is to reaffirm and extend values of the "bridge" key. The following values would continue to be used with the key: covered, moveable, bascule, drawbridge, lift, swing, transporter, floating, pontoon, viaduct, low_water_crossing, boardwalk, abandoned, aqueduct and culvert. "Drawbridge" is specifically used for bascule bridges where the weight of one end is supported by cables. "Moveable" is used for moveable bridges that do not fit any of the bascule to transporter values. The choice of values to be retained here allows moveable and covered bridges to be tagged with a bridge_type as well.

A few values will also be created for nodes on a bridge way. These are "pier" (to be placed in the middle of the piers, bents, or other supports beneath a bridge), "abutment" (to be placed to indicate a deliberate construction, such as a stone or concrete wall, under one end of a bridge span), "pivot_pier" (to be placed under the turning pier of a swing bridge or the trunnion-bearing pier of a bascule bridge or draw bridge), and "lift_pier" (to be placed on the pier supporting a lift tower of a lift bridge).

In bridges with multiple spans, the bridge's way should be split to allow appropriate tagging. (For instance, a swing bridge with trestle approaches might consist of three ways: "bridge=yes;bridge_type=trestle", "bridge=swing;bridge_type=truss", "bridge=yes;bridge_type=trestle".)

Values explicitly deprecated: causeway and levee are deprecated as values for the "bridge" key. They should be replaced by "embankment=yes". Footbridge, foot, railway, and so on are deprecated: these values are implied by the way carried by the bridge. Current values of "bridge" not explicitly deprecated should not necessarily be removed but will not be documented.

The material of the bridge fabric (concrete, steel, stone) etc. has not been treated in this proposal. The Haiti project seems to use something like "base_construction_value" as a key for this but I think the current proposal is sufficiently lengthy.

Issues:

Should culvert be a "bridge" or a "bridge_type" value? I favor the former for compatibility with current tagging.
I have omitted some other possibly useful values now to be found in TagInfo: sleepers, plank, balk, bailey, army, skyway, naviduct, tilting, retractable.

Please comment on the appropriateness of the proposal and values you think ought to be added or omitted. I would like to make this into a formal RFC and, if possible, submit patches to the common tools. Choess 01:58, 5 November 2011 (UTC)

Hello Choess, I think your proposal is interesting and want to encourage you to write a separate proposal page for it. Preferably, that page should include images (photographs or drawings; it is possible to directly include images from Wikimedia Commons on this wiki) that illustrate the various bridge types. I assume that mappers are not necessarily familiar with all of the terms, especially those who do not speak English as their native language.

I strongly recommend that you also send a mail to the tagging mailing list. Few people actively look for new posts on wiki talk pages, so you will unfortunately not receive a lot of feedback here. --Tordanik 01:34, 28 November 2011 (UTC)

Trestles

I am proposing a new bridge type, bridge=trestle. See description in Wikipedia. --T99 09:25, 2 January 2012 (UTC)

Has anyone else noticed that the "Search" functionality on this wiki doesn't always find what you're looking for? I did search for "trestle" before starting this section. However, the search did not find the secion just above, even though it specifically mentions "trestle" as a bridge type! Nevertheless, I went ahead and mapped a couple of trestles, including the one that burned down a few years ago in Sacramento (prompting UP to build a short connector in Marysville in only 3 days to facilitate the Sacramento-Marysville-Roseville detour). --T99 10:23, 5 January 2012 (UTC)

Sounds good. While we are at it Wikipedia lists 'Cable-stayed bridges‎', 'Cantilever bridges', 'Girder bridges', 'Vertical lift bridges' and a bunch of other ones here w:en:Category:Bridges by structural type. PeterIto 11:42, 5 January 2012 (UTC)

Added bridge types tables to the article with more values

I have added a bunch of the more commonly used types of bridge from taginfo to the article (on the basis that the agreed proposal was for 'bridge=...' where ... was the type of bridge. I suggest we use Wikipedia as a source of preferred names and definitions for bridge types. Are these being rendered yet? If not then can someone encourage the style guys to get on with it for the main Mapnik layer at least. PeterIto 12:36, 5 January 2012 (UTC)

Please at least discuss these on the tagging mailing list, I'd actually prefer a proper proposal. Existing usage is minimal (< 0.05 % of bridge values for each), it cannot be used on its own as a validation of these values. --Tordanik 15:19, 5 January 2012 (UTC)

What do you suggest? Happy to remove them from the main table into the proposals section at the bottom of the page. I agree that the existing usage of these other values is low, but that may partly be because they aren't publicised and aren't rendered (assuming that they are not). My inclusion of the values was primarily based on the fact that the original approved proposal was for 'bridge...' not just for the limited selection of values that we mention. Regarding the email list, I have pretty much given up on lists and feel that the talk pages associated with the relevant feature provide a much more fine-grained and efficient mechanism for discussion tags. I am still keen to get more types into use because that information will be very handy when people get into 3D CGI based on the styles. Can we get the main mapnik style to render any value of bridge (if it doesn't)? PeterIto 16:39, 5 January 2012 (UTC)

Moving them to the proposals section would be fine with me. This should account for their status as unproven ideas - I guess you could imagine different ways of filling the blanks the original, open-ended proposal. Mapnik still seems to have a problem with the values (e.g.

24470126), but I agree this behaviour should be fixed. I'm also interested in using bridge attributes for 3D, but I don't think that this selection of simple values is already sufficient for a realistic representation. --Tordanik 23:46, 5 January 2012 (UTC)

Many of the new suggested types are fine, but I find causeway somewhat misplaced. A causeway is technically an embankment=* across water or wetlands (or a road / railway built on such an embankment). The embankment is filled with solid material, preventing water or traffic from passing from one side to another. This is significantly different from a regular bridge, which is specifically designed to allow objects/substances on different levels to travel on crossing paths. Also, the description of viaduct is not very accurate. A viaduct is any bridge with multiple spans; it doesn't imply pillars or any specific structure or span length. A viaduct with very short spans is called a trestle (I propose a bridge=trestle tag) and one with long spans is simply called a bridge. To emphasize the multitude of spans, perhaps something like bridge:spans=number could be used. --T99 01:13, 6 January 2012 (UTC)

Rather than have out own discussion here about bridge types I thought it best to leave that discussion to Wikipedia (and join their discussion). I intended to include everything in Category:Bridges by structural type but take your point about the definition of viaduct, for some reason I make one up rather than using Wikipedia's version which is 'A viaduct is bridge composed of several small spans'. I note that a Tresle seems to be different from a viaduct being constructed from a mesh of wood or steel and has its own article. w:en:Trestle bridge Incidentally Wikipedia categories seem to be in a bit of a muddle with a Trestle being in 'Bridge Design' not 'Bridges_by_structural_type', a Causeway is described as a sort of bridge, but is then not in either 'bridge design' or 'bridge by structural type', and I have already removed 'Ford (river crossing)' from the bridges category in Wikipedia cos it isn't a bridge! PeterIto 03:16, 6 January 2012 (UTC)

I have now adjusted this article to move proposed values into a new table, remove causeway from the proposed values table and done some other adjustments to the article. I think these address the concerns identified above for the time being. I look forward to getting these other values rendered. Can someone flag that up to the relevant people? PeterIto 03:29, 6 January 2012 (UTC)

Tagging arches individually

It occurs to me that it will be useful to capture the 'number of arches' for some bridge types. Some by definition have only one arch (humpback for example) but others, notably viaducts and suspension bridge often have more than one. This could either be represented as a simple number to be distributed by some 3D visualisation engine as it sees fit, or could be tagged as a series of nodes alone the bridge at the appropriate positioned, each tagged with some suitable tag (similar to the way that power lines use power=pole. In an extreme case these nodes could include a height tag to indicate how far below the ground level is. PeterIto 03:38, 6 January 2012 (UTC)

Just noticed that this new record braking bridge has opened in Mexico.[1]. Would be a good example of the use of arches. PeterIto 04:10, 6 January 2012 (UTC)

Pedantically, the Baluarte Bridge does not have any arches. It does have a number of spans. The main span is cable-stayed and the approach spans are cantilevered. --T99 19:02, 6 January 2012 (UTC)

You are of course right and where would OSM be without pedants :) I guess what I am suggesting is that we need a way to indicate a node (or possibly area for the cross section) for each 'support' which might also have construction material defined (concrete, steel, iron, brick, stone etc) and optionally a depth below the deck to ground level and also possibly upwards for suspension bridges. The spans (or arches for some bridge types) are the sections between pairs of supports. For a bridge with regular supports then a simple number_of_supports could be used. PeterIto 23:22, 6 January 2012 (UTC)

Bridge vs Tunnels

I once added a section on this Key:bridge page titled 'Bridge vs Tunnel' which read as follows:

"Sometimes you'll be faced with a decision, should the higher level way be a bridge passing over the lower level way, or should the lower level way be tagged as a tunnel (tunnel=yes). So far we're a little undecided about the best approach to decide in cases where it's not obvious. See Question: Bridge vs Tunnel. Follow your instincts! The main thing is to get the levels right either case and avoid joining roads which are not joined."

...all a bit vague and leaving it open. But that was removed and now we've got this more specific advice:

'"Where the lower feature is surrounded by earth then the lower feature should be tagged tunnel=* instead. It is not always clear whether a particular crossing is a bridge or a tunnel, but it is best to choose one approach and avoid creating a bridge for the upper way and also tunnel for the lower way"

...which is good I guess. See Question: Bridge vs Tunnel for a more full discussion. My idea in an answer there, was just to look at the comparative lengths, but I don't really have any strong objection the this "surrounded by earth" definition. Just flagging the change here for discussion. I suppose it falls down in some weird cases where a long thing (a bridge!) happens to be "surrounded by earth" at the lower level.

-- Harry Wood 13:49, 8 February 2012 (UTC)

Do please further refine the definition. I made that change as part of a major cleanup of articles on the subject and I may have lost something on the way. Fyi, GDF ducks the whole issue by introducing the term 'Brunnel' which could refer to either! PeterIto 14:25, 8 February 2012 (UTC)

There's to me a serious dilemma with "Where the lower feature is surrounded by earth..." In our region many motor- and rail-ways are on man_made embankment. During construction gaps are left, retaining walls constructed, between which a road passes over which a mono spaced or sometimes a pier supported split road one and the other way is laid, above which a roof construction is placed of prefab reinforced concrete beams. Often when the maxheight=below_default a "Ponte Basso" (low bridge) sign is shown at the entrances and a max height traffic signs. The same identical construction appears at times without the "Ponte Basso", just the maxheight, or no maxheight indicating the default. How to tag the road passing below and should the roof construction be mapped (no earth layer above, just concrete, asphalt, rail).

-- SekeRob 16:13, 13 January 2021 (UTC)

Adding nodes nearby to crossing ways

When I map bridges, tunnels and other similar crossings where there is no interchange of traffic between the two ways, I tend to add some nodes nearby, possibly on each side of the bridge/tunnel on the way going under the bridge or over the tunnel. This 'anchors' the way to that location and makes it easier for editors to load relevant data. This also prevents ill effects of moving a distant node on that way so that the two ways doesnt cross where the bridge/tunnel is anymore. --Gorm 21:02, 11 October 2012 (BST)

Bridge types and access restrictions.

Some thoughts about appropriate tagging of bridges:

For highways, the only interesting information is probably bridge=yes and bridge=abandoned. These tags implicitly provide the info: access=yes/no.
More detailed information about the actual way of construction should probably not be attached to the road but rather to the bridge itself, see man_made=bridge or relation:bridge. (Personally, I think man_made=bridge is easier to handle than the bridge relation.)
Additional access information, e.g. info about times when a moveable bridge is closed for vehicle traffic can be provided by using access:conditional=*.
Don't forget that in the case of a moveable bridge there are typically two ways that are affected: The highway on the road is closed while the bridge is up, whereas the waterway below the bridge can always be passed by small boats, but bigger boats can only pass while the bridge is up. In this case it's probably useful to apply maxheight=:conditional rather than the access tag to the waterway.

--Biff (talk) 23:16, 31 July 2013 (UTC)

Simple one-node brunnels for way over waterway

Proposal: Simple one node method of mapping grade separated crossings of waterways with highways or other ways. This is in essence equal to saying "this is not a ford but some kind of grade separated crossing that is safe to cross with dry feet" in cases where more detailed mapping is not possible or practical.

To be applied for: waterway running under some other way when at least one of the following conditions is met:

insignificant crossings where bridge/culvert size is frequently only a fraction of achievable GPS precision
when it is certain there is a grade separated crossing but not the exact details (bridge, tunnel or culvert)
temporary bridges/culverts which are frequently replaced or repaired
HOT mapping

How:

create a single shared node where the ways are crossing
mark it with bridge=simple_brunnel
no layer tags - water is defined to run bellow other way, thus use is limited to the specific case of non-waterway over waterway

Further implications:

dimensions of the brunnel can be approximately estimated when width of the highway and stream are known. It would be nice to be able to specify the dimensions of the brunnel with some attributes but it is not clear how this could be done with a single node.
traffic restrictions, hazard attributes could be mapped to the simple_brunnel node
mapnik renders it as a culvert without any changes, the difference between "missing data" crossing and culvert is not visible in mapnik
most other renderers and tools are build around the assumption that where a highway crosses a waterway there is a culvert or some kind of a grade-separated crossing. These would work without change on the assumption that they would simply ignore the hitherto unknown tag combination.
renderers that make a difference between culverts and the "missing information" case would need to be updated

Rationale:

Worldwide by far the most frequent type of bridges/culverts is a waterway crossing bellow some other way. Very frequently such structures are small enough that the average GPS error is a multiple of the brunnel dimensions, many of them are simple pipes bellow the road. In other cases it is well known that there is a grade separated crossing in the place but the type (bridge/tunnel/culvert) are not known exactly. In some countries it is common that many of these bridges/culverts are replaced after every rain period when the highway is graded.

At present, we have the choice to not map such situations at all because of partially missing data or to paint a bridge or culvert structure with 2-4 nodes (both ways need to be fixed so the crossing remains in place when more distant points are moved) whose precise position is highly uncertain - effectively inserting junk or fictive data into the database. The amount of junk data generated this way is considerable: one way is split into three pieces, relations and various attributes are copied over, 2-4 additional nodes marking positions. Waterways frequently share ways with administrative borders - in such cases the attempt to insert a culvert without distorting the administrative boundary is a hair-raising exercise with frequently hair-raising results.

Painting a detailed bridge or culvert in such situations pretends more precise data then is available.

The next mapper who has more precise data may have considerable additional work just to cleanup this fictive data before he can insert for example a bridge instead of a culvert. A single node brunnel on the other hand is extremely easy to delete or reposition should a change be necessary.

Leaving the crossing unmapped when it is known that it is a grade-separated crossing is also highly unsatisfactory - the information "it is not a ford" may be vital in many situations. There is a very simple one-node method to map small fords - similar is needed for small bridges/culverts.

While it looks strange at first that a grade separated highway/waterway crossing would have a share a node this is common practice for dams with highways on top of them and thus unlikely to cause major problems for most tools. Semantically it can also be viewed as correct because small culverts are integral part of the highway above them.

Amphibious vehicles routing algorithms could be in theory confused but many thousands of bridges already exist in OSM data sharing nodes with the river bellow.

Test edit: http://www.openstreetmap.org/changeset/20229987

Last updated - RicoZ (talk) 14:32, 2 April 2014 (UTC)

This would be a tremendous help without any loss of information!

Rationale: In Austria, where I mostly map hiking trails in mountainous regions, we have the open government waterways data at our disposal, as well as areal images. When I map using my hiking tracks data and combine them with these other sources, then literally hundreds of such crossings are created. For me there is no doubt - this would really be a great help!

--BorutAtOSM (talk) 08:11, 27 January 2014 (UTC)

Using a semicolon to add two values for the same attribute to two different ways is a massive hack. Your proposed solution also contradicts the existing convention that features crossing at different height should not have a shared node. So "no rendering changes required" is simply untrue - this idea would indeed require significant changes in applications that rely on any of these attributes and conventions. (No, Mapnik is not the only renderer.) --Tordanik 14:51, 27 January 2014 (UTC)

It would be useful enough without the attributes if that is considered hack and no better solution arises.

I don't see how the convention of not having a shared node at different levels is useful anywhere and it isn't like breaking it has no precedence. One example are dams with a road on top of them. The road is logically above the waterway going through the dam but the dam (and hence road) and waterway are expected to share a node where they cross (another example of a useless or outright harmful convention btw). The convention is also a pain for lifts. Very often this convention is broken with pylons.

Do you have an example of a renderer or application that breaks with the test edit? Will that application also break when there is a ford instead? I can not see how handling this case would require big changes. Most routing apps could simply ignore as they do now, renderers will continue to ignore it. The only case that could need special attention is a routing app for amphibious vehicles which in theory might be tempted to jump from the bridge into the stream - however amphibious vehicles probably should not be routed through small streams without a boat=yes anyway. If anywhere this would have been long noticed as a problem with the dam example. RicoZ (talk) 17:55, 27 January 2014 (UTC)

3D rendering is generally dependent on not merging nodes at different elevation (at least my own renderer is, which is why I instantly noticed this). Of course it's always possible to throw in even more special case rules, but they don't write themselves and it doesn't simply work with no change as claimed. Now if a lot of mappers think that this one change saves them tons of time, so be it, but mapping a full bridge is still reasonably quick - I don't see why you think you have to copy over any attributes, for example. --Tordanik 22:22, 27 January 2014 (UTC)

Did you test your 3D renderer on it or do you have an url? I would be curios to see how it breaks on this example. Luckily, even if it would slightly break 3D mapping this is not going to be used in areas where 3D mapping is going to be useful. I would not want to cause catastrophic failure to any tool but I think the rule has already been broken so many times that this is not very likely.

Yes, a full bridge is not terribly hard to do. But for any bridge under 10 meters length unless you have very special equipment you are basically adding junk data if you try to "paint" it with two nodes. You do not have to copy the attributes by hand - JOSM does it for you, with all the unwanted consequences: you end up putting state borders into culverts etc.

I did look at the exceptions to the rule that features on different layers should not share nodes. Seems like a very high number of waterway=dam with a highway on top of it breaks that rule.. the first 2 that I looked at were matches, which is not surprising as it is described in the wiki that the dam-river intersection should share a node, I think even if the river is passing through some kind of tunnel or pipeline.

* http://www.openstreetmap.org/node/19748399

* http://www.openstreetmap.org/node/288173263

Other exceptions that come to my mind are pylons of aerialways in cases where they are shared by two or more aerialways crossing at different levels, not very rare where I was skiing. Similar situations will arise with pylons supporting several levels of bridges.

Another exception is the use of covered=yes.. btw I was trying to cleanup that wiki page some days ago and it could certainly use more eyes. I think that covered=yes and covered=building_passage/arcade etc are two completely different concepts - first being something like an abstract layering rule, the second describing a physical object and unfortunately those two concepts share a common tag. I was also trying to elaborate the layer=* tagging rules lately to make them as precise as possible without breaking current common usage patters and it is pretty hairy. RicoZ (talk) 10:39, 28 January 2014 (UTC)

Well, for my part, I would gladly use this feature only with stream+path and stream+forestry road combinations, where I am at the edit time not 100% sure if it is a culvert, or a ford, or I am sure that it is a culvert. It might actually be that it is in fact a small bridge. When I know that it is a bridge, I would map a bridge anyway. Here is an example of the area where my previous entered waterways still have to be reedited against the areal photos and - while doing that - all the crossings have to properly be taken care for: KeepRight showing massive ToDo on streams in an Austrian forest So, well, for me this really means tons of time and I would therefore be really happy to do it in the here proposed way. --BorutAtOSM (talk) 06:33, 28 January 2014 (UTC)

I think for mapping this would be a great help; for rendering it has its issues. If I think about how to render this ins mapsforge there are two problems:

Bridges are easy to render as ways, because there are lots of possibilities to design them; nodes can only be symbols, circles or captions; the only reasonable of those is to use a circle, but this leads to inconsistent rendering - it will make a very visible difference if a bridge is mapped as a node or a way
As the node is shared, one has to decide in the rendering if you render the stream bellow or the highway above, both won't be visible; which makes the sharing a bit redundant; if the tag is defined for not having to have a layer tag, why not just tag as a not shared node to the highway? --Eartrumpet 7:29, 29 January 2014 (UTC)

This feature is proposed "for the simple case a railway/highway/track/hiking_path is passing above an insignificant waterway". In these cases the mapper is generally unsure if it is a culvert, a ford, or an insignificant bridge (I am here thinking of bridges of, say, 1 m length on paths or possibly some 4 m on mountain roads). The object in question is a node. The proposed approach makes the crossing of a waterway and highway on the same layer possible (as is now the case for a ford), thus avoiding obvious mapping errors of crossing waterway and highway in the same layer without a node. It suffices to render waterways before highways in the same layer, that is it can be seen as a "dried out" ford without a ford symbol. The proposal provides for a possibility to later easily find such nodes in a given area and to refine the crossings when more data becomes available (please correct me if I misunderstood the idea). No changes of rendering were suggested or asked for. I would say that special rendering would actually be discouraged. However, I indeed have no idea about 3D rendering. I can just say that - for the proposed use - the two crossing ways are in reality "almost in the same layer" :) or most probably indeed being in the same layer (then being a ford, which is not known for sure when editing). --BorutAtOSM (talk) 09:31, 29 January 2014 (UTC)

I understood that this would be a final solution for such a bridge, not a marker for later mapping. As such rendering should be possible, especially for hikers - it is crucial to know if a path has a bridge, a ford or nothing if there is heavy rain so one can decide which path would be safer. Therefore I'm rendering culverts etc. in my theme already. --Eartrumpet 10:11, 29 January 2014 (UTC)

I was expecting that it would be rendered like a culvert or a crossbreed of a bridge and culvert. Mapnik and many other renderers do not draw anything in such a situation so they could continue to ignore the new tag-value combination. But if you want to render it as culvert that would be a great progress compared to the current state. For now the information content of this solution would be "this is not a ford but some kind of grade-separated crossing of some way over a waterway".
Not sure about the not-shared node.. was thinking about it but it would have some problems. It would make practical error checking more difficult - how precise above the waterway is close enough so that JOSM/Keepright should not complain about a waterway/higway crossing? Someone might move the node or stream and it would be suddenly a bridge far away from the stream. When creating a node close enough to the waterway it would be easy to create a shared node by accident. The error checking/validator of JOSM and Keepright would have to be adopted to handle the new method - at least the JOSM validator does the right thing in the shared node case without any extra adjustments.

RicoZ (talk) 11:43, 29 January 2014 (UTC)

You're right, shared is better that way, and rendering is still possible. As mapsforge is quite a rough renderer one hast to simplify things anyway, and we have culverts as equivalents to bridges in OAM since the last big update, see here: [2]. So they are rendered like bridges with Elevate theme and OAM (fords are still missing though, but on the to do list). I can imagine a possible rendering with circles beneath a path/track so in theory it's possible, but not as nice as if it was a way. --Eartrumpet 20:28, 29 January 2014 (UTC)

The length of the culvert could be approximately estimated from the track width (for rendering the rendered dimensions are more important than the real ones) and the angle at which the two ways are crossing. That might be more complicated than needed. A simpler method could be to change the rendering of the upper way for some short section - a way with two paralel black lines or something similar to denote a bridge. This will not be perfect if the ways cross in some very small angle but it would not be too bad and fortunately this is a very rare situation - most simple culverts are close to 90 degrees to the way. RicoZ (talk) 21:15, 29 January 2014 (UTC)

That's how bridges/culverts are rendered now, but it's only possible because they are ways. It's not possible for nodes. The node simple_brunnel can only be rendered independent of the path as a symbol or circle (or caption) at the point of the node, no direction of the symbol/borders/squares or anything else is possible, same problem as with mountain_pass or saddle - see my first post above. --Eartrumpet 22:06, 29 January 2014 (UTC)

I see. Seems to me that mapsforge does a pretty good job at rendering the culvert out of the box and instead it would be more useful to display a warning symbol in the places where there is missing data and thus potentially a wet feet xing - this symbol should also be visible when zoomed out a few levels so you will see it some way before you get all the way to the place. This would probably need some preprocessing of osm data because missing xing isn't a feature normally accessible to rendering themes? Sooner or later I will dig into the mapsforge code to explore the possibilities, a few preprocessing steps to cleanup osm data would be quick to hack for me if Christian' map generation setup can handle some more processing load. RicoZ (talk) 09:37, 30 January 2014 (UTC)

As you know a wet feed xing exists (ford), it's just not mapped a lot for paths. I'm not sure if it's necessary to have an additional indicator for having no information about a path/stream crossing. I prefer to render if there is a bridge/culvert/ford/tunnel, the rest is just guessing and is already visible - as a crossing without anything. The map user is still able to add things up. If you think about good old paper maps, most of them didn't even indicate bridges.

As far as getting this data is concerned - you should ask Christian if that's possible to calculate those nodes without too much additional processing time. I should invest some time for getting fords in OAM. --Eartrumpet10:30, 31 January 2014 (UTC)

Fine, the preprocessing to convert a single node brunnel to something like a regular bridge or culvert that can be better rendered by mapsforge is much less resource intensive and certainly easier to program than trying to find the places where there is missing information. Such preprocessing step could also eliminate the problems which mapsforge has with streams that have erroneous layer tags. RicoZ (talk) 12:31, 31 January 2014 (UTC)

I am a devoted hiker and at the same time an OSM mapper. Sure I map fords, culverts, bridges - as far as I know them - since they are very important to a hiker. At the same time I have (at least in principle) the open government data over virtually thousands of creeks (also unnamed ones) at my disposal. The time is ripe for bringing them into openstreetmap. However, apart form the small part I visited myself, I can not be sure about the form of their crossings with paths and roads (even when comparing with aerial data, since they are in forest). So, one should either

a) Not map these water systems at all (what would be a pity), or

b) Leave the crossings in one layer without a shared node, producing hundreds of errors, or

c) Guess and enter faulty/unproved crossings information (which I would never like to have on my GPS unit, when in the woods).

In this respect this proposal provides a superb solution, avoiding all three problems, while the semantics would be, as RicoZ has nicely put it: "this is not a ford but some kind of grade-separated crossing of some way over a waterway". See here how a nice mountain region full of creeks can be (with a multitude of crossings waiting to be resolved properly): Waymarkedtrails - Kalwang, Austria Would be a pity not to include them, even when crossing types are not certain.

--BorutAtOSM (talk) 12:39, 29 January 2014 (UTC)

OK, now I get your point why you would want a provisional tag. It would really be great to have this streams in the maps. But I thought that this is a tag about an really existing small bridge/culvert/tunnel to make it easier to map these. When I get you right you want to tag all crossings of paths and streams without knowing if there is really some bridge/culvert/tunnel and in my understanding that would be the same as c) --Eartrumpet 20:38, 29 January 2014 (UTC)

Yes, this is a possible danger, which I believe can be avoided by defining a very precise meaning and usage conditions for this tag. In order to be fair to the initial proposal, maybe one should leave the "maybe ford"-case out of consideration.

The distinction between a small bridge and a culvert (both of small dimensions mentioned in the proposal) provides some orientational help for the traveler (if at all visible on the map). But what can a mapper do, not knowing what it actually is? Not wanting to "lie" leaves us with: ways crossing in the same layer and not sharing a node (which is not allowed), or a shared node without a tag (which I admit I do not know if it is allowed).

This is why simple_brunnel, when meaning "might be a creek culvert, or a small bridge over the creek", i.e. in original wording of RicoZ "this is not a ford but some kind of grade-separated crossing", is appealing to me from both the hiker's perspective ("OK, the mapper could not tell", which may create even more confidence into the map) and the mapper's perspective ("culvert or bridge, probably culvert + very easy to map + no DB clutter").

And if any mapper later in fact comes to the place and sees the situation, then transforming it to ford is trivial, while refining it to bridge or a culvert is still an option.

For the 3D rendering I can not tell. For 2D I believe that no changes are needed (provided that waterways are by default rendered under highways). Introducing some special node icon, indicating this "duality" (maybe just some simple point indication on the highway, depending on the theme) might probably be nice. For this it would be important that usage/meaning is made clear to all the parties: mappers, theme/map creators, as well as map users.

--BorutAtOSM (talk) 23:07, 29 January 2014 (UTC)

For now I would prefer sticking with the strict original intention - use it in situations where we are sure that it is not a ford. Maybe we can add similar but distinct features for other situations when this one turns out to work well. I have done a couple of test edits now, always with a comment linking to this page. Since taginfo displays there are already over 10000 single node bridges I think it is safe that you do some more test edits in places that you know well (see eg http://www.openstreetmap.org/changeset/20272315 for a suitable edit summary) and if we don't see any unwanted effects I will document the feature in the wiki.

Meanwhile I will try to explore a bit what those 10000 single node bridges are.. RicoZ (talk) 09:55, 30 January 2014 (UTC)

I shall map some more test brunnels soon. Based on your two test nodes I was able to test the folowing two renderings:

On line: Wanderreitkarte http://www.wanderreitkarte.de/index.php?lon=14.7672&lat=47.4669&zoom=18
On Garmin Oregon: Thkukuk's TK-DACH-Basemap from http://osm.thkukuk.de/#maps

In both cases there are no negative effects, i.e. nothing special is rendered and water is under the track.

--BorutAtOSM (talk) 20:37, 1 February 2014 (UTC)

JOSM validator apparently started to complain ("bridge on suspicious object"). I have noticed this with JOSM Version 6901, while working on a changeset http://www.openstreetmap.org/changeset/21000136 --BorutAtOSM (talk) 06:57, 9 March 2014 (UTC)

JOSM apparently started to show nodes having bridge=simple_brunnel with an error icon. I have noticed this with JOSM Version 7163, while working on a changeset http://www.openstreetmap.org/changeset/22494261 Maybe somebody should contact the JOSM-people about that. Also, as the statistical presence of this value rises slowly but steadily - see http://taginfo.openstreetmap.org/keys/bridge#values - I believe that an appropriate entry in the wiki would be beneficial. I am not acquainted with the proposal process and the next steps to be done, so maybe you RicoZ are the best person to push this forward. After some months of applying this idea I can only repeat: it is really a tremendous help! My general usage area: This Austrian mountain area and also some valleys to the south of it. --BorutAtOSM (talk) 06:22, 23 May 2014 (UTC)

bridge=abandoned

I dont think using abandoned as a bridge value is very good. For other sturctures and abandoned things you normally just add abandoned: in front of the tag (like abandoned:shop=...). I think thats the way how abandoned bridges should be taged too because your dont overwrite the bridgetype. If you have an old viaduct (bridge=viaduct) thats getting abandoned you would still know that this is a viaduct (abandoned:bridge=viaduct). This would also make the tagging more consistent. --Hedaja (talk) 09:53, 1 April 2014 (UTC)

bridge tutorial got lanes= wrong

Thanks for the bridge tutorial. I'm going to remove some of the pictures and update the text because you're teaching people to enter lanes= wrong. lanes= should contain the total number of lanes, not the number of lanes per travel direction.

See http://wiki.openstreetmap.org/wiki/Key:lanes#Examples (and note that the second example has two ways, each taged lanes=2. If it were a single way, it would have lanes=4)

JasonWoof (talk) 14:49, 23 April 2015 (UTC)

Moving over to feature page

Many sections of this page should moved over to a feature page named "Bridge" in order to bring man_made=bridge and bridge=* under one umbrella.--Jojo4u (talk) 13:21, 4 September 2015 (UTC)

Change definition toward "leading over a bridge"

With the introduction of man_made=bridge we have to possiblity to refine bridge=*. For example a highway=* with the property bridge=* does not mean "this is a bridge" but "this is a highway leading over a bridge". The first sentence in the article reads now:
Use bridge=* to identify man-made structures used to carry a road, railway, path canal, pipeline or similar over another feature or across a valley by use of a deck or arches (see below for when to use tunnel=*).
It should e.g. read:
Use bridge=* when a road, railway, path canal, pipeline or similar is leading over a bridge.--Jojo4u (talk) 14:03, 4 September 2015 (UTC)

Seems to be a good idea Mateusz Konieczny (talk) 08:39, 5 September 2015 (UTC)
- Change is done.--Jojo4u (talk) 15:00, 25 October 2015 (UTC)

Bridge:ref or Bridge_ref ?

There appears to be a conflict between the use of bridge:ref and bridge_ref. In wiki, the definition is under http://wiki.openstreetmap.org/wiki/Key:bridge#The_building_number that states: "A bridge reference can use bridge:ref=*. " However, taginfo seems to show that there are almost four times as many bridge_ref as bridge:ref. Suggest that this discussion leads to a choice of one or the other. This arose when adding map detail on the canal around Llangollen. A similar application may be the use of prow_ref for public footpaths... A bridge reference may also also be seen on railway bridge structures. A further bridge issue for canals is how to map a bridge that is seen from the canal/towpath but appears to have no track leading to/from it. Would man_made=bridge raise an error in checking programs if there was no connecting pathway?

Generally, I would recommend adding an explicit bridge (man_made=bridge and add ref=* there, and omit ref on ways with bridge=* properties. If you still want to do it, use bridge:ref which is not only leading in numbers by 01/2021, but also more consistent with bridge:name where numbers are much clearer (01/2021: 41k vs. 2k). --Dieterdreist (talk) 10:53, 15 January 2021 (UTC)

All I know is numbered highways sometimes go over bridges. So there's a conflict between the highway number and the bridge number. Jidanni (talk) 03:32, 28 November 2022 (UTC)

There is no conflict, for bridge as an attribute of a highway (a way on a bridge, not a bridge), the tag is bridge:ref, but for bridges (man_made=bridge) the tag is ref. --Dieterdreist (talk) 13:35, 28 November 2022 (UTC)

Warn about plain "ref="

For "ref=" be sure to use the number of the highway going over the bridge(?)! If you put the Highway department's dusty catalog of bridges reference number, that's what will get shown within the highway marker shield when rendered! Jidanni (talk) 02:58, 27 October 2018 (UTC)

Manufacture/r info

It might be helpful to easily submit manufacture/installation info, e.g.: park bridge over St. Vrain in Fort Lupton has manufacturer's plaque with manufacturer, phone, date constructed, type, serial number. (I noticed this bridge has (at least) two plaques, one for each of two apparent sections.) Less important, but still historically interesting, may be installation date, opening/dedication date.--DougGrinbergs (talk) 18:57, 2 March 2019 (UTC)

Add "what to do in case of disaster" section

Let's face it, bridges don't last forever.

Therefore this Key:bridge page should be ready with a section for what to do in the case of bridge collapse, as this page will be the first place people will look at when it happens. Mention what tags should be changed, or if the bridge simply should be deleted, etc. Jidanni (talk) 15:52, 16 June 2019 (UTC)

Bridges are not handles specially but like any other destroyed object, right? Mateusz Konieczny (talk) 20:21, 16 June 2019 (UTC)

Well all I now is please now rehearse the sequence of events once a major bridge collapses and editors look on this page first for what to do. Also note that bridges collapse more than non-bridges. Jidanni (talk) 02:58, 18 June 2019 (UTC)

Plus there are no corresponding List_of_road_failures, Category:Road_disasters, i.e., bridges are more risky... Jidanni (talk) 02:45, 2 October 2019 (UTC)

https://www.openstreetmap.org/way/145628516 is an example of many editors changing a destroyed bridge in the day after it collapsed, as there is no published recommendation. Jidanni (talk) 20:01, 1 October 2019 (UTC)

I don't claim to have been a mapper long enough to have any special expertise, but this seems to me (1) a possible use case for abandoned:bridge or ruins:bridge; and (2) if that's accepted, a good reason to start rendering objects tagged abandoned on Carto (or at least most/many of those). Eteb3 (talk) 21:44, 1 October 2019 (UTC)

See also https://github.com/gravitystorm/openstreetmap-carto/issues/3916 . Anyway the Minister said they will be rebuilding the bridge right away. Jidanni (talk) 02:42, 2 October 2019 (UTC)

The "abandoned:" or "destryoed:" needs to be applied to the highway as well. RicoZ (talk) 21:50, 8 October 2019 (UTC)

@RicoZ - thanks, of course the lifecycle tag needs to be applied to the first level tag, which is 'highway' in this case, not necessary to the supplementary bridge=* tag. Clarifying on the feature page. --Polarbear w (talk) 07:41, 9 October 2019 (UTC)

The building number

We read

The building number
A bridge reference can use bridge:ref=*.

But below we read

The tag building=bridge refers only to buildings which are used as bridges.

So maybe the top should say

The ref

not

The building number

Jidanni (talk) 19:48, 25 March 2020 (UTC)

How to map pedestrian bridges?

My understanding of this is pedestrian bridges would follow the same or similar tagging scheme as bridges on highways that allow vehicle traffic in that there should be 3 distinct parts. My question is should tagging for pedestrian bridges be the same as it is for other highways or should it have rules specific to pedestrian ways?

For example: You have a pedestrian bridge that crosses over a dual-carriageway and you gain access to the pedestrian bridge via steps. When adding the steps should add the "spacer" on either side of the bridge or could I connect the steps perpendicular to the bridge?

Baconcrisp

"When adding the steps should add the "spacer" on either side of the bridge" what you mean by that? For reference here is one of such pedestrian bridges: https://www.openstreetmap.org/#map=19/49.90126/19.87275&layers=N - though it is missing mapped ground access to elevatiors Mateusz Konieczny (talk) 23:07, 5 August 2020 (UTC)

He's correct. Adding a short highway=footway segment between the crossing part and the highway=steps is a correct refinement of detail. On top of the common (unfavored) practice of connecting the bridge directly as a crude initial step, footbridges usually have intermediate landing levels that are flat to be resting areas. This is usually skipped when creating the footbridge at first by most. Personally I don't leave them out, in order to show the incline=* and levels clearly. -- Kovposch (talk) 10:13, 7 August 2020 (UTC)

Yes, https://www.openstreetmap.org/#map=19/50.09154/19.92632 is bridge mapped in such a bit more detailed way (some edits were just made, tiles may be outdated) Mateusz Konieczny (talk) 11:13, 7 August 2020 (UTC)

Thank you for clarifying! That makes perfect sense! Baconcrisp