Mapping embankments

I did not talk about that - I just wanted to point out, that the meaning of the term embankment in real life can be used for the whole substructure of a raised trafficway or a dyke and at the same time for one of the artificially created slopes one one side or even part of such. That makes it difficult to use this term in OSM imho.

That is what most mappers do, other use this tag at the toe liine or may even place it in the middle of the slope. There is no explicit instruction in the wiki about this.

The wiki says to draw the line so that the downside is to the right. And that is how it is mostly used. A toe line mapped as man_made=embankment would indicate a further slope down, which is not correct, because then it wouldn’t be a toe. Man_made=embankment is sometimes even used in the wrong direction, so that the arrows point upwards, which puts it on the map but is clearly not consistent with the stated intention of the object/tag.
A line where the slope becomes steeper, that could happen especially where reinforcements are used, and that could merit a separate man_made=embankment line. A plateau, if it is important enough to map, has a toe line of the upper slope, then another embankment line for the lower part. Again, mappers decide how detailed they want and can map in each particular case.

If the plateau is a road or cycleway, I think I would not bother to map upper and lower slopes. Same for regular long stretches of standard dykes/levees, which all have a plateau (banquet) between crest and toe. But in the showcase above I would map upper and lower slopen, e.g. where the combined railway embankment rests on the even wider embankment beneath the whole complex, which then ends somewhere on the bathtub floor, and I would also indicate that “landing line” with a toe line.

This way, regardless of naming or official /technical component mapping, very complex setups can be broken down and mapped reasonably accurate, in a way that enables effective rendering. Existing landuse/natural mapping is not touched, it just adds information that is currently missing.

It does not get in the way of even more detailed mapping where more parts of the construction are mapped separately. And, it even enables mapping of areas between the high and low edges, where the crest and toe lines can be rendered as themselves, and the area can carry other attributes such as name, material, surface, angle, height,…, and can even have other areas within, such as areas of wood, allotments, meadows, partial reinforced_slopes.

I did a small test to see how an embankment slope area could work:
image
This is an embankment under an aqueduct, that’s why it is triangular. I had no renderings for special lines, so I used the upside down man_made=embankment to get an impression. The left side of the triangle is a toe, and I gave that a non-renderable tag.
The whole area is tagged as natural=scrub (it’s actually rough grass), and I gave it the name of the aqueduct. I actually think it doesn’t look that bad, even though it could still be a pit instead of a single slope. The upper line looks fine. Imagine that the lower parts of the outline would look like a thin line with some shade at the slope side, I think it would give a good impression on the map.

1 Like

I honestly don’t understand that.

“man_made=embankment should be added to a way drawn with the lower side on right side of the way’s direction.” Klang für mich immer eindeutig nach der oberen Kante.

… an there ist no lower side!

and in the middle of the slope there is not only a lower side, but also a higher side. So it can’t be visible either.

Misapplied mapping/tagging should not be the basis for making the description in the wiki even more complicated and confusing. It should rather be a reason to make the description in the wiki clearer and more concrete. Incorrect application must also be clearly described as incorrect.

Btw. I don’t like the edits to the OSM wiki on man_made=embankment that have been made this month. They are too detailed, cause confusion and I think one thing or another is not described correctly.

A berm is not exclusively

The extent of horizontal ground between the watercourse or coast and a raised feature.

A berm can also be halfway up a slope. Berm is also a word with many different meanings. And probably different in the Netherlands than in the UK or Germany.
The German Wikipedia says:

A berm is a horizontal piece or ledge in the embankment of a dam, rampart, excavation, quarry or on a slope. It divides the slope into two or more sections. A berm is designed to reduce the earth pressure on the base of the slope. An embankment with a steep slope and berms is more stable than a continuous embankment without berms. Slope failure is thus avoided.

next point

the word used in the OSM-value for man_made=embankment typically refers to the embankment as a whole (sloping parts and the crest), but the focus in the descriptions and images used focus on the sloping part

