Proposal talk:Bridges and Tunnels

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

• create a relation with type=segmented_tag bridge/tunnel=yes layer=1-5
• mark the node(s) at the beginning of a bridge/tunnel with role=from
• mark the node(s) at the end of a bridge/tunnel with role=to

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:

• bridge=aqueduct
• bridge=viaduct
• bridge=swing

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)

An embankment relation would be useful, for representing that multiple ways/etc. share one embankment; this is the case, for example, near Pittsburgh, where 2 of the 4 tracks which were part of the Pittsburgh Line subdivision on the Pennsylvania Railroad mainline were made into the East Busway. In the areas where the railroad tracks were placed upon an elevated embankment (in Wilkinsburg), they both share the embankment. :-) --Abbafei (talk) 01:27, 16 February 2015 (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 1736039 1736039), 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.

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 (2412204 2412204) 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)

This comment is really the crux of the problem and its solution, in my opinion. --Hubne (talk) 11:46, 20 April 2016 (UTC)

The comment I read further down by User:RicoZ brings my attention to man_made=bridge, which seems to fulfil this role and enjoys Mapnik support as a bonus. --Hubne (talk) 12:09, 20 April 2016 (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

• Obviously the latter one Mateusz Konieczny (talk) 12:58, 5 October 2014 (UTC)

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

Add member roles for other objects in/on tunnels/bridges

Normally both tunnel and bridge should apply only to ways and there is no way to represent something like a waste basket or bench inside a tunnel or on a bridge next to a way.

I think such objects could be nicely represented with this relation with members like "inside" (tunnel) or "on" (bridge). RicoZ (talk) 12:50, 8 June 2015 (UTC)

I agree that we want to express that some basket/bench/... is on a bridge or in a tunnel. Ideally, we should try to find a solution that also works with just man_made=bridge, though. Perhaps layers on these objects would be enough? --Tordanik 13:11, 8 June 2015 (UTC)

It makes sense to assume that points with layer=X which are within an area (man_made=bridge) with the same layer are indeed part of the area but without additional help that might be rather difficult for software that would try to evaluate it. It could also turn out to become a mess for more complicated objects.

Also there is the rule (in key:layer) "With some exceptions, layer=* on ways should be used only in combination with one of tunnel=*, bridge=*, highway=steps, highway=elevator, covered=* or indoor=yes. For areas, it could be used in combination with tags such as man_made=bridge, building=* and similar."

The benefit of the rule is to allow very simple checks for wrong layer/bridge/tunnel tags, so assuming the rule can be extended without making it completely useless that should work. Should the objects on the bridge generally have a bridge=yes? RicoZ (talk) 15:21, 8 June 2015 (UTC)

I have created Proposed features/Simplify man made=bridge mapping which munges this together with another idea that I wanted to propose since some time. RicoZ (talk) 12:17, 9 June 2015 (UTC)

Hm, that would certainly be a solution for objects on bridges. However, it seems a bit odd to introduce bridge=yes + layer for objects on the bridge, and removing it from highways etc. at the same time. Surely a highway is also an object on the bridge? --Tordanik 12:57, 9 June 2015 (UTC)

Yes, that is true. It is really two proposals in one and maybe I should split them so things don't get lost or misunderstood. For the ways I want to remove the layer&bridge attributes because they can be deduced from man_made=bridge.

For other objects on bridges that do not share any nodes with the area or one of the ways the layer is obviously necessary to make it deducible that the object is on the bridge and adding bridge=yes would help double checking this and data consistency. I am not decided yet whether it should be bridge=yes or on_bridge=yes ? RicoZ (talk) 13:59, 9 June 2015 (UTC)

Don't forget that changing attribute might force highways to be split inside the bridge area, though. In that case there could be pieces of the highway with no shared nodes with the bridge outline.

Was already thinking on that, in principle graph analysis could still do it but I suspect it will be more robust to specify that such cases should continue to be tagged the old way.

The question what the tag for objects on bridges should be is something I'm not yet sure myself. I also wonder if it could be worth considering objects on rooftops (e.g. in the context of rooftop parking or rooftop gardens) at the same time as objects on bridges. To me, these seem like very similar problems. --Tordanik 16:00, 9 June 2015 (UTC)

I have seen location={roof,rooftop} used many times so I was also thinking about location=bridge. RicoZ (talk) 11:02, 10 June 2015 (UTC)

Looks much better to me with location=bridge, gives a few more benefits. RicoZ (talk) 11:34, 11 June 2015 (UTC)

Clarify member role "under"

I would suggest to clarify that this is optional and does not obviate the use of key:layer . RicoZ (talk) 10:57, 18 June 2015 (UTC)

I would suggest to remove the role "under" entirely. For any imaginable usecase, you would have to support layer-based "under" anyway and cannot rely on the relation membership. --Tordanik 11:29, 18 June 2015 (UTC)

Bridge subtype

Noticed that - like man_made=bridge - there is no way to specify which type of bridge( movable, aqueduct, trestle..) the relation applies to. Since the attribute "type" is already taken (bridge or tunnel), what would be the next best? RicoZ (talk) 14:01, 17 August 2015 (UTC)

bridge:movable

How is bridge:movable supposed to be used?

According to the documentation for Key:bridge, only the movable section of a bridge must be mapped as movable. Fixed ramps up to the moving bridge will not be mapped as movable, but they are still in the same bridge. Moreover, it is theoretically possible that a bridge can be opened in several places with different techniques.

I do not believe that the bridge:movable belongs in this relationship, it is more a characteristic of a section of the bridge.

This should refer to the "overall" bridge type, just like with Relation:waterway where you also need to decide on one type out of stream/river/canal even if the waterway has many sections with different types. Some other attributes may also be valid only for some points or sections of the bridge such as layer, height.

If there is no reasonable "overall" type it should be left empty.RicoZ (talk) 13:57, 20 August 2015 (UTC)

tag member outline with man_made=bridge ?

Would seem tempting as man_made=bridge will likely have support by more renderers in the near future., any thoughts? RicoZ (talk) 14:12, 5 October 2015 (UTC)

I don't think tagging the outline member as man_made=bridge causes any issues. Of course, it also needs the correct layer tags – otherwise it would produce incorrect results in applications that support man_made=bridge but not bridge relations. --Tordanik 14:10, 5 May 2018 (UTC)

I agree - I tag the bridge outline with man_made=bridge, bridge:structure=, name= (if applicable), layer= and then build detail with other applicable tags before wrapping it in the relation with additional features such as guardrails/parapets and the way sections crossing over and under the bridge. Renders completely on openstreetmap.org and doesn't trip JOSM or Keep Right validators. --John Grubb (talk) 05:50, 21 May 2018 (UTC)

Some Observations On Bridge Relations

Greetings, fellow mappers.

Firstly, apologies if I have gone about this the wrong way and messed up the discussion flow or anything. It's my first attempt editing/contributing to a Wiki and I'm on a learning curve. If I should be adding to an existing topic perhaps someone with moderator privileges can merge this into the correct section? I signed up to specifically comment on this proposal because I like it so much and would like to see it go through to approval.

I have been experimenting with bridge relations in areas I am contributing to in the map since finding this proposal and the following observations in no particular order spring to mind, having used it in anger (some points of which may be reinforcement of those already made earlier in the discussion):-

1) It's an excellent idea in my opinion, particularly for bridges where more than one way crosses the same bridge deck or one bridge has two decks, such as the new Severn Crossing bridge between England and Wales in the UK. To be able to collate the bridge deck (outline), all the roads, paths, railways, etc. that cross it, the guard rails, signage and so on in one block, as it were, is very useful.

