Add rendering for man_made=dyke

[matthijsmelissen]

In coastal regions, such as the Netherlands or Germany, dykes are important features. It would be nice if they could be rendered.

Example region: http://www.openstreetmap.org/#map=16/53.9390/8.9138

See also https://trac.openstreetmap.org/ticket/3982.

[matkoniecz]

http://wiki.openstreetmap.org/wiki/Tag:man_made%3Ddyke exists but it need to be improved to be a proper documentation

Note that man_made=embankment used for tagging dykes is already rendered.

[ChristianKraemer]

What is missing to be a "proper documentation"?

Regarding "man_made=embankment" vs. "dyke": In http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment you will find "it is much more common to use embankment=yes than man_made=embankment." Looks like "embankment" is commonly used as an additional attribut for something existing, mostly a way. Unfortunately this isn't possible for a typical dyke, where only sheeps are allowed to move on the top.

[matkoniecz]

For example:

"This could apply to a point line or area, depending on the level of detail used.", according to infobox it may not be used for nodes (what seems more sensible).

Relation to man_made=embankment is unclear (IMHO it is duplicate, but I am against using man_made=dyke).

And "this is a stub page for man_made=dyke " indicated that this page is unfinished.

[ChristianKraemer]

Well. The wiki isn't like an RFC in computer science. So a lot of real tag usage is not covered by wiki entries. That's the drawback of crowd source.

[matkoniecz]

It is obvious, but usage of tag that is not described properly on wiki should not be encouraged by rendering it.

[ChristianKraemer]

We are talking about a niche topic, like pikes in the mountains. I'm aware of dykes in the Netherlands, Germany and the USA. So the number of people involved is limited. Nevertheless these "things" are significant for the landscape where they exist.

[ChristianKraemer]

Did you take a look at at the discussions about the "dyke" wiki-page and the history of the page? Just combine it with http://yosmhm.neis-one.org to get an idea, if people have an opinion about the neighborhood or talking from a "more theoretical point of view".

[matkoniecz]

Rendering poorly documented tag is a poor idea.

[eigenwillig]

@ChristianKraemer Hi Christian, what about reviving this proposal? I think now the definitions of man_made=dyke and embankment are clear.

[matkoniecz]

Original reason for closing no longer applies.

[VA00]

Dykes are quite wide features, e.g. Vistula river in my surroundings is protected by structure 25 meters thick at the base. Moreover, asphalt or gravel cycleways are very common on top, recently. Dyke ,,embankment'' is usually symmetric. Both mapping and rendering is troublesome, see e.g: dyke with bicycle path:

https://www.openstreetmap.org/way/175984422

and ,,bare'' dyke:

https://www.openstreetmap.org/way/412551359

Single line tagging provides asymmetric rendering of symmetric feature, suggesting it is narrow, like a path or edge. Dual line mapping of top of the dyke results in ,,messy'' rendering, especially if one fit cycleway between them. Option is to draw lines at the base of dyke, but it is uncommon and wrong. For some topographic maps, dykes are mapped using four lines, but this seems too complicated.

On the other hand, dykes are very similar to dams, except symmetry and surface. Dams are usually concrete at the water side, dykes are covered with grass. So maybe area is more appropriate than line, with more ,,green-ish'' or ,,brown-ish'' color to indicate ,,unpaved'' surface. See e.g:

https://www.openstreetmap.org/way/465945107

Dyke:

vs dam:

[mboeringa]

Single line tagging provides asymmetric rendering of symmetric feature, suggesting it is narrow, like a path or edge. Dual line mapping of top of the dyke results in ,,messy'' rendering, especially if one fit cycleway between them. Option is to draw lines at the base of dyke, but it is uncommon and wrong. For some topographic maps, dykes are mapped using four lines, but this seems too complicated.

The problem with dual line mapping is that for some reason I don't quite understand, people tend to digitize the "top-line" of the dyke as man_made=embankment. This is in my opinion a mis-representation of the embankment, as, like you also wrote, many dikes are very wide, indeed up to 25 meter.

For a cartographically sound rendering, I would therefor suggest to digitize the embankment lines somewhere between 1/3 to 1/2 down the slope of the dyke, instead of digitizing the "top-line". Doing this, will lessen the cartographic problem you refer to with roads of footway/cycleway considerably, and allow cartograhically sound rendering in a much wider zoom range (e.g. 1:5k-1:25k), instead of only looking good at the very highest zoom levels.