embankment=yes on a highway or railway refers to the crown - yes.
As far as I can remember, man_made=embankment always referred to the edge between the crest and the slope. The rendering also follows from this: a line and markings (triangles, semicircles, small lines at right angles …) on the sloping side. Comparable representations can also be found on historical maps.

  • the instructions in “How to map” refer to a line with a with a high side and a low side, without making explicit if this is (a) the toe at the base of the slope (“face”) ; (b) the crest at the top of the slope or (c) both ;

That was never misleading for me. It must - for me always - be b). Since the rendering is comparable to natural=cliff, you can compare it with the description there:

If the cliff is not perfectly vertical the way should be located on the top edge.

If the previous wiki was misleading, it should be clarified as with natural=cliff.

however a well defined tagging scheme for describing the different elements of an embankment and their relations is not yet available. For the area of the slopes the non-documented tag man_made=reinforced_slope is sometimes used (Taginfo) but this is not explicit in the direction of the slope

That is correct. So back to what Peter wants: a simple tag marking the bottom of a slope.

KISS - Keep it simple, stupid!

Can be used for all kinds of embankments, dykes etc. Easily recognisable by the mapper in most cases, without the need for a mapper to have expertise in dyke construction, embankment construction, dam construction. Without knowledge of technical terms.

I fully agree with you in most of your points. What I tried to express is that the description to embankment in the wiki is poor and should be enhanced:

You may understand that this defines the upper kink of the embankment but it is not explicitely stated. An embankment is an area and if the area is represented by a way (bacause auf reasons of simplicity or else) that way could well be in the center of the area as long as the indicators shows the correct direction of the slope.

I do not say this is correct, I just pointed out that people can misunderstand this. And again it is not my idea that other mappers may draw the way at the toe line of the embankment:

and moreover the wiki also reflects this (see your own quote). Again I do not say this is correct, I just pointed it out.

Your idea that man_made=embankment always referred to the edge between the crest and the slope is reflecting the OSM tagging practice in most cases (although not clearly defined as such in the wiki).

But the text you quoted from the wiki talks about the meaning of the word embankment in real life where an embankment ist mainly understood as the whole structure beneath a raised traffic way from the crest down to the ground and then points to the fact, that in OSM the word embankment is used with a focus on the sloping part only (by the descriptions used and images attached). It is just a criticism on the poor definition of the term “embankment” in OSM which is one of the points in my earlier posts as well.

Thank you, this is exactly my point.

Please consider the possibility that other people don’t want to be KISSed by you.

Personally I first interpreted the text

man_made=embankment should be added to a way drawn with the lower side on right side of the way’s direction

also as to draw a line on the high end of the slope.
But then I saw several large embankments with man_made=embankment also around around the toe of the embankment, then I read the text in the wiki again and came to the conclusion that the tagging instruction wiki does not exclude this : when looking perpendicular at the toe line, when you move away in both directions, one direction is lower compared to the other.

This might for most people not be the first way to read the tagging instruction (it was not for me), but if you would only allow it only to the high end of the slope and consider all other uses as incorrect, you are left with a much worse problem:

If you draw a line around a simple embankment like a sound barrier, with downward slopes on all sides of the crest -only around the the top the slopes-, you would draw the circumference of only the crest, and leave out all the slopes , while the definition in the wiki and images focusses on these slopes :
image

This while the feature that man_made=embankment aims to describe is normally regarded as the sum of crest+slopes.

So with this narrow approach of what current man_made=embankment may be used for, it is actually representing man_made=embankment_crest , which would be a very confusing choice for a tag name and tagging instruction.

That is why I would ask again to please respond to my earlier question on whether you agree to these working definitions or if you have a better alternative.

Because if we don’t agree on the scope of definitions we can have endless debates and not get anywhere, and that would be a waste of time.

1 Like

No, it doesn’t, if you consider the whole wiki text and examples. I have altered my opinion on this point, and no longer think the wiki supports the option to use man_made=embankment on a different line than the top line of one slope of an embankment. I think the intention is clear, and most mappers understand this and use the object as intended. I do think the wiki should be made more explicit on this point. Which I will not do during this discussion! It would give the impression of retrofitting the wiki to enforce my preference, while I am, on the contrary, keen on keeping the current usage, based on this wiki, unchanged. I just want to offer renderers the option to improve their rendering, and renderers who do not want that should not have to do anything.
I think the “overwhelming minority” of uses based on a different interpretation, will stop once an easily renderable alternative (to map the end of an embankment slope) becomes available.

