[Tagging] better mapping for embankments / slopes

Lorenzo "Beba" Beltrami lorenzo.beba at gmail.com
Tue Nov 29 22:57:12 UTC 2016

It makes sense that a road embankment have only one slope.

Perhaps for a levee[1] we need a specific tagging system because a levee
has always two slopes.

I'm native of the Po Valley where levees are along every river (Volker can
confirm it ;) ).
A levee for flood prevention could be simple[2] but even a wide and complex
feature[3] to map.


[1] https://en.wikipedia.org/wiki/Levee#River_flood_prevention

2016-11-29 23:28 GMT+01:00 Kevin Kenny <kevin.b.kenny+osm at gmail.com>:

> 'Embankment' is frequently used for a built-up structure on a steep
> hillside that keeps a road, railroad, or similar feature from sliding into
> a gorge or river. See https://en.wikipedia.org/wiki/
> Embankment_%28transportation%29#/media/File:Embankment_1_%28PSF%29.png
> for an illustration from Wikipedia. Except for the portion crossing the
> tributary stream, the road in the picture is clearly NOT banked on the
> uphill side, so the embankment here is what Warin was describing as
> 'one-sided.'
> Locally to me, this is the commonest sense of the word.
> I am a native speaker of American English, and I live in terrain heavily
> sculpted by the glaciers of the last Ice Age, where highway and railroad
> embankments are relatively common.
> On Tue, Nov 29, 2016 at 4:34 PM, Volker Schmidt <voschix at gmail.com> wrote:
>> On 29 November 2016 at 22:03, Warin <61sundowner at gmail.com> wrote:
>>> Not all embankment have 2 slopes
>> To my understanding of the English term, an "embankment" is the
>> equivalent of dyke or levee and is a long, narrow man-made elevation.
>> Therefore they always have two slopes of opposite directions (leaving out
>> the ends)
>> What Martin proposes should get a different tag name to distinguish it
>> from an embankment. The term "on-sided enmbankment" is used in OSM for
>> this, but I do not like it at all. I strongly recommend to use a different
>> tag name. I used "slope" as this is the term used to describe the inclined
>> flanks of levees (=embankments).
>> Length - simple set as the length of the way. Cliffs are tagged as a
>> single way at the top of the cliff, with the right hand side being
>> 'downwards' when facing the direction of the way.
>> Vertical rise - could be tagged with the height key.. this can vary over
>> the length of the feature (I have found this on some maps as a number in
>> meters ... assumed to be the maximum vertical locally rise in meters) To
>> accomodate teh change in vertical height .. put the height on individual
>> nodes?
>> Slope - or in OSM terms 'incline'. This in OSM is entered as a way along
>> the top where the slope would be minimal and not what 'we' want to
>> describe. ... as cliffs, cuttings and embankments are best described this
>> way I think incline may not be the best thing to tag? Humm stairs are
>> described using the incline key ... but on a way that goes up .. leaving
>> the top and bottom free of this. So maybe a top and bottom way .. with a
>> simple way from bottom to top containing the incline information?
>> While the 'top' and 'bottom' of natural features can be a bit fuzzy they
>> are features that should be mapped. Definition? Something for a geologist?
>> Along the lines of the line formed by the intersection of the average slope
>> of land before the change to the average slope of land after the change (
>> the change being the cliff, embankment or cutting)?
>> On 30-Nov-16 01:25 AM, Volker Schmidt wrote:
>>> If you want to micromap slopes you should create a new key "slope" or
>>> something similar. An embankment has two slopes. It is equivalent to dyke
>>> or levee. The one-side embankments that are defined in the OSM wiki, are in
>>> reality slopes and should be retagged accordingly.
>>> Independently of the name used fo the tag I see the prblem of defining
>>> where the slope starts, normally these are rounded features.
>>> On 29 November 2016 at 13:48, Martin Koppenhoefer <
>>> dieterdreist at gmail.com> wrote:
>>>> Currently we are mapping only one side of the embankment (I think it's
>>>> the upper side, but am not sure if the wiki says this explicitly), with the
>>>> direction. What we would IMHO need is a way to map the lower side as well
>>>> and to combine both. A closed polygon will not work I believe.
>>>> The obvious solution that comes to mind is a new relation type: in case
>>>> the upper end is mapped, draw a new way for the lower end and combine both
>>>> with a relation (possibly assigning roles like upper and lower, maybe also
>>>> draw lateral ways (ways that connect the ends of the upper and lower ways
>>>> and defines their shape) in cases they are not straight). (The type=area
>>>> relation does this)
>>>> Maybe it could also be done without the relation, simply by tagging the
>>>> upper and lower ways accordingly, and connect them at least at one of their
>>>> ends with an explicit lateral way (and respective tags). This would require
>>>> from the data user to topologically search for the embankment area in order
>>>> to be able to render it (or make other use).
>>>> What do you think, which representation is better? Are there
>>>> alternatives?
>>>> Cheers,
>>>> Martin
>>>> _______________________________________________
>>>> Tagging mailing list
>>>> Tagging at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/tagging
>>> _______________________________________________
>>> Tagging mailing listTagging at openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>> _______________________________________________
>>> Tagging mailing list
>>> Tagging at openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20161129/2b54af77/attachment-0001.html>

More information about the Tagging mailing list