Talk:Relations/Proposed/Bridges and Tunnels

From OpenStreetMap Wiki
Jump to: navigation, search

Comments

  • I like this proposal and think it is a very nice example for the use of relations. I somehow doubt the usefulness of "outline" and "edge", but would be happy, if osmarenderer could take the rest of the information into account. --ramack 15:40, 1 January 2008 (UTC)
  • For me there are still some clarifications required: --FrankT 20:14, 21 May 2008 (UTC)
    • If (like mentioned) bridges cross bridges, also relations should be possible members. This is not mentioned.
    • Is the bridge or tunnel tag on the member ways still required or can it be omitted?
      • I hope not, because otherwise this proposal is useless (because of not minimizing work ;) --Cbm 10:34, 14 June 2008 (UTC)
        • This should be stated explicitely in the proposal then ;) Perhaps: This does not replace bridge=yes/tunnel=yes attached to a way, but when the relation is used these tags are not necessary. --FrankT 11:42, 18 July 2008 (UTC)
    • In response to ramack: I think there are some situations where edge or outline would be required. Imagine a valley where a highway crosses a waterway or railway several times - without any location information the renderer would not be able to determine which crossing would be the right one for the actual relation.
      The proposal from pebe to take Relations/Proposed/Segmented Tag as member seems to be fine too. This would give all necessary information even in the described case. --FrankT 12:16, 18 July 2008 (UTC)
  • I came here because --Eric S 17:00, 26 February 2009 (UTC)
    • I have large roundabouts with parts as bridge (ontop of a motorway). This proposal allows to have one single roundabout with two bridges inside.
    • I have tunnels with an name different to the name of the road inside. Ok with the proposal
    • I am still in trouble with helicoid railway tunnel used in mountain area like between Moutiers and Bourg-Saint-Maurice in France (Savoie). The tunnel is passing over itself. Attribution a single layer to the tunnel relation is not enough. Well, no need to use the relation. But we can also imagine a bridged helicoid loop to access a suspended motorway. We must use a single bridge relation but with several layer. If layer is defined in the relation, it is used. If not, use layer from ways.
  • I like this proposal and I use it for bridges with many separate ways on it, but it is far from done, yet. --Skyper 12:39, 16 September 2009 (UTC)
  • For some outlines multi-polygons will be needed (e.g., P-shaped with a real hole in the middle). --Ij 13:11, 16 October 2009 (UTC)
  • I like the proposal and I started using it! I like to see it as an established relation at least with its core features. These are good enough to model very many situations. We can continue to discuss how to model the most complex situations and enhance it later. But editors and renders can start supporting this relation. -- Nzara 20:34, 29 May 2012 (BST)

I like parts of this proposed:

  • The outline & combine some ways togehter on one bridge/tunnel, instead each for each way are really usefull (for rendering).
  • I think the other thing are unnecessary. These things can also be write into the highway/railway/waterway-tag like: bridge:name=* bridge:ref=* bridge:lenght=* Edit by author: I thought wrong!
  • Are the rolemembers (across, under, through and edge) really necessary? Edit by author: Yes, it is useful.-- MasiMaster 00:50, 27 January 2012 (UTC)
  • The default role should have 'one or more' (zero members of the default role makes no sense) --Gorm 00:26, 6 May 2012 (BST)
    • There may be some rare cases where nothing that we would usually map as way is on top of a bridge. For example there are bridges across motorways that allow wildlife to get to the other side, with just a bit of grass or scrub on top. --Tordanik 10:09, 6 May 2012 (BST)
      • Perhaps so. But we must specify that wee need to have at least one other member of the other roles to avoid relations with no members. --Gorm 12:27, 17 May 2012 (BST)
  • Perhaps instead of "This does not replace bridge=yes[...]", it could read "This proposal outlines an alternative method of designating what is a bridge or tunnel. It is suitable to use in more complex cases where the traditional method (tagging a way with bridge=* or tunnel=*) comes short of details. The two methods can co-exist and even mixed.". --Gorm 00:26, 6 May 2012 (BST)