You know the KISS principle?

Or, the feature that man_made=embankment aims to geotag is de top of an embankment slope, also to be used for one-sided embankments, so a two-sided embankment needs two lines, one for each side of the crest. The lines indicate positions of the artificial slope tops, but not the extent or area attributes of slopes. This is all standard stuff in OSM, where a road is represented by a single way, a parking lot can be represented by a single node, etcetera.

1 Like

I absolutely agree.

And that doesn’t rule out inventing tagging in the future that covers all the individual parts of a dam or embankment. But everyone should keep in mind: OSM is not landscape planning software and not software for engineers.

1 Like

Yes, I do.
The fact that you use the “…, stupid!” variant again after it already came across to another mapper as unkind just seemed unnecessary to me.

If you are looking for an acronym this version of THINK might be more constructive. :wink:

There is one significant difference here tough:
in the examples given it are more simple elements (node / way), mostly placed in the center to represent something that in the real world is an area.

With embankments it was concluded earlier in Wiki-Talk that it can be used on closed ways.

And while these are technically not areas most users will interpret them as such when they see them. And this makes the term man_made=embankment a very confusing name for a tag that -in the narrow tagging interpretation- would not draw a line around the embankment, but would only draw a line around the highest part of the embankment, the crest.

And with embankments the crest might be placed very asymmetrical in the cross section of a two-sided embankment, which makes it different from representing an area with an open polyline or node.

If the picture above was a building (grey) with an inner garden (green), we would in the most simple form tag the outline of the building with the general building-tag along the red outer line.

If we wanted to map the building in more detail we would also map the blue line and create a multipolygon.

But what we would not do is only trace the inner blue line and tag that as building.

But with simple embankments like sound walls, that is what the narrow interpretation of the “How to map” works out: only inner blue line (the crest) is tagged with the general term “embankment” , while the parts of the embankment which the description in the wiki focuses on (the slopes) are left out of the traced line.

That approach is so counter intuïtive (“for man_man-embankment trace around the part that is not a slope”) that there are mappers that interpret this in a wider way, so a line can be draw around the actual embankment.

I think everybody would welcome a more explicit instruction on this in the wiki, nobody benefits from this kind of confusion.

If the choice would be to only allow the narrow interpretation, that would also mean considering retagging current usage according to the wider interpretation around the toeline to a new -to be documented- tag. An alternative that could then also be considered would be to rename the general sounding man_made=embankment to a more specific name that is more in line with the narrowed down tagging instruction.

1 Like

How many toe-lines mapped as man_made=embankment do you think there are? So far, only your one example came up, mapped by you. IIRC you mapped one slope, the crest kink line and the toe line, bith as man_made=embankment.
I think this is an exception, and almost all mappers use man_made=embankment to geotag the upper line of the slope.

I have not yet seen any case of a full two-sided embankment mapped only as an outline along the toes.

The consequence of changing the definition on rendering in those cases are none. The rendering remains exactly the same. The impression that it is a pit instead of a slope, also remains the same.

I don’t know, but far more such examples have come up in just our discussion than the one example you mention now:

  • The discussion you linked here in the Dutch forum started with an example in Germany by a another mapper with both toe-lines mapped (which the OP called a nice way to depict the embankments)

  • as I wrote here I first followed the narrow-interpretation for tagging man_made=embankment, until I saw work from yet another mapper who tagged the toe-line as such, read the wiki again and realised that it does not exclude using it for the line around the actual embankment (the toe-line). I think it was the work of another mapper here

  • and I am in good company realizing that the wiki is not clear cut on excluding usage on the toe-line, for example this mapper wrote

Which translates to (Deepl ; [my addition about tense in Dutch original text] ) :

