Proposal talk:Man made=bridge

Please add to the discussion using the Add Topic button above. Keep discussions succinct, try to stay on topic, and mark finished conversations with {{Resolved}} and related templates.

Tunnel as well?

Why not include man_made=tunnel with the same semantics into this proposal? --AMDmi3 (talk) 21:12, 12 March 2013 (UTC)

I thought about that initially, but there are many substantial differences between bridges and tunnels. We would need this tagging mainly for tunnels with more than one tube. But it is very hard to determine the "outline" of the tunnel. It is also not always clear if those multiple tubes are in fact one, single structure. Maybe they are connected somewhere (e.g. emergency connections), maybe they are not. Although I'm not really a fan of relations (obviously) I think that for tunnels it would be better to use a relation - if necessary. --Imagic (talk) 09:07, 13 March 2013 (UTC)

Tunnel's geometric properties and problems with mapping these must be out of this proposal's scope. The proposal finally gives (although I've actually used the same scheme 2 years ago) a way to map a bridge, and to map it as a single object, and the same should be possible for tunnels. The geometry of tunnel doesn't actually matter and there's nothing in it which is different from bridges - if it's two separate tubes, it can mapped as a multipolygon with two outer ways, tagged with man_made=tunnel, and it'd be the same as a bridges which multiple side-by-side decks (e.g like this, but single bridge). If there are service tunnels connecting tubes, there will be a multipolygon like this:

┣┫
┣┫
┣┫

but in many (most) cases there will be just a single closed way like with bridges. In either case, it'll be a single and geometric object, which is the most important. --AMDmi3 (talk) 04:26, 14 March 2013 (UTC)

One advantage would be that the name of the tunnel would be only assigned to the object tagged as man_made=tunnel, instead of assigning it to each individual tube. This would mean that a renderer would need to show it just once instead of multiple times (once for each tube). --Biff (talk) 07:55, 31 July 2013 (UTC)

Multi-level example

In the "Multiple ways, two levels" example, where cycleway is layer=1 and roads is layer=2 it is proposed to tag bridge outline with layer=1. Won't it be more correct to tag it with layer=2, as the outline belongs to roads mainly, and cycleway as I understand is somehow attached below it? --AMDmi3 (talk) 21:16, 12 March 2013 (UTC)

The problem with this is that there needs to be a clear rule to determine which ways belong to which outline, even when there are multiple bridges involved. Currently, the logic is that layers of the way are equal or greater than that of its bridge outline, but not equal or greater than that of any other bridge outline. --Tordanik 23:20, 12 March 2013 (UTC)

I agree with Tordanik. I also think that this is more intuitive. Even if the cycleway in the example is below the roads it is on the bridge and not below it. --Imagic (talk) 09:00, 13 March 2013 (UTC)

I may not quite understand the real structure of that bridge. I've imagined it to be something like this, in which case it's clear to me that the bridge should be layer=2 both because upper level is constructively the supporting structure (e.g. THE bridge), and because it's widest part and outline belongs to it geometrically, while a footway/cycleway is just attached below it at layer=1. In the less obvious cases, e.g. when there there's no dedicated supporting structure (like this) I'd agree that it makes sense to tag the bridge with the bottommost layer. --AMDmi3 (talk) 04:47, 14 March 2013 (UTC)

First of all we need one rule that applies in all situations, otherwise no data consumer could process the information correctly. In my opinion the one proposed is the best variant. It could be defined the other way around but to me this is very counter-intuitive. And secondly, keep level=* in mind. Theoretically (but not practically at the moment) we could even tag all the ways attached to the bridge with the same layer and differentiate further with level. --Imagic (talk) 11:40, 15 March 2013 (UTC)

The data can't be processed in an any sane manner unless you use ranged layer (e.g. layer=1-2) for the outline: in multi-level bridge, you'll either have "roads above the bridge", or "roads below the bridge". You can't reliably link roads with bridge without extra relation either. What's for level=*, it doesn't solve anything, as relative position of ways is only determined by layer=*. --AMDmi3 (talk) 12:51, 15 March 2013 (UTC)

Here's an example with multiple briges, which is probably not a common situation but might exist in some densely populated city: Two bridges A and B. Bridge A carries two roads R1 and R3 and bridge B carries one road R2. Bridge B passes through bridge A, below the upper way R3 of bridge A and above the lower way R1 of bridge A. So, the roads are stacked like this from bottom to top: R1, R2, R3. Of course, bridge B and R2 are both assigned layer=2, R1 is tagged layer=1, R3 is tagged layer=3. For me it is clear that a typical map needs to show a bird's eye view, and in this case bridge A needs to be drawn above bridge B, which would in result in tagging bridge A with layer=3. A compromise which might lead to a useful rule could be to tag bridge A with all appropriate layers: layer=1;3. This would clearly show that this is an intentional multi-layer bridge instead of a difficult to detect tagging error. --Biff (talk) 21:03, 30 July 2013 (UTC)

I would tend to support the use of level=* in this situation. If the current semantics isn't sufficient to define which way is above or bellow than this needs improving. RicoZ (talk) 11:01, 8 March 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)

I don't see any need for this. This tag "should be used to indicate the outline of a bridge and group together all features for that bridge", i.e. there are already ways representing roads/tracks/whatever and therefore it is already known if there is a railway or not. --Imagic (talk) 12:54, 13 November 2013 (UTC)

Multilevel example does not work like in the picture

The layer tags do not establish any vertical ordering of the ways except exactly in the point(s) where they cross. I think the relation could have a set of levels as members to fix this. Also in the example the cycleway is supposed to have the same layer as the man_made=bridge but does not appear to share any nodes with it?RicoZ (talk) 11:39, 8 March 2014 (UTC)

Use this for all bridges, i.e. also those with a single carriageway on them

I really appreciate this proposal because it finally introduces a simple bridge object (as opposed to more complicated bridge relations) in addition to the long established bridge attributes for ways on bridges (i.e. bridge=yes/*). In the first paragraph it is stated that this feature should not be used for simple bridges (with only one carriageway), but I'd rather encourage to use this for all bridges. A dedicated bridge object helps to put relevant additional information to the correct object, e.g. tags like wikipedia=*, start_date=* or even name=* and ref=* without having to introduce workarounds like bridge_name which are alternative tags for what is really the same thing (a name). --Dieterdreist (talk) 10:58, 1 September 2014 (UTC)

What paragraph do you refer to? The first example? If so: I would add to the example, that the bridge doesn't have any special name/reference/... and therefore there is no need to add a separate bridge object. I don't want to scare off people ;-) --Imagic (talk) 08:01, 2 September 2014 (UTC)

type of bridges ?

The proposition does not specify where we should put the tags when we want to be more precise about what bridge it is. Does using man_made=bridge + bridge=covered is ok or should we (also ?) put this on the supported ways ? sletuffe (talk) 23:51, 14 October 2014 (UTC)

• IMHO it would be best to place this tag both on bridge and its ways Mateusz Konieczny (talk) 06:10, 15 October 2014 (UTC)
• I think bridge=yes on the way over the bridge ought to be enough. man_made=bridge should get the details. Also see discussion here.--Jojo4u (talk) 15:26, 4 September 2015 (UTC)

droping bridge=* from ways alltogether ?

Since way(s) on a bridge can be calculated by the intersection (at common coordinates and level=*) could or should we add to the proposal that Adding bridge=yes on ways is optionnal if you tagged the bridge's outlines ? sletuffe (talk) 23:51, 14 October 2014 (UTC)

• No - vote already started. Also, calculating intersection is not trivial. Mateusz Konieczny (talk) 06:09, 15 October 2014 (UTC)
• No, that would completely break backwards compatibility. --Imagic (talk) 07:27, 15 October 2014 (UTC)
• yes - this should be an option for the future. Once man_made=bridge is well supported it would be a huge benefit if we could avoid splitting all ways in many parts to add bridge & level tags.RicoZ (talk) 14:18, 17 October 2014 (UTC)
  • This might be something to consider in the future. But then you would still have to split ways for width, surface, maxspeed, lanes, turn:lanes, sidewalk, cycleway, parking:lane and other tags. Splitting ways is a fact of life in OSM. --Tordanik 04:43, 18 October 2014 (UTC)

Even when there is enough other cases left where we still need to split ways I think this one special case is so common and the data bloat as well as amount of work substantial enough that it would be worth it. RicoZ (talk) 20:34, 18 October 2014 (UTC)

Glaring omission in the proposal - bridge type ?

Resolved

The proposal does not mention bridge types, in the relevant places (area man_mad=bridge, ways across the bridge) it mentions only bridge=yes. However there are other bridge types than "yes" and those should be attached to man_made=bridge somehow. Attaching the detailed bridge type to eg a pedestrian path across man_made=bridge but not to the bridge as a whole would be a step backward - one of the proclaimed goals of this proposal was to "to allow to group together all features of a one-level-bridge without the need of a relation".

So how to do that? Attaching bridge=anyvalue to an area man_made=bridge is possible but ugly. Using bridge:type=value to hold the value that would otherwise go into bridge=value would seem cleaner.

Stumbled upon this when doing Proposed features/Simplify man made=bridge mapping so whatever seems sensible could be added to that proposal. RicoZ (talk) 08:34, 3 August 2015 (UTC)

Let's discuss this further at the talk of your proposal.--Jojo4u (talk) 15:21, 4 September 2015 (UTC)

It is in the proposal: The key bridge=* can be used on the outline to indicate the type of the bridge. --Jojo4u (talk) 12:16, 25 October 2015 (UTC)