2) Waterways passing under a bridge outline are masked by the outline. Roads, railways and paths are not, so even with the outline on layer 0 and the passing-under way on default layer 0, the "under" way appears to cross over the bridge outline (representing the bridge deck, say) but under the road or railway actually crossing on the bridge. I have got around this to an extent by tagging the way segment passing under the bridge with covered=yes, which of course it is, as well as making it the "under" member in the relation and it looks "natural" on wide bridges such as motorway fly-overs but a little contrived where the bridge is narrow. Okay, we don't map to the renderer but if the point of your micro-mapping effort is to produce an image for a presentation as well as expand the OSM database then - well... I don't consider it sensible to treat byways the same as waterways and mask them out as it would have implications for, amongst other things, satnav apps that use OSM. Perhaps this issue could be addressed by tweaks to the render engine to render ways tagged as covered=yes that are also "under" members in a bridge relation in a feint colour as at present but without the "tunnel mouth" effect at each end? For tunnels I think it is okay as rendered and gives a good symbolic representation. *I note on coming back to the proposal page since last looking it up that "under" is now struck out.

3) The proposal page lists "on_bridge" as a member. However, having just micro-mapped some historic railway bridges near where I live to include the height restriction roadsigns fixed to the bridge guardrails the JOSM validator reported that "on_bridge" was not found in the relation template. This could do with fixing or adding to the template ASAP as, whilst such furniture as signs, etc. is technically on the edge of the bridge, the "edge" member is defined for non-node features (according to the validator), and fits its assigned purpose as-is. "On-bridge" is a very useful and flexible membership for when "across" and "under" are not suited or specifically exclusive.