I read [past tense] the wiki for embankment as tagging the stitch line/crown edge of the embankment. But he does not, on re-reading, rule out that you could use the tag for a footline;

  • And others in this English thread have concluded as well that you could read the wiki in the broader way as well. Especially since the narrow interpretation can in some cases be very counter-intuitive as described here.

  • And more mappers will held this opinion on one time or another and have mapped accordingly, as you can see for example here: without much effort I stumbled upon a site with some 50 embankments where the toe lines are tagged by yet at least two different other mappers.

I am not saying this is ideal ( for instance I wonder if the toe lines are drawn in the correct direction), but the suggestion that usage for the toe-line would be extremely rare is simply not supported by the examples of mapping and opinions that have been presented.

And I would still very much would appreciate your reply (or better proposal) on the question of definitions for scope in this discussion

True, there are more examples. Still I think the regular use of man_made=embankment is just the crest side line. “Nice way to depict embankments”, I disagree.
The example of the military base in Den Helder shows why it’s not a good idea to map the toe lines as man_made=embankment. The mapper probably thinks it shows embankments, because (s)he knows what is there, but if you don’t, it shows a collection of curiously formed (snake?) pits. I’ll zoom in a little…

To the left, a sea dyke has its crest mapped. Outside the embankment is another embankment line, where another section of the slope starts, there is a banquet (berm) there. There is no toe line, but there is a fence which gives an impression of the ende of the slope, just above the outer embankment line. And the water edge marks the end of the lower slope. This looks OK.
A toe line could improve the rendering by showing the berm with the fence better.

The military embankments would certainly profit from a differently rendered toe line.
The outer lines are drawn with the high side to the right, not the low side. You could draw them in the other direction, but then they would look like another slope section, just like the reinforced slope of the sea dyke.

I said in the beginning of this discussion that I thought the wiki did not rule out using man_made=embankment for the toe line, which was my first impression. I was wrong; the wiki doesn’t explicitly say the tag is just for the upper line where the slope begins, but taken as a whole, you can’t fit a toe line in the description and the examples, and it is clear that it only applies to the upper line of one embankment slope. Anyone who wants to quote me on this, please do not quote my older impression!
I do think it would be wise to state this explicitly in the wiki, and you can quote me on that.

Addition to the navy base mapping:


These are not embankments, but fuel storage tanks. I think we have a serious case of mapping for the renderer!

I try to avoid the discussions about the terms, and concentrate on the information needed (mainly) for renderability. (Is that even a word?). I think the initial confusion is much less now. Yes, embankment is the whole thing, but also often used for just one side, and there are one-sided embankments.

All the technical parts, categories and variations and the terms for those things, it’s nice to have a model and terminology for describing things, but we shouldn’t let progress depend on that. I think whatever models and terms come up, the basic information where the embankment slope stops is always needed.
I do not want to impact the installed base for man_made=embankment as the upper border of the slope. Which leaves deciding on how to map/tag a lower border of an embankment slope as the singlemost piece of information needed, to get any further. No matter what the exact definitions are.

1 Like

I think this example is off-topic. And that kind of judgement seems a bit excessive in this case whether or not there is a fuel storage in the core of the embankment, observers still see an artificial slope covered with grass. And the feature is also tagged as storage tank in OSM.
image

But more on-topic I think it is good that you mention the principle of tagging for the renderer. I find the constant focus on how nice or not nice examples render in current Carto instead of how structure of the data we enter in OSM relates to the real world features we aim to describe worrying.

I think everybody agrees that the current mapping scheme for embankments is not sufficient and that mapping toe lines -and being able to distinguish them from crest lines is a valuable addition.

But if we rush to just ivententing another line and focus on fun things like tagging, the end result might not be an improvement but make a bad tagging scheme even worse (see some of the considerations mentioned earlier)con.

I found this to be the most worryin example of (incorrect) tagging for the renderer at the cost of a geometry that is representative for the feature we aim to describe:

In the Dutch thread you defended mapping this embankment:

like this:
image

with a break in both the toe-line and the crest line -where in reality they continue. Stating:

and just as with a track on landuse, you can then craftily map the landuse on either side separately

That might look nice in Carto with a 3d like effect at the break, but that resembles the canonical example of what NOT to do when it comes to incorrect tagging for the renderer.

