Proposal talk:Simplify man made=bridge mapping

bridge=* vs. bridge:type=* on man_made=bridge

Points for bridge=*:

• bridge=* means "this way has (also) bridge attributes". I don't think it will go away, it's an easy way to map small bridges, so the bridge=* key will remain.
• It was discussed briefly here.
• bridge=* on man_made=bridge would fit within the well established tag chaining in OSM.
• bridge:suspension usage is not always comparable to bridge:type. It is defining the spans, not the whole bridge. On Key:bridge#How_to_map is states that when the suspension type changes the way should be split. When micro-mapping a man_made=bridge, one should probably use sub areas (like building:part), optionally leaving out the abutments.
• bridge:movable=* should be renamed bridge:type:movable=* when bridge:type=movable is used.

Points for bridge:type=*

• It fits besides brige:suspension=* which is orthogonal to it.
• bridge=* on man_made=bridge might cause confusion because from current point of view it could mean: "the bridge is on a bridge".
• man_made=bridge is like bridge=yes, i.e. the type is unspecified. So man_made=bridge + bridge=yes would be nonsense.

Unclear:

• bridge=* describes some types of bridges, while bridge:support=* describes some other. So bridge=* or bridge:type=* would be optional on man_made=bridge. Bridge:type=* might be suggesting that has a value for every bridge.--Jojo4u (talk)

Note that Relations/Proposed/Bridges and Tunnels also should get a way to tag bridge types, I have added it as bridge:type for now.

The page man_made=bridge does include the bridge type since [2014: "The key bridge=* can be used on the outline to indicate the type of the bridge.". So I consider bridge=* on man_made=bridge to be documented and the case closed.--Jojo4u (talk) 11:54, 25 October 2015 (UTC)

Thanks for spotting that.. must have been blind. I assume the same method should be used for Relations/Proposed/Bridges_and_Tunnels as well? RicoZ (talk) 22:03, 28 October 2015 (UTC)

location=bridge

In the far future usage of location=bridge sound reasonable. One step earlier we could deprecate usage of everything else than bridge=yes of the bridge=* key for the way leading over the bridge when man_made=bridge is used.--Jojo4u (talk) 15:24, 4 September 2015 (UTC)

Implicit location=bridge

I don't think it's currently possible giving the schema of osm2pgsql that a way knows that it is inside a man_made=bridge. I asked a similar, even easier question, about nodes on ways on the forum.--Jojo4u (talk) 15:43, 4 September 2015 (UTC)

It would probably need a special SQL-query like http://postgis.net/docs/ST_Contains.html and then splitting! But none of some ST_* statements I searched could be found in the code of osm-carto. Only ST_Intersects is sometimes discussed in issues/pull requests. --Jojo4u (talk) 20:48, 4 September 2015 (UTC)

I am realistic about this - it may be some distant future or perhaps may happen somewhat sooner if the required changes to underlying technology become urgent for some other reason.

I think it is a good idea to draft this as early as possible so developers can keep that in mind, would be nice to have. Also I think not terribly much would break if a few data consumers can not deduce the location&layer tags implicitly. Routing would be affected only for routers that can't derive a bridge=movable - so far I am not aware of any that would evaluate it all. Rendering would be affected only where default layer order isn't sufficient - most bridges are over waterways and those would be "saved" by default layering. RicoZ (talk) 21:20, 4 September 2015 (UTC)

level key

Currently, the level key is discussed and used in the context of indoor mapping. As that field is only just emerging within OSM, I'm worried that giving a separate, different meaning to the level key will only add more difficulties. In particular, proposals such as the emerging Simple Indoor Tagging use the level key to determine that a feature is indoor (and thus might not be shown on default renderers). This is a very different behaviour from what is required for bridge levels, so different tags may be justified. --Tordanik 13:27, 4 November 2015 (UTC)

Is it necessary to interpret "level" as implying covered? key:indoor is for that and implying that "level" means covered would make it unnecessary complicated to map (and understand) a building where eg the 5th level is partly open space (terrace or similar). Whether or not indoor elements should be displayed depends more on the focus of the renderer: a renderer focused on road traffic will probably choose to display roads even if they are covered or indoor. RicoZ (talk) 23:11, 4 November 2015 (UTC)

Actually, in SIT, key:indoor is used for indoor elements such as corridors. There are also other indoor features, though (shops, benches, fountains, waste bins) that wouldn't use the indoor keys. It's of course true that renderers make different decisions regarding rendering, but I think we can agree that they need the "this thing is inside a building" information, and that they need the "this thing is on level x of a bridge" information. Probably they will do slightly different things with these two data points, so I don't see a problem with using more specific keys such as bridge_level. --Tordanik 12:54, 9 November 2015 (UTC)

Imho shops and benches would be considered inside/part of a building if they are within the area of the building and don't have a different layer than the building. No need to change the meaning of level to imply something is inside a building for this. The type of building/bridge might further specify what exactly the implications of level are. So far I see only advantages reusing the level key for bridges and even multilevel highways.

An area possibly needing some more elaboration is partially open buildings. Perhaps there should be some way marking features explicitly as covered=no? RicoZ (talk) 12:52, 13 November 2015 (UTC)

The criteria "within the area of the building and don't have a different layer than the building" are a lot harder to check for non-indoor renderers than "has level tag". This is a clear disadvantage. There would also be unnecessary complications when bridges pass above buildings. So there are definitely not only advantages of reusing the level key. --Tordanik 13:39, 13 November 2015 (UTC)

It is slightly harder to check the general case but the multi-level bridge case is easily distinguished from an ordinary building by "location=bridge". The check should be rarely useful anyway as far as I can see. Shops are considered indoor by default, whether or not they have any level assigned. Features like toilets or benches would be rendered mostly based on renderer priorities. If level would be used to decide how to render things it would be probably used to decide to render them only at higher zooms as the probability of cluttering the screen is higher.

In my opinion if there is any ambiguity it would be better to use indoor=yes, covered=yes/no or something to that effect instead of overloading the meaning of "level" to imply "covered and inside a building". Looks cleaner to me. RicoZ (talk) 18:42, 13 November 2015 (UTC)

As long as you accept that the concept of "level" refers to buildings (which is how it is currently used!), there's no "overloading" involved. And adding another tag to every single element in a building (when every single one already has a level tag) makes the already hard indoor mapping process even more laborious, and pointlessly so. --Tordanik 16:00, 14 November 2015 (UTC)

I think location=bridge makes it sufficiently easy to handle for all renderers and "level" inside buildings can be used as ever. Also in most cases there is very little reason to treat levels of a bridge differently than levels inside a building - the only exception is that the top-level of a bridge is not covered by default. This could be either mapped explicitly with covered=no or defined as a special property of the combination of location=bridge+level. I would not mind if renderers need some time to catch up with this. RicoZ (talk) 12:06, 24 November 2015 (UTC)

location and pipelines

Interesting proposal. There is one thing to watch out for: The tag location=* is already in use for pipelines. There is at least one example where a way and a pipeline use the same bridge, and the bridge has not been tagged with <man_made=bridge>, see http://www.openstreetmap.org/way/408296534 . If a renderer is confused by this ambiguous case, it should at least be designed to fail graciously (without crashing) when trying to find the corresponding <man_made=bridge> area ;-) --Biff (talk) 16:59, 19 May 2016 (UTC)

Sure, data consumers should not crash if one tag they were expecting is missing because otherwise they would crash rather often:) Pipelines use location but the the value location=bridge was not previously defined for pipelines, in your example I am thinking that a man_made=bridge would definitely be an improvement.RicoZ (talk) 19:38, 19 May 2016 (UTC)