E.g., see this image, which is representative of how I digitize them:

[imagico]

Just to avoid mappers who read this to actually follow the instruction - what is suggested above are map painting instructions for the mapper to spare map designers the need to actually work on a meaningful data interpretation while resulting in mandatory mediocrity for all data users who all would have to show the data as painted by the mapper but at the same time have no reliable information on the actual geographic reality that would enable them to create a high quality rendering.

So as a mapper: If you want to map a dyke then map the dyke in the form you find best to represent the observable geographic reality. Do not try to draw what you or someone else considers suitable design elements of a cartographic representation of that reality in a map.

[mboeringa]

So as a mapper: If you want to map a dyke then map the dyke in the form you find best to represent the observable geographic reality. ****

So you think that suggesting to do whatever you like:

"form you find best to represent the observable geographic reality"

is more objective than actually giving a clear instruction as to how to digitize them:

"1/3 to 1/2 down the slope of the dyke"?...

In fact, I would agree with you if either the:
man_made=embankment
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment
or:
man_made=dyke
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Ddyke
page had clear instructions to micro map dikes as two man_made=embankment lines following the top-line of the dyke.

Neither page does... In fact there is no instruction at all as to how to map man_made=embankment lines, except sticking to right-side-is-low-side.

The fact that you now suggest "to do whatever you like" ("map the dyke in the form you find best") actually hampers developing "a meaningful data interpretation" for man_made=embankment.

Just to avoid mappers who read this to actually follow the instruction - what is suggested above are map painting instructions for the mapper to spare map designers the need to actually work on a meaningful data interpretation while resulting in mandatory mediocrity for all data users

No, it is not. A dyke is a structure potentially a few dozen meters wide, as @VA00 already explained. Who says the current practice is a better representation of reality than the one I suggested, which still keeps the embankment lines on the real world structure, not displaced from it, because that is not what I am suggesting.

They are equal as long as the Wiki is undecided and incomplete... (and maybe that is what needs to change...)

[jeisenbe]

I believe you've misunderstood Christoph's comment. I think he is saying that he would like mappers to draw dykes (or Levees, or embankments) in a way that represents their real location. So if they are mapped as a way, the line should follow the center of the dyke. This may sometimes be the same location as the centerline of a cycle path or service road that follows the top of the dyke (but not always). Use width=25 if it's a 25 meter wide dyke.

The map renderer can then use the line, or can compute one from the polygon, and use this to determine how the dyke should be rendered at each zoom level.

Mapping the dyke as two lines is less useful for database users, because it duplicates the data or makes it harder to use. If you use a closed way ("area") drawn, we would need to calculate the centerline first, before rendering.

Christoph has shown how to nicely render embankments along highways tagged embankment=yes on his blog. The code is a little complex, but it would look quite nice for dykes as well: http://blog.imagico.de/rendering-implicit-embankments/

Example:

[mboeringa]

I believe you've misunderstood Christoph's comment. I think he is saying that he would like mappers to draw dykes (or Levees, or embankments) in a way that represents their real location. So if they are mapped as a way, the line should follow the center of the dyke.

@jeisenbe , I agree the man_made=dyke tag should be drawn on the center of the dyke, and that you can develop rendering for it. I actually implemented something similar to Christoph in my own renderer.

The problem is that we have two representations of dykes currently used by mappers:

1. • A single man_made=dyke line drawn along the center of the dyke. This is actually "dyke tagging", because we assign the tag described for it on the man_made=dyke Wiki page. The tag is in fact usually added to the corresponding highway=x line already drawn that represents the road or footway going over the dyke (if any)
2. • A micro mapped dyke that doesn't use the man_made=dyke tag, but instead uses two man_made=embankment lines, usually drawn along the right and left top-line of the dyke. This isn't actually "dyke tagging", because we don't assign the tag from the Wiki, this is "embankment tagging". In this case, luckily, most users refrain from also tagging the feature man_made=dyke with a center line. If they would, and rendering for man_made=dyke was implemented based on this center line , we would end up with a double overlapping rendering of dyke symbology.

In the Netherlands, where I live and where dikes are probably more numerous than anywhere else in the world, both practices are common, and man_made=dyke is usually replaced by mappers by the micro mapped double man_made=embankment line if they want to add more detail. The man_made=dyke tag is then removed from the corresponding highway=x line it was added to (if such highway exists).