Splitting ways?

"This does not replace bridge=yes/tunnel=yes attached to a way." Does this mean you still must split ways and apply the bridge/tunnel tag to the artificial mini-ways? --Keichwa 06:43, 13 October 2007 (BST)

  • No, you mustn't split the way. you can just select the nodes of the bridge/tunnel. The great advantage of this is the elimination of this mini-2-nodes-ways just for marking a bridge/tunnel. Great idea :) --Cbm 15:31, 6 June 2008 (UTC)
    • but if you only put nodes in the relation, you can't store the information which pair of nodes belong together, so it involves more processing when using the data. And (theoretically) a pair of nodes can be used by more than one way, so you might not be able to identify the correct one at all. Imho using nodes is not a good idea. If you really want to avoid splitting the way you probably should use Relations/Proposed/Segmented Tag as a member. But just splitting the way seems a much simpler solution to me. I don't really see the great advantage we get by eliminating this. If you worry about the duplication of data that imho can be solved better with Relations/Proposed/Collected_Ways. pebe 09:10, 10 July 2008 (UTC)
    • http://informationfreeway.org/?lat=50.805049961764865&lon=6.098474773674037&zoom=13&layers=B000F000F I tried this proposal at the motorway from the border to the motorway-cross. A pity the renderer don't use it, yet--Cbm 19:59, 15 June 2008 (UTC)
    • But in the proposal the elements are ways, not nodes. Did I miss something? --1248 01:22, 12 December 2009 (UTC)


  • No, it means that method can still be used in preference to the relation form because it is simple and effective: most bridges still carry a single road/railway and can be nominal. But yes, I still anticipate the way would be split as it passes over a bridge represented by a relation (and, re the below, the length comes from that way). You wouldn't necessarily need to tag it though as he relation provides all the necessary information; however I can see renderers needing a little help, so layer information may still be needed in the medium term.David.earl 17:18, 18 October 2007 (BST)