4) Guardrails/walls - is the intent that they are "across" or "edge" members...?

5) Mapping bridges more fully than just a way with "bridge=yes" and "layer=1" to include the actual footprint of the bridge is a much better way of doing it, especially where the bridge is large/wide and there are multiple ways crossing. Tagging ways crossing the bridge with "location=bridge" instead of "bridge=yes" and wrapping them in a relation seems more logical, too. Also, the relation tags allow the collation of a considerable amount of additional detail and information about the feature.

6) Take a basic example: a road and a cycle path cross a stream on the same bridge structure. Using the "basic" method it looks like there are two parallel bridges. Defining the outline and building the road, the path and the bridge extents into one package (the relation) makes it clear that there is one physical structure.

7) "Under." I can see the arguments made against it but it is a useful member if used correctly. Given that basic mappers will probably continue with "bridge=yes" on their ways and the more enthusiastic and seasoned mapper will look up the advanced stuff on the Wiki and follow it, as long as the description in the Wiki page is absolutely clear on where and when it is used I can't see why it shouldn't remain in the template. A way designated as member "under" in the relation could be used to trigger a specific feature rendering (see 2) above).

8) The relationship also allows to have the name of the bridge where it is different from the name of the way on the bridge and, as a bonus, for it to show on the rendered map. With basic "bridge=yes" bridges on ways you can store the name of the road in "name=" and the name of the bridge in "bridge:name=" but to access the info you need to know what you're doing with Maperitive or code or whathaveyou which may be inconvenient for the casual user who just wants to look something up on a map whilst out and about.

9) (Edit: Later-added comment but seemed inappropriate to start a new section for it) A bridge outline, regardless of layer setting, seems to render under all ways except waterways - suggesting that the crossed ways and crossing ways both go over the bridge, rather than one way under it and the crossing way over it. This example illustrates - the two thick ways of the motorway in reality pass beneath the bridge and the dashed footpath way is carried over the motorway by the bridge:-

Compare with this flyover, which is wide enough for the "covered" tag on the beneath way to show a clarifying effect:-

And these two bridge relation outlines over water, where the water beneath the bridge is "hidden:-"

Should the render of a bridge outline not cover "land" ways in the way that it does waterways?

Apologies for the untidy image insertion - haven't quite mastered the formatting malarkey on here yet. --John Grubb (talk) 02:51, 13 February 2019 (UTC)(End edit)

All in all, I think the proposal is a good idea, albeit with a few tweaks identified in this discussion.

Some examples to illustrate some of the above points:-

[[1]] Two ways on one bridge - as a relation with "location=bridge" instead of "bridge=yes" and with the outline it is clear that a road and a cycle path cross one physical bridge. Also, how the outline masks the waterway flowing beneath the bridge.

[[2]] A large motorway bridge as part of an interchange - the outline does not mask the way passing under the bridge. However, use of "covered=yes" on that way makes it clear what the layout is. The bridge footprint is sufficiently large to keep it neat, too.

[[3]] A small bridge on the historic West Somerset Railway, showing how the "tunnel mouth" rendering effect for "covered=yes" makes things a bit messy and unclear on small bridges. Also how it can become unclear which way crosses which.

[[4]] The same bridge seen in JOSM, showing micro-mapped detail of guardrails, attached roadsigns, etc.

--John Grubb (talk) 02:24, 21 May 2018 (UTC)

