OpenStreetMap logoOpenStreetMapNederland

Mapping embankments

Posted by Peter Elderson on 3/3/2023

This diary entry contains a wrap-up of discussions on the osm forum, (dutch section and general section). I’ve tried to capture all that has been said into a logical narrative and solution proposal.

Improved mapping of embankments

Objective

Establish improved mapping of embankments. This includes small embankments and large embankments; one-sided, two-sided and irregular embankments; embankments to contain and to protect against water, embankments to support roads and railways, and embankments serving as a traffic barrier, visual barrier or sound barrier. The aim is mainly to enable fuller rendering on maps, including at least the extent of the slopes. It is NOT the intention to establish full mapping of all aspects of embankments. However, it also should not exclude richer mapping of embankments in the future.

Starting point

Embankments can currently be mapped as:

embankment=yes on a way on the crest of the embankment.
This is especially useful if there is a road, track or path on top of the embankment. Some renderers also handle a single way tagged only with embankment=yes, without a main tag. The tag can modify the rendering of the way, to suggest it is supported by an embankment. Comparable to how a way can be altered by the tag bridge=yes. Other non-approved values are sometimes used, e.g. embankment=dyke for a way on a dyke/dike/levee. There is no established way to indicate further details of the embankment itself, e.g. left/right differences, landcover or surface, steepness, width. Theoretically one could add details like embankment=right and embankment:right:width=5 but this currently is not done. We don’t propose or oppose that.

man_made=embankment on a way tracing the crest edge/edges of the embankment.
Though some mappers use this tag also to trace the bottom edge (toe) of an embankment, the predominant (and so documented) use of man_made=embankment is to trace the crest edge (the upper edge of the slope or slopes). The mapping instruction that the righthand side of the way should indicate the lower side of the embankment is not compatible with the use as a toe edge line. This tag enables renderers to show where the upper edge is or where the upper edges are, and it allows mapping the crest shape (varying width; curves, cuts, corners and crossings; platforms on the crest eg for buildings, terraces).

This is established mapping and the intention is to keep this as it is. The proposal (beneath) enables improved rendering, but if a renderer does not do anything, that particular map wil not change. It’s a non-breaking extension proposal. The same is true for mappers who have used man_made=embankment for the lower edge of embankment slopes. To profit, some retagging will be necessary. If the ways are not retagged, the rendering wil not change.

That said, an embankment is more than a crest edge or mid-crest line. I will make an effort to support more systematic naming of the most visibly important parts of embankments.

What is missing and how to go about it?

Mainly for large embankments, what is missing is information about the slope(s). We know the top (crest) edge, but we don’t know the lower (toe) edge. We don’t know any specifics about the slope: steepness, type of reinforcement, extent, material/surface, berm. What you don’t know, you can’t use or render. So we want to map more information, somehow.

Most wanted: the extent of the embankment at both sides. Since the extent can differ on both sides, and the slopes at both sides are often not connected, the mapping must be able to handle one slope. If the two sides of a levee do connect, they can simply be treated as one curved slope. Because the slopes of elongated embankments are often interrupted by coupures, buildings, roads and other landuse, the mapping must also be able to handle sections which together form the embankment. And let’s not forget one-sided embankments to support sections of mountain roads.

Mapping the toe edge with man_made=embankment is sometimes done. It results in the slopes looking (on the map, no matter which renderer) like pits in the ground. Or, when drawn in the other direction, like two embankments on top of each other. With steep embankments where the toe and the edge are close together, the two line renderings tend to merge and look like a railway or a very thick wall.

Conclusion is that we need a different method (and a different tag) to map the extent of the slope of the embankment. One that enables data users to handle the upper edge different than the lower edge.

Options

A. Add a polygon for the slope area
The first thing that comes to mind is: it’s an area, so why not use a polygon representing the slope. The problem is: how do you know, as a data user, which side is up and which side is down, and if you knew, could you render the lower edge different from the upper edge? Maybe you could associate a portion of the polygon with the man_made=embankment crest line, but is that going to happen for real? And isn’t that a bit overdone, mapping a crest-edge line AND a polygon which also has partly the same line?
Doesn’t sound good… but wait, hold that thought!