How would you derive the length of the bridge? Generating a second short way using the same nodes as the long way doesn't seem to make too much sense either. After splitting you could use a "superway"-relation to create one large entity from your way-fragments. For the simple case it might however be useful to be able to specify just two nodes on the "across"-way as being the edges. --Tomz 16:51, 13 October 2007 (BST)

  • but then you might as well do it more simply and easily using the old non-relation method. David.earl 17:18, 18 October 2007 (BST)
  • Yes, I'd have thought to create an additional pseudo way (I'd call an "extend" or "element" or "object") representing a special feature of the actual way. But the "superway"-solution is also fine (that's probably what I want). --Keichwa 18:17, 13 October 2007 (BST)

Could you use a relation to name all segments of a road as one? <--road--+--tunnel--+--road--> --Nickvet419 05:36, 2 November 2008 (UTC)

  • nevermind, that would be a Collected Ways relation.--Nickvet419 05:40, 2 November 2008 (UTC)

Renderer support?

Did anyone already take a look at how the renderers will be able to support this? --Tomz 16:51, 13 October 2007 (BST)

  • without dealing with the detailed implementation, this was one of the factors I was thinking about. Obviously, the non-relation version would remain the same; the area version would render as an area I expect, possibly without reference to the relation itself, which merely groups the structure together with the ways it carries and crosses, and the edge version would have the edges rendered much as osmarender artificially does now. David.earl 17:11, 18 October 2007 (BST)

Role "under"

What's the purpose of adding the ways going under a bridge to the relation? --Eimai 15:39, 14 May 2008 (UTC)

For determining the extent of the bridge automatically. -- Eckhart 17:54, 29 June 2008 (UTC)
It also adds semantics to the map data. Layer is sufficient for rendering but not for semantic queries to the OSM data. I don't know how much people think about semantics, the most I know don't. But I think this will become an important aspect of the whole project in the future. This means modeling should move away from pure rendering requirements more and more. Example for such a query: "What is the minimum available height of all bridges that this way crosses (under)?" --FrankT 11:57, 18 July 2008 (UTC)
I'm not sure, how useful this would be for my needs, or if I would use it, but apart from that I think it should be possible to mark areas (such as parking lots) as members of the role under in this relation. Actually they also can be located under a bridge. --Hantilles 14:33, 28 July 2008 (UTC)
The question that somebody might ask to the routing software: What is the fastest / shortest way to destination that can be used by a vehicle of 3,60m height? The standard height of brindges in Germany that are not marked with any sign is 4,00m. --Lulu-Ann 12:20, 29 July 2008 (UTC)
very cool aspect. so role=under should not be underestimated --Cbm 14:26, 29 July 2008 (UTC)

Using this proposal

I tried to use this Proposal. Finally I use the following procedure for a bridge:

  • create a relation with type=bridge
  • mark the nodes of the way where the bridge should start/end and make them to relation-members with role=across
  • optionally mark the ways (not the nodes) under the bridge and add them to the relation with role=under. Normally this should not be needed (maybe for "bridge under bridge" construction to set which one is on top)--Cbm 23:32, 16 June 2008 (UTC)


same for a tunnel:

  • create a relation with type=tunnel
  • mark the nodes of the way where the tunnel should start/end and make them to relation-members with role=through
These examples are not correct, because across role should contain ways but not nodes. Edinorog 13:27, 4 July 2008 (UTC)
  • it's a proposal. I think we should add that nodes could be members.--Cbm 15:46, 4 July 2008 (UTC)
  • I think, ways are much more intuitive then nodes. Nodes should only be used if there are things like bus_stops, benches, telephones, etc. on the bridge. I also suggest only to put the parts of the under-way in the relation, that physically go under the bridge and therefore split these ways. Otherwise, we would have difficulties to tell whether a car will pass this bridge on his route, if there would be junctions before the bridge on this way. --JojoK 20:46, 15 June 2009 (UTC)


I used this Proposal. It works out quite well, but then I got stuck. I had some stairs and also a ramp leading from layer=-1 onto the bridge.

  • need some role for inclining/declining ways.--Skyper 19:33, 17 August 2009 (UTC)

Using Segmented_Tag proposal instead

http://wiki.openstreetmap.org/index.php/Relations/Proposed/Segmented_Tag

thats it...


Even if segmenteg_tags is much more flexible I prefer this proposal for tunnels and bridges, because layer=* IMHO is only for rendering issues and do not to describe anything in reality. Roles like across/through/under does much more and more clear! --Cbm 11:56, 18 June 2008 (UTC)

There's another issue with segmented_tag: You cannot tell whether two ways with bridge=yes are in fact the same bridge. -- Eckhart 17:56, 29 June 2008 (UTC)
To Cbm: from the "layer" key page, "Do not use this tag to correct some render behavior as in just to make the output look better. This tag should only be used for height differences that are real, like bridges over a street or tunnel under another object. " I take that to mean the layer key is semantic as much as it is presentational. Therefore it should not be dropped in favor of over/under, especially when there are stacks of bridges. Anyway, the Segmented_Tag proposal sounds good except I don't see how it would address describing some funny-shaped bridges or grouping multiple ways onto a single physical bridge. Vid the Kid 15:34, 24 December 2008 (UTC)

through members

Do we need both "through" and "under", or is "under" enough? -- Eckhart 17:57, 29 June 2008 (UTC)

  • we need both. "through" for tunnels, "under" for bridges.--Cbm 10:02, 30 June 2008 (UTC)
    • My question was whether there is a need for both roles, as they seem to convey identical information. -- Eckhart 10:26, 30 June 2008 (UTC)
      • it's more for linguistical than logical matters. A tunnel is "through" something. But something is "under" a bridge an the bridge is "across" something. To keep it intuitive I think we should keep all 3 options. --Cbm 13:08, 18 July 2008 (UTC)
        • By the same logic then you should have "over" for ways that pass over tunnels - I can also show you examples of tunnels that pass over/under themself (it is a tunnel that spirals down to get sufficient depth before heading under the sea) --Pshipley 11:13, 11 August 2008 (UTC)
          • In the case of tunnels, I would support some kind of member that identifies the principal obstacle that the tunnel is meant to go through or under. I'm not sure if "over" is linguistically correct, though. Anyway, adding every way that happens to be above the tunnel as "over" members doesn't seem useful to me except to satisfy Pshipley's apparent requirement that tunnels be semantically very similar to bridges. (I can see how that makes logical sense, but there's a practical difference. Often a way that goes "under" a bridge is practically affected by the bridge somehow, such as clearance issues. It can also help identify the bridge, such as "The I-70 bridge over Sullivant Ave". But if a mountain road passes over a freeway tunnel just because the freeway bores through the mountain that the road is on, I don't see how the tunnel or the mountain road are directly related. Neither one really cares about the other's existence. On the other hand, the mountain itself could be identified as an "over" or "above" or "across" member of the tunnel relation, since that's the principal reason for the tunnel's existence and possibly a key identifying factor of the tunnel. Then again, I think tunnels are more likely to have names to identify them...) Vid the Kid 15:57, 24 December 2008 (UTC)
            • maybe "trans" is the solution which works for bridges(across) and tunnels(through) --Skyper 14:47. 19 August 2009 (UTC)

