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)

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)

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)

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)

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)

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)

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)

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:

1. If you know the location of the  abutments, then use those as the endpoints.
2. If you can identify a change in surface (asphalt->concrete->asphalt), then use the points of change as endpoints.
3. If you have sufficient resolution, judge the ends of the bridge by inspecting rails or other components of the bridge structure.
4. 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:

1. Should culvert be a "bridge" or a "bridge_type" value? I favor the former for compatibility with current tagging.
2. 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 [1]. 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.[2] 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.[3]. 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)

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)