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 :
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.
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. 
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.
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:
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.
-
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. -
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. -
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
Been following with interest, so a couple of questions re possibly connected options.
How about cliffs? We currently only map the top edge of a cliff - should we also map the bottom?
& do we then turn any new embankment idea around, & also us it for the top edge of cuttings?
I wouldn’t use man_made for cliffs. You could copy the idea, though.
Cutting can take the form of a retaining wall, thus that would not be an embankment, I think.
If the cutting on one side of the road is in fact a one-sided embankment, I would not hesitate to map it as an embankment.
So two OSM-embankments, back to back, form a dyke/levee/railway embankment/road embankment; two OSM-embankments, toe-space-toe can form a cutting. When there is a road or railway in between, I don’t think I would map a toe line, though. Unless… well, the cutting could widen , maybe for a gas station or rest area… then maybe a toe line would be nice on that section.
(Disclaimer: I’m thinking out loud. If valid counterarguments emerge, I might change my mind, in that case please don’t hold this against me!)
I (for one) would like to heartily encourage “thinking out loud” in OSM’s Discourse forum (here).
This is, and should remain, a friendly, productive, collaborative space to do exactly that, this thread is a good example of it. There’s some fascinating stuff being said here and the fact that the discussion is so lively and diverse I find wonderful. There are ideas that cross over between railway mapping, natural mapping (like cliffs from @Fizzie41), stern and necessary reminders that OSM is a database (with renderers and use cases properly stated as “at the end of the line” and “only need the data that they need”) and some great rhetorical devices like “Advantages and Disadvantages.”
Keep up the good discussion, everybody. This is a bright, vibrant topic, with awesome pictures and thoughtful posts.
BTW, as a native English speaker, I would say “renderability” is a word, though purists or dictionary publishers might disagree. (My excellent dictionary shows “-ability” as a listed suffix).
1 Like
How could a toe line look on the map? Of course, it’s up to the renderer, but the renderer shoud get some idea of what is requested. I have heard mentioned a rendereing as a line with short side lines at the slope side. When the top and bottom edges are close, this would mean overlap. It also is quite similar to some renderings of the top edge I have seen.
I was thinking of a light gray/dark gray double-line, giving an impression of a kink line. Dark side would be the slope side. This would work on any background, I think. It’s the same trick used for undertitles, to ensure the letters are visible on light and on dark backgrounds in any colour.
Impression (making very clear that I’m a disaster when it comes to images…)
I hope this conveys the idea.
This is a piece of an actual embankment toe line. And a very crude double-line mimicking it. I think something like this, made into a line by someone who actually knows what (s)he is doing, would do the trick. It’s direction dependent, just like the top edge.
If the mapping aims to draw the toe line in the same direction as the top line of the slope, the instruction would be that the slope side is to the left of the way (dark), the flat side is to the right of the way (light).
The light side is the right side.