I think that the under/over issue has not been well analysed in the discusions that I have seen so far. Sorry to say it like that, but I hope that I can make amends by adding my grain of sand to the pyramid:

  • By default, with roles left as [null] this means:
    • for "type=tunnel" => "role=through"
    • for "type=bridge" => "role=across"
  • In other words the default role, variously named as "through" or "across", as the case may be - this always means somthing like "included" (by), "within" or "inside" - the said tunnel or bridge.
  • I believe it better to set this roles specifically, not leave as [null] so as to "benefit" from a default role value, as I mention below in the discussion on Across=default.
  • Other "members", being "outside" the said tunnel/bridge:
    • for "type=tunnel" => "role=over"
    • for "type=bridge" => "role=under"
  • The fact that these roles have names of either "over" or "under" does not change the essential fact, which is that they are all "outside": whether that be above or below is (usually) trivial - at least when in the presence of only 1 tunnel/bridge at a time.
  • If, for example, Potlach 2 was enhanced so as to recognise relation "type=tunnel" and then propose auto-complete way role values of "through" & "over", and also recognise relation "type=bridge" and so propose instead auto-complete way role values of "edge", "across" & "under" - plus the role value "outline" for an area - then this would be a big help in getting such tunnel/bridge relations "up and running", well tagged, in user-freindly manner...

--Neil Dewhurst, Lyon France 13:13, 26 July 2012 (BST)

Bauwerksnummer

Giving a bridge or a tunnel a relation is a nice possibility to give this building a reference number like the "Bauwerksnummer" in Germany. -- Schusch 23:25, 29 October 2008 (UTC)

Aqueducts and Viaducts

bridge=* allows for varying types of bridges:

How should these be described when using a bridge relation? --Sward 14:35, 25 December 2008 (UTC)

How about just applying the bridge=* tag to the relation using the same values as are already defined? --Gregoryw 00:27, 26 December 2008 (UTC)

Toll and max*

Are toll, maxwidth, maxheight and maxweight actually properties of the bridge? IMO it are properties of the roads, not of the bridge. Currently, it is not defined if maxheight is when passing over or under the bridge, a bridge might impose both restrictions. Also, maxwidth is only specified when going over the bridge, but it might also have restrictions for travelling under it. When there is water under the bridge, it is quite common that there is toll to travel under the bridge, because the bridge should be opened, but no toll when traveling over it. Thus, IMO toll, maxwidth, maxheight and maxweight should be removed from the bridge relation. Besides that, using a relation for bridges looks good to me to group everything that's under and over it. --Steven te Brinke 15:04, 14 April 2009 (UTC)