[Adamant36]

@mboeringa, isn't a dyke essentially an embankment? So, replacing the dyke tag with embankments isn't technically wrong is it? (I'm not trying to start a tagging discussion. I'm just wondering what the differences would be in rendering etc if they are essentially the same thing.)

[mboeringa]

@mboeringa, isn't a dyke essentially an embankment? So, replacing the dyke tag with embankments isn't technically wrong is it?

Yes, and I am actually fine with the current practice as applied in the Netherlands.

As long as people avoid to also add the man_made=dyke tag in case they start micro mapping the dyke with two embankment lines, because that would represent a cartographic challenge given the potential conflict in symbology if rendering for the man_made=dyke tag is implemented as well in a style (as it is in my personal style and probably a few others).

[jeisenbe]

@imagico - do you think your code for implicit embankments would have fast enough performance for this style?

If so, we could also use if for ways that were dual-tagged with highway=* and man_made=dyke; this seems to be very common. Most of the levees that I know in the western USA have at least a footpath, and more often a service road.

[imagico]

@imagico - do you think your code for implicit embankments would have fast enough performance for this style?

I do not know. It probably depends on your understanding of fast enough.

[SomeoneElseOSM]

Just for info - there are some more embankment examples (in an OSM-Carto derived style) at https://map.atownsend.org.uk/maps/map/map.html#zoom=15&lat=-25.00269&lon=135.09449 and https://map.atownsend.org.uk/maps/map/map.html#zoom=16&lat=-24.99105&lon=135.1531 . See changelog at the top for links to style source.

The way that it was done was by making "embankment" a modfier in the code in a similar way to "bridge", and by also rendering standalone embankments as "two sided cliffs".

[imagico]

Yes, the bridge like rendering of embankments is essentially the same as the 'very simple' variant i have shown on the blog. The problems this causes are less prominent when you render it as a simple bridge like casing than with an offset pattern line.

[jeisenbe]

I've added the "help wanted" tag for this issue, because I believe it would would be worthwhile to render, considering the discussion above, but the code would require a fair amount of work.

[ppete2]

What is the current strategy in rendering "man_made=dyke" and "embankment=yes" ?

I think it would be a very good idea that both tags get rendered. They are well defined and popular used in OSM. In the blog of #823 (comment) there are nice examples how it's possible to render them in a satisfying visual apperance.

Right now I noticed some tagging-for-the-renderer to tag embankments of highways and even dykes (without a highway on top of it - they are build for prevention of flooding) with to 2 parallel lines of "man_made=embankment" - although a dyke or an embankment of a highway is just one mapping object/feature.

[Adamant36]

What is the current strategy in rendering "man_made=dyke" and "embankment=yes" ?

Rendering of barrier=embankment was removed in #4010. I/m not super up on why it was removed, but I image there would be similar reasons to not render embankment=yes.

[imagico]

Before someone makes the wrong assumptions due to incomplete information paired with speculation - the reasons for removing rendering of barrier=embankment are explained in #3744. See also #4124 (comment) for a summary of the current state of rendering of embankments and similar features here.

[ppete2]

I want to ask again: Why is "man_made=dyke" (Dykes without highways) as well as "highway=*" + "embankment=dyke" (Dykes with highways) not rendered?

I think Dykes are a feature within the countryside which should be visible on a detailed map, like man_made = embankment or natural=cliff for example.

They are well defined https://wiki.openstreetmap.org/wiki/Tag:man_made%3Ddyke and popular used in OSM. In the blog of #823 (comment) there are nice examples how it's possible to render them in a satisfying visual apperance.

[imagico]

To answer the question: Because no one has implemented this and submitted a pull request here.

The main difficulty is that good quality rendering of dykes with roads/paths on top (highway=* + man_made=dyke or highway=* + embankment=*) requires rendering to be adjusted to the road line signature. This is perfectly doable as demonstrated in the ac-style but it is not trivial. I would be in support of adding something like that to OSM-Carto but i cannot speak for the other maintainers in that regard.

If anyone needs help understanding the ac-style implementation feel free to ask.

[fgnievinski]

This is perfectly doable as demonstrated in the ac-style

here are the main portions:

• https://github.com/imagico/osm-carto-alternative-colors/blob/master/style%2Fbarriers.mss#L293
• https://github.com/imagico/osm-carto-alternative-colors/blob/master/sql%2Froads.sql#L481