Isn't there some overlap between locations for man_made=pipeline? A pipeline could be both location=bridge and location=overhead.--Jojo4u (talk) 20:58, 19 May 2016 (UTC)

Same problem for the imho poorly designed location=kiosk for power=substation. I think both of them can/should be corrected because using location for the more general terms (underground, underwater, roof, bridge) seems much more important.--Jojo4u (talk) 21:15, 19 May 2016 (UTC)

There is some overlap, don't see a big problem with the pipeline case - we have not needed location=overhead for bridges thus far so it is unlikely we would need the combination location=bridge+overhead in the future? However the power station certainly could be a problem as there can be power stations on bridges/in tunnels. The use of values like indoor/outdoor/kiosk for location is not good at all but it is fairly widely used.

At the moment I am unsure if and how to untangle this - even location=underground/overground/overhead is already inconsistent if you look close enough. Also, location=bridge/tunnel is not meant to be a cure for everything but just for moderately simple situations, relation=bridge/tunnel coming to the rescue in more complex situations. RicoZ (talk) 14:18, 20 May 2016 (UTC)

I thought about this: location should not be used generally (e.g. for features like waste_basket or a highway). There are too many nesting problems here:

• An object inside an underground stream is location=underwater;underground
• A bridge can be placed underwater and underground. A feature on it would be location=bridge;underwater/underground
• An antenna on a underwater building is location=underwater;rooftop

We should not try to cram all location values into one key. Just use underwater=yes, underground=yes, location:bridge=yes, location:tunnel=yes, location:overhead=yes, .... --Jojo4u (talk) 12:58, 29 September 2016 (UTC)

In many (most?) examples it seems to work as is, a waste basket on an underground bridge would have location=bridge and inherit location underground from the bridge.

Regarding your idea, do we need "underground=yes" even though there is location=underground? I surely could get used to "location:*=*". RicoZ (talk) 14:22, 2 October 2016 (UTC)