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
<dieterdre...@gmail.com <mailto:dieterdre...@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@openstreetmap.org <mailto:Tagging@openstreetmap.org>
https://lists.openstreetmap.org/listinfo/tagging
<https://lists.openstreetmap.org/listinfo/tagging>
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