I agree, that it is not clear. Maybe we can put the level to these tags (toll:-3=value for level -3 - or toll=-3:value or just toll-3=value) --Skyper 12:57, 16 September 2009 (UTC)
I agree, maxhight and toll should stay on the highway object, not on the bridge or tunnel relation. They are even vehicle dependent. Please remove. --Lulu-Ann 14:32, 3 June 2010 (UTC)

combined ways on bridge

Can this relation be used to guide rendering where multiple ways passes the same bridge? Examples I can think of is one bridge in Trondheim, Norway where a road, footway/cycleway and railway passes on the same bridge fundament, and in Guarapari, ES, Brazil where two oneway roads with a cycleway in the middle, and footways on each side passes over the same bridge fundament. At the moment, these are rendered as separate bridges, overlapping each other, and depending on direction of rendering/layers, partly or fully obscuring each other. At some zoom levels the bridge in Guarapari does not show the roads in Mapnik render, and the footways partly cover the road on other zoom levels, and on other again only the roads are shown. --Skippern 00:48, 20 August 2009 (UTC)

Give it a try, it already works like that in several renderers. --Lulu-Ann 16:06, 20 August 2009 (UTC)
Have given it a try, but both Mapnik and T@H don't show the bridge as one.--FFes 11:08, 31 August 2009 (UTC)

The reason for using the "bridge" relation is indeed to better handle exactly such examples as given above by Skippern. But it seems that rendering has never been implemented. Basically we are wasting our time - at the moment - by setting up "bridge" relations. However, if this is ever rendered fully, then lo-and-behold we should immediately see all those hard worked on bridges instantly rendered in very nice-looking fashion?! Please also note that a closed-way "area", as relation member with "role=outline", should perhaps be the common factor for all bridge relations - sizing & positioning of "highway" ways of all types is semi-symbolic: they precisely show interconnections of ways with varying access rights, and also relative positions in so far as the sequence of different ways going one side to the other - for example a 2x2 roadway with separate cyclepath & footpath on each side might not be mapped to-scale, as the cycle/foot ways would "collide" visually at even high zoom levels (when viewing, or when mapping), but rather as 5 ways with some not-to-scale spacing between them. --Neil Dewhurst, Lyon France 14:01, 26 July 2012 (BST)

bridge with more than one level

I think we need to distinguish the level of the ways a bit more. We should connect the role with the level. e.g. trans1(across1/through1), trans2, under-1 and under1 --Skyper 12:57, 16 September 2009 (UTC)

I'm pretty sure this is already handled with the way-level tag layer.
SixSix 00:20, 2 September 2011 (BST)

role for connection from one level to another

I have several bridges where a way with role under is connected with stairs or a ramp to a way with role trans(across). For me these ways are part of the relation. We need a role for these way!! May climb or connect.--Skyper 12:57, 16 September 2009 (UTC)

I understand your scenario, but I do not think that a new role is the answer. The fact that a way connects a tunnel and a bridge, i.e. is an "under"/"tunnel" role at one end and an "across"/"bridge" role at the other, can be implicitly determined via the tags on the ways that it connects.
SixSix 00:24, 2 September 2011 (BST)

maxheight

Would this apply to vehicles crossing on the bridge, or under the bridge? maxheight=* says it applies to "using the way to which the tag is added" - this no longer makes sense for a relation with multiple ways as members. I personally think (if anything) it should refer to "using the bridge" i.e. traveling on the bridge, and the proposal should be updated to specify this more clearly. Alternatively, to avoid ambiguity/misuse, it should be left out - I tend to think maxheight, maxweight and maxwidth should continue to be applied to ways, and not to a relation describing a bridge. -- Waldo000000 21:10, 21 September 2009 (UTC)

