From left to right there are six lanes, A to F. Obviously, lanes A and F are on the “ground level” and must not get embankment=yes. Also, obviously, lanes B and E are on embanked ground, and must get embankment=yes.
The question is on lanes C and D. They are at the center, between lanes B and E, are above the “ground level” of A&F, but are below the embanked ground of B&E. Should C&D get embankment=yes? How do we describe the difference of embankment between B&E and C&D?
Or, what if Lanes C and D are at the same level as lanes B and E? In this case, should C&D still get embankment=yes?
I currently hold the opinion C&D do not need embankment=yes because when C&D look at their immediate (closest) surroundings, they are indeed below B&E, and therefore C&D are not on any embankment, so there is no embankment to tag.
A related situation would be riverside embankments where a lot of roads and buildings are built on top of the embankment. Following the logic in the above paragraph, all those roads and buildings on riverside embankments should not need embankment=yes because their immediately observable surroundings are all at the same ground level.
The wiki only describes simple embankment situations with single roads that obviously are on embankment. What does the community think about these advanced multi-level cases?
IMHO, if A and F are the natural ground height, and B-E are on an embankment (on different heights) , B-E should get embankment=yes. AFAIK there is currently no way to distinguish different embankment heights, if not by stating the ground elevation (tag ele).
That is not what a user will see on the ground travelling one of the lanes C or D. Instead they will see that C and D are located in a cutting and I would tag that as cutting=left/right (whatever applies) to each way.
I’d say embankment/cutting should reflect what is directly beside a way, not what can be found in an unknown distance. Imagine B and E are not simply ways on a narrow embankment but some 100 or 200 meters wide. Which distance would you see as a limit to justify an embankment tag on C-D?
if I understood the OP correctly, the whole structure is an embankment, with different levels, so several parallel ways are all on the same embankment, for a cutting I would expect terrain to be cut, which doesn’t seem the case here.
I do not think distance plays a significant role, when it gets really large maybe it becomes a landfill ;-)
As long as you call it embankment it consists of the bordering slopes plus the flat parts on top
At close distances (e.g. by somehow traveling along lanes C and D), C and D are surrounded by embankment B&E, so C&D should not be getting embankment=yes. However, when we zoom it out, we realize B C D E all are on some embankment compared to A/F, so B C D E should all get embankment=yes.
We have incompatible and ambiguous reference frames here, so to speak (small frame C/D, and large frame A/F). I can’t strictly say which one of the two is wrong, because we are trying to discuss two separate topics using the same words. This is analogous to the “relativity” concept in physics where the perspective of the observer decides the local truth. But we need/prefer global truths in OSM.
To disambiguate the reference frames, well-accepted and mutually-agreed-upon rules have to be used. One way to do this is to use Occam’s Razor and take the smallest reference frame and closest neighbourhood; then, C/D must not get embankment=yes.
I’d say your example is a very edgy case so one should not overestimate it’s importance. If a mapper chooses to tag
C/D as cutting=yes,
or C as cutting=left and D as cutting=right
or C/D as embankment=yes
or does not add any of these tags at all
does not make the road impassable or unroutable in any way. As long as the main tags describing the road in detail are set, everything is fine. There will always be such cases and it does not make sense imo to try to nail down every exotic detail with specific tags.
The undescribed part of the problem is B,C,D,E are on the same level on both ends beyond this cross-section drawing. They are on the same raised structure. Here, C,D are kept on the same height, while B,E raises for an interchange. If C,D are claimed as not embanked, a paradox will be resulted where the same structure on the same level doesn’t get embankment=yes consistently.
If you use this argument, the interchange section is short compared to this long structure, and entire Highway. Then it should be kept as embankment=yes
I don’t see a problem there as we tag what is on the ground, not beyond. As long as lanes B-E are on the same level rised above ground one can tag the lot as embankmant=yes. Where B and E rise above the two others one can split the ways and leave C/D without an embankment tag following the ground truth within this section.
If this is a bridge=viaduct , all of them will be bridge=viaduct
This is the same structure that extends beyond this section. That’s the ground truth I see. As I asked above, this section is relatively short compared to the whole structure, and entire road.
Lack of embankment=yes suggests C,D are similar to A,F, which is not the case. There are flat tunnel= across them, that’s passing through the whole raised structure conceptually.
Besides, it could be argued B,E are on the same structure. Then C,D should be on the same structure by continuity.
But there’s exactly no height and structural difference along the main line for C,D?
If this is sunken or underground (B,E deeper than C,D), it will also be cutting=yes or tunnel=yes
I don’t see the difference in logic with them for embankment=yes
When I pass through the flat tunnels across them, I can realize C,D are above me. They are the same as B,E.
Why overcomplicate things when you could simply add a man_made=embankment to the right or left of the relevant sections?
As always, the content of the relevant wiki varies depending on the language. The German wiki states:
man_made=embankment is used to mark an embankment or slope. Normally, embankment=yes is used to mark a dam, but if several transport routes run along a dam or through a cutting, man_made=embankment is more suitable – you simply need to draw two separate lines for this.
man_made=embankment is used to map an artificial slope or steep incline built, for example, to provide a level platform on top for a road or railway line (see embankment) or to otherwise shape or stabilise the terrain. Such a structure can be built from compacted earth (often stabilised with grass or other plants) or from loose or set stones.
Wouldn’t the German interpretation be a good representation for this situation?
You are right, this would be the simplest solution in such a tricky constellation. Draw separate lines for the outer embankments along the whole structure and for the inner embankments (forming a cutting for C and D) as well. Just make sure to draw the lines in the correct direction to indicate the direction of the slope of inner embankments specially.
There’s a reason why I worded this as “multi-level embankment”. For example:
The thought is valid. However, note that bridges and tunnels have a very well-accepted auxiliary tag layer=* for this. With this as inspiration, another way out of this problem could be also giving embankment the use of layer=* but that’s of course not currently documented (and perhaps rare/exotic), so I should at the very least ask unaffiliated people on this forum how they feel about this.
The question originates from the removal of embankment=yes using the reason that man_made=embankment has been drawn. One of the rebuttals is bridge=yes are kept inside man_made=bridge area.
The German article reads as you can draw man_made=embankment instead of adding embankment=yes , but it doesn’t say whether you should remove the latter. Hence the debate remains. English has “instead of (only)”, meaning embankment=yes can be added or at least kept. embankment=yes was already added to the road along the entire raised structure. So removing it from this section in between seem inconsistent.
yes, embankment=yes is a property, man_made=embankment is a feature. The comparison with bridges is fine, there are many other features that are also often mapped as properties, e.g. bin=yes, atm=yes, etc.
