[Tagging] better mapping for embankments / slopes

[Warin]

Not all embankment have 2 slopes .. nor does a 'slope' describe all of 
the properties of an embankment. The same problem exists for a 'cliff' 
and a 'cutting' ... and stairs that cover a large area. So use what has 
been done for them as a guide.

What are the key properties of these features ...

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 <mailto: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 <mailto:Tagging at openstreetmap.org>
>     https://lists.openstreetmap.org/listinfo/tagging
>     <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/20161130/80962228/attachment.html>