I would hope that a scheme can be had that is one sided - and the same for cliff, embankment, cutting etc.

As such it should be one sided. After all another side could have a different slope/area. A single sided scheme could be used for 2 sided or multi sided structures by many separate one sided OSM entries, as many entries as required to represent the structure. In this way the name of the structure has less relevance ... when does an embankment become a cutting? A cutting a cliff? If the result is the same .. then it does not really matter what it it called, avoids arguments of things like masts vs tower, monument vs memorial.

One rendering, not OSM based, has cliffs in pink, the top with spikes pointing downwards and the vertical rise stated as a number in meters.

On 30-Nov-16 09:57 AM, Lorenzo "Beba" Beltrami wrote:
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.

Lorenzo

[1] https://en.wikipedia.org/wiki/Levee#River_flood_prevention <https://en.wikipedia.org/wiki/Levee#River_flood_prevention> [2] http://www.navecorsara.it/wp/wp-content/uploads/2010/01/Stirone_argine_1-580x435.jpg [3] http://bur.regione.veneto.it/resourcegallery/photos/465_Guarda%20Veneta_ro_Panorama%20con%20argine.jpg

2016-11-29 23:28 GMT+01:00 Kevin Kenny <kevin.b.kenny+...@gmail.com <mailto:kevin.b.kenny+...@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
    
<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 <vosc...@gmail.com
    <mailto:vosc...@gmail.com>> wrote:



        On 29 November 2016 at 22:03, Warin <61sundow...@gmail.com
        <mailto:61sundow...@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
            <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 <mailto:Tagging@openstreetmap.org>
            https://lists.openstreetmap.org/listinfo/tagging
            <https://lists.openstreetmap.org/listinfo/tagging>

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

Reply via email to