I agree that these tags are not well documented here and should probably be removed from the proposal. The "as per existing tag in Map_features" is clearly wrong, as the existing tag is used to define a restriction on the way that is affected by it (not the one causing it). --Tordanik 09:03, 24 September 2009 (UTC)
I agree that these tags won't work well on the relation - in particular, even on a simple bridge carrying a single way over a (different) single way, they may each need their own maxwidth (and possibly maxheight); this is compounded when multiple ways share a bridge or tunnel. These restrictions need to remain on their constituent ways. Plus, it makes a significant difference on how much relation-processing is needed by routing software. --tms13 13:59, 16 November 2009 (UTC)

Notes

I haven't seen this proposal progressed for a while; so here's a few more use-cases it needs to handle before going forward:

  1. When a canal crosses under, or over a railway, there is a ref= for the bridge with respect to the numbering system of the waterway and a ref= with respect to the numbering system of the railway (and these will be different). Something like over:ref= is required.
  2. British navigable canals tend to be "addressed" by a numerical bridge number, rather than a km distance; the number being attached to the physical structure passing over the canal---yet these still somehow need to be attached to the waterway (rather than the foot/road/way/waterway passing overhead).
  3. Tunnels have multiple tubes, a method should be allowed to combine these both lengthwise (to avoid tunnel portals in the middle of mountain where two ways join back-to-back), and laterally (eg. "The Channel Tunnel" is three-tubes).
  4. maxwidth=, maxheight=, maxlength are just as important for going under/through as going over; eg. the maximum craft size for the River Trent is defined by Newark Town Bridge, rather than the locks. Same applies to the Chester Canal, the restriction being a new motorway overbridge at Ellesmere Port. Additionally, beam on the North end of the Trent and Mersey Canal is restricted by the width of a new aqueduct (where the T&M canal crosses a river), not by the locks. maxlength= in turn is limited by the approach curve radius.
  5. The bridge having the ref= may not even be on the way in question; for example motorway or waterway bridges over/under the side turnings/access ways.

Sladen 07:00, 19 December 2009 (UTC)

the name problem

why can't we solve the name problem (street vs. bridge/tunnel name) with namespacing? e.g. bridge:name=foobar? I don't oppose the relation stuff (not at all, makes sense to me!) but I think we should have a simple and generic solution for simple issues. and since everything can have a name and in OSM we often have tags that describe an additional feature of an entity and both thinks (entity and the feature) can have different names (entity highway vs. the feature tunnel/bridge), we need some sort of generic approach to solve this. therefore I propose finding a better way to solve the name issue, like described above. I'm ok with the rest of the proposal. --Marc 12:09, 29 December 2009 (UTC)

You can use the name tag of the relation of the type bridge. --Lulu-Ann 11:46, 2 January 2010 (UTC)
Yes I know, thanks! Please see http://wiki.openstreetmap.org/wiki/Talk:Key:tunnel (bottom of the page) for the same problem and discussion that hopefully states my concerns more precisely. --Marc 12:08, 2 January 2010 (UTC)

The same for embankments

Hi,

I have added "embankment", because on embankments there can also be several ways (like a cycleway on both sides of a canal).

--Lulu-Ann 17:06, 16 May 2010 (UTC)

I'm removing it; an embankment is generally considered to be part of the ground level (on topographic maps, for instance). The only way an embankment would be relevant to this proposal is when there's a tunnel under one. --NE2 19:58, 17 May 2010 (UTC)
I think embankment and cutting would match to this proposed, because for example there can be a embankment on which are some different ways, so we can combine it on ONE embankment, instead each for each way. -- MasiMaster 00:30, 27 January 2012 (UTC)

Height and maxheight

I agree to uselessness of max* tags, since they should belong to road, not the bridge. But bridges have height itself, so I propose to add relation tag "height" (and remove max*). I have added the tag to the page --Zverik 05:51, 3 June 2010 (UTC)

What should be meant? height above sea level (eleveation) or height above ground --Langläufer 07:51, 30 August 2011 (BST).