And after removing the optical break the alternative which is geometrically much more correct was discarded -like the examples in the post above, looking at current Carto images, stating:

You want a solution that also looks like a dyke to others.

While as a geometry the second variant is much more correct, and has the potential for both renderers and other data users to give usable results.

But to do so we must first improve the tagging scheme so that we have a scheme with meaningful terms in relation to each other and in relation to the features we aim to describe, so we can distinguish both the circumference of the different parts and their relations.

Rendering is at the end of the line, our job with tagging is just to hand the renderers the information they need and not cut corners to get nice looking results quick.

No I did not defend that, I rejected that. it was an example of what could currently be done in mapping but with a wrong result, showing that there is a lack of information for a renderer to do this better. Hence the need to add at least a toe line which can be rendered differently. The break represented a path. It does not help to keep quoting me out of context!

As I said before, I focus not on the actual rendering, but on the information needed to render embankments better. At the same time, better rendering is the main goal here, and that requires mapping. When thinking about this, how it could be done and how that would work out, examples wil show a rendering.

Mapping the toe line as man_made=embankment because then you see the line, even though it does not fit the wiki, that is classical mapping for the renderer. I would like to see that change into mapping the toe line with its own tag(s), and I expect rendering to follow later as the information to make it look better becomes available.

Do you think mapping a toe line does not correspond to the real world?
Can you think of a workable data structure for richer mapping of embankments that would not include the toe line, be it as a separate line or as part of a polygon or area outline?

I think the bottom line is that we all want the same thing: a better representation of the extent of a slope in the database and on a map. For you Dutch, the dikes are the most important, that’s understandable. But it should also work for other very similar things, whether it’s a dyke, a railway embankment, in road construction, noise barriers or construction pits and fortifications. The basic principle of an embankment is always the same: there is a top edge, a sloping surface and a bottom edge. Mappers can recognise and map these three features even without specialist knowledge.

Keep it simple …

There are several ways that can lead to this goal:
First, we accept that embankment=yes is just an additional information at another way, that it runs on an embankment, but has no information about the width of the embankment. I think this is indisputable and needs no change.

  1. man_made=embankment is in use, far predominantly representing the crest_line between crown and slope. Other uses in the middle of the slope or at the toe_line are considered incorrect because either the wiki was misleading (not in my eyes), the mapper misinterpreted the wiki or deliberately used for the toe_line to force a render (mapping for the renderer).
    The wiki needs to be clarified: man_made=embankment exclusively only for the respective top edge of a slope.
    The wiki is to be supplemented: a new tag for the toe_line, e.g. man_made=toe_line or man_made=embankment_toe or …
    This toe_line will also be visualised by the renderers in the future. This problem should be solvable.
    advantage: very simple!
    man_made=embankment remains untouched, most mapped slopes can remain unchanged, only some wrong ones have to be corrected.
    Desirable would be a modified rendering with the fine strokes (as I know it from most maps and from plan drawings). This makes the mostly even slope better distinguishable from rather steeper or vertical and irregularly shaped natural=cliff.
    Disadvantage: it is not a tagging scheme, it is in man_made=* with much else.

  2. we use man_made=embankment as the main tag in future and extend it as a tagging scheme, e.g.
    embankment=crest_line for the top of the slope surface and
    embankment=toe_line for the lower edge where the slope meets the ground
    Advantages: clear tagging scheme, expandable. Existing man_made=embankment could be searched for specifically and extended by embankment=crest_line after visual inspection (while adhering to the rules for mass edits) - in doing so, visual individual inspection also finds the cases where it has been mapped in the middle or at the toe so far and can correct it immediately.
    Disadvantages (that I see): possible conflicts with existing embankment=*.
    The combination of man_made=embankment and embankment=toe_line is factually rendered wrong (like the crest_line) by renderers that only evaluate the first one. This can lead to more confusion overall at first.

  3. We invent a completely new tagging scheme with a new main tag. The big disadvantage is that this is not rendered at all at first. However, such a completely new scheme could be run in parallel for a while until the renderers also display it.

Personally, I would prefer the first option.

1 Like