[Tagging] better mapping for embankments / slopes

Kevin Kenny kevin.b.kenny+osm at gmail.com
Tue Nov 29 22:28:10 UTC 2016


'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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20161129/c9f79b40/attachment.html>


More information about the Tagging mailing list