B. Add a stand-alone toe line
Another option is to simply draw a way tracing the embankment toe line, i.e., if it is visible/verifiable by survey, and tag it as the toe of an embankment. Anything between crest and toe is regarded as the slope of the embankment. The toe line can get a rendering suggesting a kink in the landscape, where the embankment slope hits a level piece of land.
This enables rendering the extent, but it does not enable area-rendering, at least not in the way that areas are normally rendered. Just a visual impression.

C. Create an area incorporating the crest edge line AND optionally a toe line
As it happens, there is an approved and operational method to create an area from multiple different ways. And this solves the problem of tagging crest and toe lines in their own right AND the slope area in between!
Simply connect the two tagged ways (or sections thereof) using untagged ways to delimit the area. Then put the ways forming the outline of the area in a multipolygon as outers, add a main tag, and there is your area. The tagged ways will be rendered as usual, the untagged lines are invisible area delimiters, and the MP is an area and can have its own tags and rendering, even a name.

So what do we need to accommodate all options at once?

  • A crest edge line, we have that.
  • A toe edge line, that’s new.
  • A multipolygon to form the area, that’s already possible, but the main tag is new.

You could e.g. map an embankment slope covered by scrub as an MP tagged natural=scrub, defined by (a section of) the way tagged man_made=embankment as outer, and an untagged way forming the rest of the outline of the embankment slope. This actually works and is not bad visually, if e.g. at the toe line the scrub changes in grass or wood. If a toe line is present and separately rendered, you can simply incorporate that as outer in the MP representing the slope area. To get additional rendering of the slope area itself, the area would need a new main tag to let data users know what it represents.

So, one new tag for a way, and one new tag for an area, and no forced changes to the installed base. Not bad! I think it’s not a big enough subject to warrant a new main key. Let’s see if we can do it with a couple of new values for an existing main key.

One thing: the crest edge is tagged man_made=embankment, but the embankment is much more than a crest. That’s why a synonym is suggested for the tags of embankment parts, and the other values reflect the parts of an embankment that stand out in the landscape.

Tags, proposed

  • man_made=embankment:crest as a synonym of man_made=embankment
  • man_made=embankment:toe as tag for a way tracing the toe line (bottom edge of an embankment slope)
  • man_made=embankment:slope as tag for an area covering an embankment slope from upper edge (crest edge line) to bottom edge (toe line).

More generally worded alternative could be:
- man_made=embankment:upper
- man_made=embankment:lower
- man_made=embankment:slope
It’s just that man_made=embankment:upper could be understood as “the upper embankment”, embankment:lower as “the lower embankment”. As large dykes often looking like embankments on top of each other, I think this would create confusion and considerable mistagging.

What about man_made=embankment, embankment=crest|toe|slope ? This kind of sequence is generally used for typology. It would imply that crest, toe and slope are types of embankments. I would rather support e.g. embankment=dyke|railway_bank|road_bank|sound_barrier|river_bank|… to indicate the type of embankment by function. This would be tagged on the most defining element: the crest. This is not part of this proposal, but this proposal should not stand in the way of a regular breakdown scheme for embankments types.

How to map

First, let’s establish a standard mapping scheme, in 3 levels/stages of detail.

Level 1: Always consider simple mapping first (existing mapping: just embankment=* on a way on the crest; or man_made=embankment or embankment:crest on the crest edge)

Level 2: Then consider if the extent of the embankment should be mapped: if so add a toe line or toe lines

Level 3: Then consider if area attributes are required for the slope(s); if so add a multipolygon area tagged man_made=embankment:slope containing the upper way, lower way, and connecting ways as outers.

  • Level 1 already accommodates many embankments.

  • Level 2 mapping is expected be widely applied, if not for the whole of every embankment then for sure for more complicated sections.

  • Level 3 mapping accommodates large dykes, think 50m or more toe2toe, found in substantial numbers in Nederland. E.g. ‘polder’ dykes, where each side can have a different name, form and surface, can be accommodated (name=, surface= on the MP’s). Or sea dykes with one side built of special surf-resistant concrete blocks (surface=? on the slope area).

