special rendering for roads under man_made=bridge

[AllroadsNL]

When a man_made=bridge is drawn in with bridge=* people expect that the way underneath is going to be transparent with dashed outline. As width as the man_made=bridge is.
A of lot them use for the underneath way, cut way and set tunnel=yes, this is wrong.

A question asked from a render perspective.
There is a relation between the underneath going way and the man_made=bridge, this is the max height to drive under the bridge.
man_made=bridge layer=1 underneath going way no layer.
When the underneath going way is connected with the man_made=bridge, could this part of the way be transparent and with a dashed outline?

Or must the underneath going way be cut on these nodes?
I did this here as a example.

I expect between bridges a normal way rendering.
Note: That the bridge highway way is not connected to the underneath highway way.

From routing perspective: I could expect a call go over 100 meter under the viaduct.
This because the connection is made with the man_made=bridge on the nodes.

Is this kind of rendering possible?
Two nodes (end nodes) connected with a man_made=bridge, different layer, give a transparent dashed way.

[dieterdreist]

maybe a workaround like in other cases is required: split the way underneath and add covered=yes to the covered parts. This will very likely work (but is not very elegant, still, we use this mechanism for building passages (tunnel=building_passage), and other highways going under buildings (covered=yes)

[AllroadsNL]

In the past I once (see history of the way) used covered and then they advised me not to use it anymore because, it is wrong, only to use it, if there is a roof over the road.
tunnel=yes
Both tags does not say anything about going under a bridge or a aquaduct.
If someone searching the OSM database and want to find where the real tunnels are.
Overpass bridge near tunnel It is either a bridge or a tunnel.
They must not get the wrong elements. Quality of data.

Then the search started, not using these tags, how should it be done, to get the effect.
What side effects are negative or positive.

The question is, can it be done, from render perspective? The man_made connection, if this is allowed.
Not setting extra tags.

[dieterdreist]

sent from a phone

On 2. Nov 2018, at 13:14, AllroadsNL ***@***.***> wrote: then they advised me not to use it anymore because, it is wrong, only to use it, if there is a roof over the road. tunnel=yes

semantically I agree that tunnel =yes is wrong, but covered isn’t. It can be used for covered by anything not just buildings

[AllroadsNL]

but covered isn’t.

Key covered wiki
says:

Do NOT use this tag:

For objects in tunnels or passing under bridges where vertical ordering is established by layer=* in combination with a suitable tag such as bridge=* or tunnel=*.

We can not use covered!
That is why I search for other option in rendering method.

[dieterdreist]

Am Fr., 2. Nov. 2018 um 14:53 Uhr schrieb AllroadsNL < notifications@github.com>:

but covered isn’t. Key covered wiki <https://wiki.openstreetmap.org/wiki/Key:covered> says: Do NOT use this tag: For objects in tunnels or passing under bridges where vertical ordering is established by layer=* in combination with a suitable tag such as bridge=* or tunnel=*. We can not use covered! That is why I search for other option in rendering method.

Maybe adding paragraph this was a bit shortsighted. The original phrasing was:

When NOT to use:

- as a tunnel feature, since "covered=yes" is implied for tunnels. - on a highway passing under a bridge, where the path of the under-passing highway may be accurately assumed. - for entities that are buried in the earth or submerged in water. However, underground excavations, such as parking lots and reservoirs are appropriate. most interestingly, tagging for explicit "bridges" wasn't even introduced when this was written ;-)

[matkoniecz]

could this part of the way be transparent and with a dashed outline?

With rendering software used by this style - it may be possible but it is unreasonably hard to implement.

[matkoniecz]

We can not use covered!

Note that wiki is not a holy book. It's recommendations can be changed (and for me "covered by bridge" seems to be clearly correct case for covered=yes).

[matkoniecz]

I change the title to make clear that it is not duplicate of #3203

[AllroadsNL]

"Not the holy book" agree with that. A process of evaluation and changes.

Two things:

• May we, can we, use connected nodes, man_made=bridge layer=1 and the underneath highway no layer. This point is the exactly point of change. Where max height starts.

• What value to use for covered=*
  viaduct
  aqueduct
  ??? Is this right ???

Questions are tagging questions, should be discussed else, derived are the render issue.

covered=yes, not to render? I agree.
covered=viaduct, should be rendered? Could be.

Choices in rendering, makes people react, in this case a better quality of data. Which others can use in routing and rendering.

Over going way, viaduct.
I can assume, that where a man_made=bridge layer=1 and connected highway=* bridge=yes layer=1 is, that on the highway the outline of the way line is not rendered on some zoom levels, where the man_made=bridge is visible. To give the map a that spot a restful impression.
Rendering both, could be seen as overkill.

Connecting nodes give more render possibilities and avoid extra tagging.

The whole case in this topic is, how to use connecting nodes for better rendering possibilities
Good, that, you changed the title!

[jeisenbe]

Should we close this as wontfix? The ways of solving this would bring up more problems (using transparency), or excessive code complexity and slow performance (adding more layers), for a minor rendering improvement, and as mentioned above it's possible to tag the highways with covered=yes.

[dieterdreist]

If it is completely unpossible to fix it, then close, but these are really ugly. Btw: is covered=yes working for highway=pedestrian area=yes as well?
Example:
https://www.openstreetmap.org/#map=19/41.86057/12.47010

[AllroadsNL]

Should we close this as wontfix?

No, should be fixed.
Lately on a forum there was a discussion about setting maxheight on road, just the part under the bridge. The road should be cut where the man_made=bridge start, if there is no traffic_sign. (maybe connected nodes, like the building and the tunnel=building_passage)
The under bridge passage, new key with value?
Some find tunnel= not appropriate, how should a maxheight under bridge be called?

What I say maxheight is set, can we use that or must that be some (under_)bridge:maxheigt, this means it is covered. Some say covered= is not for bridges.

[jeisenbe]

The maxheight tag is meant to warn routers that the way is not passable for vehicles. It does not imply that there is a solid covering over the road. There might just be a gantry or overhead wires.

I believe covered=yes is reasonable for your use case, but if a new tag is needed it would be good to discuss on the tagging list or other forums.

is covered=yes working for highway=pedestrian area=yes`

I believe highway areas are not rendered if tagged with covered=yes.

[RicozOSM]

The strong expectation when man_made=bridge was approved was that tagging and rendering will be consistent with simple bridges so this should be fixed, everything else is rendering around renderer-bugs.

Regarding a hypothetical connection/relation of roads bellow bridges with the bridge itself this is a valid issue which has popped up several times and should be addressed for example in the tagging mailing list or wiki. In short, the current model where roads under bridges are completely independent/unconnected with the bridge is correct only in some situations (bridge high above valley) while pretty often the bridge and road(s) bellow it constitute a single complex multilevel structure and these situations could be in principle mapped somehow analogous to indoor mapping. However it is not clear at this point that "fixing" this would actually improve anything in practice while it would be certainly a gigantic effort.

[jeisenbe]

@RicozOSM or @AllroadsNL - do you have time to submit a PR to resolve this issue?

[matkoniecz]

expectation when man_made=bridge was approved was that

Well, it probably depends on a person. For me main motivation for involvement in this proposal was to give decent (not worse) alternative to using tagging for renderer with building=*.

[AllroadsNL]

time and knowledge is a issue for me.
I have other OSM projects that are still half finished and need my attention first.

And it is true, often this kind of implementation depends on a few, which control the deeper matter.
I am therefore full of admiration and respect for those who are so committed.
My contribution then mainly consists of feedback regarding Carto.

It is a choice of the code expert, what to do.

[RicozOSM]

@jeisenbe: sorry, don't even want to guess how long it would take me to implement this.. probably would be finished long after it becomes obsolete for other reasons.

if everyone thinks this is impossible or not worth the effort to implement correctly than maybe it is time to to abandon the feature and come up with something that is workable - otherwise it may be doing more harm than good. Who needs a feature that has no realistic prospect to work as expected???

Not only do people use all kinds of questionable workarounds which afaics have their own problems - but even worse - many would innocently consider man_made=bridge as a "good example" how to do things and we could end up with many more features designed similarly with even worse results. (I have been working on some proposals;)

I have prepared https://wiki.openstreetmap.org/wiki/User:RicoZ/Deprecate_man_made_bridge just in case...

@matkoniecz: an irony that you voted for this feature with the comment "I consider this to be a good tagging scheme for marking bridge areas, especially as format is easy to use by data consumers (for example in openstreetmap-carto style)"

[jeisenbe]

As @matkoniecz mentioned, the tag man_made=bridge is an analogy with building=yes, used to map the area of a structure - many were previously mapped as building=bridge until the new tag was created.

We currently rely on other tags like covered=yes or tunnel=* on ways that go through or under a building, so it's reasonable to expect this for ways that are under or through a man_made=bridge area, but as I mentioned, it would be nice to see code that makes it possible to determine this from tags like layer and intersecting geometries alone.

We could also consider using layer to render the man_made=bridge fill color above the roads that pass underneath, but this would block the lower roads from rendering in that area. That solution, and the problems it raises, are mentioned in #436, #1633, #1799, #2509 and #3203.

[matkoniecz]

@matkoniecz: an irony that you voted for this feature with the comment "I consider this to be a good tagging scheme for marking bridge areas, especially as format is easy to use by data consumers (for example in openstreetmap-carto style)"

See #1633 and https://wiki.openstreetmap.org/wiki/User_talk:RicoZ/Deprecate_man_made_bridge

And to make clear - making passive aggressive proposals ("Deprecate man_made=bridge because openstreetmap-carto developers say this is too difficult to render as expected.") is certainly not increasing chance that your favorite feature request will suddenly be implemented.

[mboeringa]

See #1633 and https://wiki.openstreetmap.org/wiki/User_talk:RicoZ/Deprecate_man_made_bridge

And to make clear - making passive aggressive proposals ("Deprecate man_made=bridge because openstreetmap-carto developers say this is too difficult to render as expected.") is certainly not increasing chance that your favorite feature request will suddenly be implemented.

@RicozOSM

I agree with @matkoniecz that this is totally counter-productive. I also object to your implicit assumption that if openstreetmap-carto isn't capable of rendering it properly, then the tagging scheme should be abandoned.

You are ignoring the fact that there are other consumers of OSM data, and other "non-carto" rendering frameworks. The one I personally developed based on ArcGIS, is capable of rendering stacked bridges, highways, railways and buildings properly, see the attached images with the top one being from my ArcGIS Renderer for OpenStreetMap.

However, the solution I personally choose, requires a great number of layers to be rendered to achieve this (one for each OSM layer=x value times the number of thematic layers, e.g. highways, railways, man_made=bridge etc., which means I have hundreds of layers in the ArcGIS Table of Contents).

As consequence, even my renderer, does not render all thematic OpenStreetMap layers according to OSM's layer=x but only a specific subset of thematic layers, and, while the solution is OK for rendering static high quality georeferenced PDFs where performance is much less of a concern (the main goal of my renderer), it is much less suited for a high performance dynamic web map or vector style map.

As such, I also fully appreciate the difficulties and doubts the openstreetmap-carto developers have related to tackling this specific issue, as any solution for carto needs to perform well, and this doesn't even consider the technical difficulties for implementing this in the style or SQL.

[RicozOSM]

@mboeringa: I very much appreciate your enlightened technical expertise, especially also here (#2509). I also know that there are many more problems to be solved.

But this is an important feature in my opinion and I consider calls to close the ticket and encourage mapping workarounds using "covered" or "tunnel" as unfortunate. Either man_made=bridge is the correct way to do things or it isn't.

@matkoniecz: I have long given up having any favorite feature and would not particularly care about Carto - except where mappers take Carto as an excuse to abandon good practice in favor of good rendering.

[jeisenbe]

Either man_made=bridge is the correct way to do things or it isn't

I think you mean: "Either man_made=bridge + layer and highway=I + layer on ways which cross over or under the bridge is the correct way..."

Just to be clear, both the use of layer= and the use of covered= require extra tags that are mainly useful for rendering, though they both provide some additional real-world information. The tag layer= lets you know what things are above or below other things in the real world, if you consider all the neighboring and overlapping features as a whole (since the layer=* value is relative, not absolute), and covered= lets you know if a way is covered by a roof, building, or bridge.

[jeisenbe]

As mentioned in #4555 we should close this since the fix is technically too hard for the small potential benefit.