I'm preferring the area-approach: draw an area for the bridge and tag with man_made=bridge. No need for any relation (unless you have disjoint areas or want to reuse existing geometry, in which case you can use multipolygons). You can add everything referring to the bridge to this object, e.g. name, architect, wikidata, etc., here's an example: [5] --Dieterdreist (talk) 12:35, 21 May 2018 (UTC)

I don't disagree that bridges (and tunnels) can be micro-mapped to the extent shown in both our examples without the need for a relation. It just seems tidier to group it all "under one roof," so to speak, by wrapping it up in a relation. Both methods work equally well in their own right and could feasibly have equal footing and run side-by-side, I suppose, but I can see that that could open up issues in the future. Ultimately it is better to have one method of doing something that everyone uses consistently, I guess. Well; there it is! You've sowed a little seed of doubt for me now! :D --John Grubb (talk) 20:20, 21 May 2018 (UTC)

Having slept on it somewhat I'm coming round to siding with the arguments against the "under" member. Before wrapping my bridges into the relation all the bridge features - outline, way, guardrails, furniture, etc. get a layer=1 tag with the way passing under being left bereft of a layer tag altogether (i.e. it's left on default layer 0). However, as the relation carries a layer=1 tag then I'm presuming that the "under" way picks up the layer 1 status when it is in the relation with the other layer 1 elements, which is clearly incorrect. It is on a layer below the bridge features as it passes under the bridge and needs to stay there. The way under the bridge needs to be left out of the relation on that basis, which makes the "under" member redundant as it'd never be used. --John Grubb (talk) 05:59, 4 June 2018 (UTC)

A Case For Role "Under"

I may have misunderstood the intent of role "under" here but on mapping an old stone bridge with buttressed abutments I found a use for "under," insofar as the abutments that support the bridge are "under" the bridge deck outline. There are a lot of old stone and brick bridges around Europe (and the rest of the world!) where micro-mapping would involve tracing the prominent abutments and other supports, where indicating that they go "under" the bridge would be a useful clarification. --John Grubb (talk) 04:57, 17 January 2019 (UTC)

That is most likely the wrong way to do it, have a look at Bridge3D. I believe that complex bridges should be handled much like buildings and borrow as much as possible from Simple 3D buildings and Simple Indoor Tagging. RicoZ (talk) 19:13, 23 January 2019 (UTC)

Is there still any need at all for this relation?

Done this edit - and don't see anything left that could not be done easier by some other method. What are those "complex cases where the simple bridge as way or man_made=bridge area models are not deemed sufficient" ? RicoZ (talk) 19:29, 23 January 2019 (UTC)

I think that a relation might be useful for complex bridges/tunnels that can not be mapped with a single man_made=bridge/tunnel area. One example might be a tunnel that actually consists of two or more parallel tunnels that need to be grouped. However, to appropriately cover such cases a slightly different definition of the relation might be needed. --Biff (talk) 22:00, 23 January 2019 (UTC)

Fully agree. Wondering.. if it is only for grouping and sharing common attributes like name isn't there some "generic" relation type that could be used for that? RicoZ (talk) 20:04, 31 January 2019 (UTC)

Well, maybe a simple multipolygon is sufficient? --Biff (talk) 22:00, 31 January 2019 (UTC)

Would like to see more opinions on this. Technically it would work but the first sentence of multipolygon says "Relations of type multipolygon are used to represent complex areas." I think two parallel bridges are not one "complex area" but really two things sharing some attributes. Also, multipolygons are already source of enough troubles..RicoZ (talk) 22:53, 1 February 2019 (UTC)

Two parallel bridges should definitely be mapped using two man_made=bridge areas imo. I don't think it would be unacceptable to use a multipolygon relation to map the "bridge group" (or however you want to call it), as long as that multipolygon relation is not iself tagged man_made=bridge, but I could also see a specific relation type being used for this purpose. --Tordanik 13:39, 2 February 2019 (UTC)

One possible limitation of man_made=bridge areas affects the goal to "allow the possibility to mark arbitrary objects as being on a bridge/in a tunnel". With areas, that only works as long as the objects are inside the bridge outline. A relation would be needed to mark objects next to the bridge outline as nevertheless being attached to the bridge.