Key:height never refers to absolute elevation, we have Key:ele for that. There's no reason why bridge relations should be different. --Tordanik 10:09, 30 August 2011 (BST)

Across=default

A few comments

  • I would just suggest that in "across" be considered the "default" role. So if there is a relation with 4 ways with no roles, they should all be assumed to be on top of the bridge.
  • I don't think "through" and "across" should be different roles. The role is essentially the same: a way that is parallel to/carried by/in the direction of the bridge/tunnel. Maybe neither role should be specified in fact.
  • I don't really understand why "under" is needed. But maybe it makes sense for some people.
  • Might be nice to make clear that having both the area and the edges does actually make sense. A sensible way to render the area would be make it semi-opaque. Stevage 06:11, 11 July 2011 (BST)
I agree, merge "across" and "through" into empty role. By the way, that role should also allow nodes and areas.
As for "under", well, it's something that's not needed as it's clear from the data without explicit tagging. I wouldn't have included that role and it could be removed, but it doesn't really hurt to have it listed either. It should be clear that adding "under" members is not necessary for that information to be properly represented, though. --Tordanik 07:57, 11 July 2011 (BST)
I agree with the proposal to depricate the across and through roles, given that the structure type is already specified by the way-level bridge, tunnel, and layer tags. A blank/null role can be interpreted as "see the way level tag to determine bridge/tunnel/layer/across/through status".
Coming to think of it, depricating across and through would obviate the need for my proposed link role (below), since, again, the way-level tags will indicate whether the way is ground level.
SixSix 00:17, 2 September 2011 (BST)
Since everybody here seems to agree on this, I'm going to merge "across" and "through" into default role soon.
--Tordanik 14:38, 1 April 2012 (BST)
Even with "across" as the default role for "bridge" relations, I believe that is still useful for mappers to explicity assign "across" as the role in those cases (roadway & paths on top of the bridge decking). And I have a practical reason for this: in Potlach 2, when selecting many ways (related to the same bridge, otherwise don't care of course) having for example roles "under" and [null] (and so default, same as "across") - then Potlach will show the cumulated role as "under" only. That is misleading, as the ways have different roles, its just that Potlack ignores [null] values, and does so without any intelligence regarding the implied default value. Of course you could say that its a Potlach bug, which could be true, but still does not change the fact that at the moment with current Potlach 2 version then specifically setting all roles is still useful!
Note that, in Potlach 2, selecting multiple ways where some are already members of the relation, plus others that are not (not yet) - perhaps you actually want to add them now, and so select at least one existing member so that the relavant relation is easily identified - then Potlach 2 will show only the "role" of the existing members. That is fine, logical, as there is no need to say "role=different" just because of non-members being also selected. But once they become members, with "role=[null]", then perhaps "role=different" should be shown as that is in fact true.
--Neil Dewhurst, Lyon France 12:24, 26 July 2012 (BST)

Proposal: "link" role

There are ways that, despite having a ground elevation of 0 (zero) and therefore are not technically bridge or tunnel structures themselves, belong in a "bridge" or "tunnel" relation because they are considered logical members of a larger bridge or tunnel facility.

For example, the Wikipedia:Chesapeake Bay Bridge-Tunnel, a facility that consists of multiple bridges and tunnels (relation Relation 1736039 (XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx)), has (relatively short) surface-level ways between its bridges and tunnels. These ways belong with the CBBT relation, but are not candidates for the "across" or "through" roles.

My proposed name for this role is "link", and the following is the proposed description:

Approach roadways, ramps, and other ways that have a ground elevation of 0 (zero) and are therefore not bridge or tunnel structures themselves, but should still be considered part of a larger bridge or tunnel facility, due to their role in transporting traffic to, from, or between bridges or tunnels within the facility; such ways typically, but not always, have an endpoint in common with a bridge or tunnel

SixSix 23:13, 1 September 2011 (BST)

By the way, I also considered using a blank/null role value for this purpose. However, I saw other proposals (such as the topic above this one) that suggest implicit meanings for blank/null roles, and figured that it was better to use an explicit role.
SixSix 23:58, 1 September 2011 (BST)

Proposal: "move" role

In additional to edge role, add role move (or some other name). This is the line where bridge/tunnel formaly starts/ends. With the edge ways it will be closed polygon. If we have many parralel ways over the bridge (footwalks + tram + highwyas) and they are the members with role across, we don't need to draw bridge outlines for each of them, just edges of the bridge and, maybe, some filling for entire bridge.

If we have large bridge system, we can use role move for connections between bridges.

Bridges.png

Dkiselev 05:52, 1 March 2012 (UTC)

bridge:higway tag

Like area:highway it will be useful for redering (fill color, etc) and for huge bridges/tunnels systems where we have different importance of bridges. Dkiselev 05:56, 1 March 2012 (UTC)

example?

Is there anywhere an example, where this already works???--LordOfMapping 14:56, 9 August 2012 (BST)

How to tag the outline way?

It's not clear from the proposal, how should the outline way be tagged? I've had a go at using the bridge relation (Relation 2412204 (XML, Potlatch2, iD, JOSM, history, analyze, manage, gpx)) and currently the outline way is just a blank way. Spark 10:49, 13 September 2012 (BST)

It doesn't need any tags, a blank way is fine. --Tordanik 12:21, 13 September 2012 (BST)
You can use man_made=bridge for that. De vries (talk) 07:06, 16 September 2014 (UTC)

Bridge type

I need a way to tag whatever bridge contains railway (other may want similar tag for roads, canals, footways etc). I would suggest railway=<any value other than "no"> to mark existence of railway on bridge and railway=no to mark lack of it. Bulwersator (talk) 20:11, 8 November 2013 (UTC)

That information is already available with the current proposal. Just look whether any of the "across" members of the bridge relation have a railway tag. --Tordanik 06:56, 9 November 2013 (UTC)


bridge=yes is not a bridge

I'd like to point out (and kindly ask to modify the proposal accordingly) that bridge=yes is not describing a bridge, it is an attribute describing that a way is running over a bridge. This is not the same thing. Up to now we still don't have a tag for bridges in widespread use (i.e. an object that is the outline of the bridge, where you attach the tag "name" and it is the name of the bridge).--Dieterdreist (talk) 20:08, 13 January 2014 (UTC)

Implicit layer discouraged?

The proposal to have an implicit layer=1 was voted down long ago for simple bridges, so per extension I think it should not be considered optional here. RicoZ (talk) 11:30, 8 March 2014 (UTC)

I agree, making layer semantics dependent on whether a bridge is mapped as a single way or a relation does not seem like a good idea. As there was no objection, I removed that line now. --Tordanik 14:39, 24 March 2014 (UTC)

Multiple outlines

Outline should say “optionally one or more” (or for consistency, “zero or more”).

Divided highway bridges often actually have two parallel spans, but a single name, and with lanes of a single named road crossing them.

There are disadvantages in treating them as two separate bridges:

  • You would have two map entities representing a single thing with a proper name (e.g., there is only one Fort Garry Bridge in Winnipeg, and search results shouldn’t make the searcher choose one of two).
  • Ways under a bridge would have to belong to two separate relations with the same name, unnecessary complicating the tagging.

 Michael Z. 2014-10-03 18:53 z

Relations under

How to tag relations passing under bridges?

For example, a hundred-kilometre-long river relation passes under a bridge. Should the relation be added to the bridge relation with role=under? Or, is it better to only add the local river’s centreline ways and/or boundary polygons? (I suspect one of the latter, because, e.g., river-craft height restrictions are significant in the local context.) Michael Z. 2014-10-03 19:04 z

The latter is three: ways, or polygons, or both (at least in many cases). I don’t know what considerations affect the choice. Michael Z. 2014-10-05 16:53 z