Rendering

I think rendering of the toe line should be subtle, no shark’s teeth or comb lines. It should suggest a kink in the landscape. I have tried to create a shade effect, using inkscape, then upload it to imgur as svg. Crude, I know, but it’s about the idea.

Suggested rendering for man_made=embankment:toe (dark grey side=high side)

embankment:toe or embankment:toe2

Only thinner and more transparent. I wish I was better at this!

Use cases

a. One-sided embankment against a hill or mountain slope, carrying a road or railway.
  • Standard mapping scheme
  • If the upper part of the slope is more like a retaining wall, consider using barrier=retaining_wall instead of embankment:crest. This has no consequence for Level 2 and Level 3.
b. Two-sided embankment to carry a road or railway above ground level
  • Standard mapping scheme for each side separately.
  • For long embankments use suitable consecutive sections. Coupures/floodgates and major turns are natural places to start a new section.
c. Dyke/levee: One- or two-sided embankment for flood protection along the coast, along a river, around a “polder” or between “polders”.
  • Standard mapping scheme of each side separately.
    If the sides of a dyke differ, so can the mapping. There is no obligation to map both sides with equal detail.
d. Two-sided earth wall as a noise barrier along roads or railroads
  • If there are no other intersections,the standard mapping scheme may be done for the two sides in one go.
    • Level 1. Trace the crest edge line as a closed way tagged man_made=embankment:crest (or its synonym man_made=embankment);
    • Level 2. trace the lower edge line as a closed way tagged man_made=embankment:toe;
    • Level 3. Create the multipolygon with the toe-line as outer and the crest as inner, and tag it man_made=embankment:slope.
      • Note that this is the only case where an inner is used. If you don’t want the exception, just map the two sides separately, as two multipolygons with just outers.
e. Large embankment slope with a “berm” or “banquet”
  • Tag the higher slope and the lower slope separately, using the Standard Mapping scheme.
  • If there is a road on the banquet, consider if that in itself is enough to indicate the extent of the higher slope.
f. Complex crossings involving embankments
  • Divide the complex into separately mappable edges and slopes.
  • Use the standard mapping scheme on each section
g. Reinforced_slope as a part of an embankment (water-side)
  • No preferred mapping (yet?)! The reinforced slope can be the complete slope, or just the lower part, or in the middle; it can be usually exposed or tidally exposed; it could coincide with a banquet or not; it could stretch along the whole dyke or just some vulnerable parts. It’s up to the mapper to decide whether or not to incorporate or overlay embankment mapping with reinforced_slope mapping.
h. Coupure / floodgate
  • Basic mapping. Let the ways and, if used, the area stop at the coupure/gate. The mapping of the coupure gate is separate from the embankment(s) involved.
i. Irregular shaped crest/slope/toe
  • Basic mapping.
  • If it gets complicated, divide the complex into separately mappable edges and slopes. Think of how elaborate water areas are broken down into manageable sections.
j. Other features (buildings, landuse/natural/man_made/leisure) on crest/slope/toe
  • Basic Mapping. If it gets complicated, divide the complex into separately mappable edges and slopes. Think of the way elaborate water areas are broken down into manageable sections.
  • Let the edge ways stop if they are interrupted by another feature. Note that landcover usually does not interrupt a crest or a toe.
  • When mapping the slope as an area (multipolygon), it’s possible to cut out other areas on the slope as inners of the multipolygon. Whether this is useful or not depends on the tagging of the slope area. If we agree that an embankment:slope area can have a surface tag or landcover tag, the use of inners is appropriate. An embankment usually has its own operator, which might be different from what’s on the slope. Etc.
  • Note that this additional tagging and handling is not proposed here. Just the mechanism of indicating an embankment slope with an optional toe line tagged man_made=embankment:toe and optional multipolygon area tagged man_made=embankment:slope.