I can't think of any good examples at the moment, so I'm not sure how relevant that is, but I imagine e.g. signs or other objects might be mounted on the side of the bridge. --Tordanik 16:42, 1 February 2019 (UTC)

I concur - I have mapped a few bridges as relations in which I have included max-height signs, street lamps and so on that are on the bridge within the relation - the signs in particular sit on the outline as nodes, rather than within it. However, this attracts the "on_bridge" role which throws a "role not in template" warning in JOSMs validator. Also, if we bin this proposal what of the existing bridge/tunnel relations? - will there be a need to dismantle the relations and re-map the bridges/tunnels with another method? --John Grubb (talk) 17:10, 1 February 2019 (UTC)

I think that signs etc on the outline of the bridge do not require a relation - they should work with man_made=bridge as well?

You can keep all existing relations though you might consider redoing them using some other method because it might work better and be rendered.

One thing that can be done with the relation which I am not sure how I would do with man_mad=bridge is the use of the "egde" member - you could do pretty micromapping of the bridge outline here.RicoZ (talk) 20:28, 1 February 2019 (UTC)

Objects on the outline do not require a relation in my opinion, but objects outside the outline would. And yes, the edge member has no direct equivalent with man_made=bridge. A sufficiently sophisticated data consumer can probably guess the edges based on which segments of the outline are, or aren't, intersected by or connected to the ways running on top of the bridge. --Tordanik 13:39, 2 February 2019 (UTC)

A sufficiently sophisticated data consumer can guess the edges, though micromapping edge with eg barrier=wall can be used to add additional detail which can't be guessed. But maybe that is getting into a level of detail where it would be better to develop Bridge3D. Alternatively I think it would be ok to map the man_made=bridge as multipolygon to allow some segments of the outline to have attributes such as barrier=wall?RicoZ (talk) 22:19, 2 February 2019 (UTC)

After some thinking I realized that the original proposal did not mention or in any way support "grouping" multiple bridges with this relation and it would be incompatible with the current description. So some minor micromapping aspects seems to be what is left of this relation. RicoZ (talk) 20:36, 18 February 2019 (UTC)

Proposal: "label" role

Normally a bridge's name is rendered in the center of the man_made=bridge area (which would be using "outline" role). This is not always the best place to render it. For example, if a bridge starts at the west bank of a river, goes across the river, then continues for the same distance past the east bank. The label would be rendered over the east bank instead of the center of the river. Instead of putting the label at the center of the outline, renderers could check if the bridge area is a member of a bridge relation with a node using the "label" role and render the label there, just like boundary relations. Tguen (talk) 06:56, 20 October 2020 (UTC)

just like with boundary relations label will be optimized for one specific renderer (different renderers needs label to be at a different location). It would end as a weak case of unwanted Tagging for the renderer like other label roles Mateusz Konieczny (talk) 07:28, 20 October 2020 (UTC)

The "tagging for the renderer" page says not to tag things incorrectly so that they are rendered in a particular way. There is nothing wrong with adding data to provide hints to the renderer. The label node is not the location that the label is required to be rendered. It is a suggestion that will be helpful in most circumstances, and the renderer is free to put the label elsewhere or not render it at all. Do you have another suggestion for how to deal with the situation described above? Tguen (talk) 02:41, 25 October 2020 (UTC)

"provide hints to the renderer" - for the specific renderer. Renderer showing info for boats would likely prefer to place label not over river to avoid collisions with detailed info there. In this specific case, personally I see no problem. Can you link such location? Mateusz Konieczny (talk) 23:37, 25 October 2020 (UTC)

It's not for a specific renderer, it's for a general purpose renderer. (This includes most that I'm aware of, e.g. Carto, Mapbox, Maps.me, Osmand, Magic Earth, etc.) Even a lot of specialized renderers like OpenCycleMap would likely render labels in the same place, if they choose to render them at all. The few that would render the label elsewhere are free to ignore the suggestion.

In Portland, Oregon, I originally mapped the bridges in multiple segments, with the name tag only on the part over the river to ensure the label is in the right place. I now know this should be changed, but I've been avoiding it because of the ugly rendering. https://www.openstreetmap.org/way/392707014 Tguen (talk) 04:48, 05 November 2020 (UTC)