Re: [Tagging] better mapping for embankments / slopes

[John Willis]

Javbw
> On 30 Nov 2016, at 7:28 AM, Kevin Kenny  wrote:
> 
> '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.

So a retaining wall (or reinforced "retaining slope"?) is when an embankment / 
cutting is covered with a man made structure, like concrete, bricks,rocks, or a 
soil-nail wall?  

So a road in a "cutting" could be surrounded by an embankment or a retaining 
wall? 

Here are some terraced embankments cut into the ground. They are bare rock.  
The motorway here is 40-50m below ground level - they removed an entire 
mountain to make this deep cutting. The two sides used to be connected by a 
single gentle slope before. 

https://goo.gl/maps/8X3uiCNq1JH2

In my home town in Japan they cut away a hillside, Forming 3 terraced 
embankments, to widen a train line going into town. 

http://www.openstreetmap.org/#map=18/36.41246/139.32270

If you are going to have relations of top and bottom, I think you also need 
"side" - often the ends are an angle, ending up looking like a trapezoid. 

Javbw ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] better mapping for embankments / slopes

[Kevin Kenny]

I render the things that OSM shows as cliffs, because sometimes surprises
lurk between the contour lines. Otherwise, when I care, on my own maps I
render elevation contours (and hence have no use for the cliff height in
the data base). In a spot like
https://kbk.is-a-geek.net/catskills/test3.html?la=42.1876=-74.0397=14,
it's pretty obvious that there are cliffs about.

I do like the idea of having some sort of object for cuts and fills,
because they're important features that often aren't in the elevation
databases. Highway and rail embankments would kind of come along for the
ride.

On Tue, Nov 29, 2016 at 6:08 PM, Warin <61sundow...@gmail.com> wrote:

> 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
> [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 :
>
>> '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 
>> wrote:
>>
>>>
>>>
>>> On 29 November 2016 at 22:03, Warin <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. 

Re: [Tagging] better mapping for embankments / slopes

[Warin]

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 

[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 >:


'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 > wrote:



On 29 November 2016 at 22:03, Warin <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 

Re: [Tagging] better mapping for embankments / slopes

[Lorenzo "Beba" Beltrami]

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
[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 :

> '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  wrote:
>
>>
>>
>> On 29 November 2016 at 22:03, Warin <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> 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 

Re: [Tagging] better mapping for embankments / slopes

[Kevin Kenny]

'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  wrote:

>
>
> On 29 November 2016 at 22:03, Warin <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 > > 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
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>>
>>
>>
>> ___
>> Tagging mailing 
>> listTagging@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/tagging
>>
>>
>>
>> 

Re: [Tagging] better mapping for embankments / slopes

[Volker Schmidt]

On 29 November 2016 at 22:03, Warin <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 
> 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
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>>
>
>
> ___
> Tagging mailing 
> listTagging@openstreetmap.orghttps://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

Re: [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 
> 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 
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

Re: [Tagging] better mapping for embankments / slopes

[Volker Schmidt]

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 
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
> https://lists.openstreetmap.org/listinfo/tagging
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] better mapping for embankments / slopes

[Martin Koppenhoefer]

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

Re: [Tagging] Key:visibility

[markus schnalke]

[2016-11-29 11:10] Martin Koppenhoefer 
> 2016-11-29 7:02 GMT+01:00 markus schnalke :
> 
> This is just like the smoothness=* case. Instead of having values
> like ``excellent'', ``bad'' or ``horrible'', we now learned that
> it is better to tag for what cases some smoothness is okay. The
> same here: You'll always need the explanations above if you use
> the values ``house'', ``street'' and ``area'', but you can get
> rid of them if you just use the explanations themselves:
> 
>         - visibility=for_walkers
>         - visibility=for_slow_cars
>         - visibility=for_fast_cars
> 
> 
> I tend to disagree, the values you propose are more specific and not
> universally applicable (this is not about speed, but about scale, these new
> values would suggest to take into account other aspects like "visibility from
> within a car on the street", not applicable in many cases).

You are right. It should be about distance, not about position nor
speed.


Maybe that's the aspect that I don't like about the value ``street''
(although my suggested values were no better ;-) ): It indicates
position.

If you talk about scale then a set of ``house_scale'',
``street_scale'', ``district_scale'' or so could become universal
scale specifiers to be used in other situations as well. (Here I
would tend to use ``house_scale'' instead of ``building_scale'',
because buildings can be really large -- as large as streets --
whereas houses are usually within a quite limited size range.)


meillo

___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Key:visibility

[Martin Koppenhoefer]

2016-11-29 7:02 GMT+01:00 markus schnalke :

> This is just like the smoothness=* case. Instead of having values
> like ``excellent'', ``bad'' or ``horrible'', we now learned that
> it is better to tag for what cases some smoothness is okay. The
> same here: You'll always need the explanations above if you use
> the values ``house'', ``street'' and ``area'', but you can get
> rid of them if you just use the explanations themselves:
>
> - visibility=for_walkers
> - visibility=for_slow_cars
> - visibility=for_fast_cars
>


I tend to disagree, the values you propose are more specific and not
universally applicable (this is not about speed, but about scale, these new
values would suggest to take into account other aspects like "visibility
from within a car on the street", not applicable in many cases).

I believe the originally proposed values are fine (besides the "house"
maybe"), they do give an indication about scale. I also think that
mentioning distances can generally be OK, given as an rough idea how to
read the values, but not as very strict limits. What is not OK are the
actual values: they seem off (too small) for what I believe is "street
scale", "area scale" or "within the building scale". It could also be
"small", "medium", "large" or "close", "medium distance", "far", but these
would give even less indication as to what scale it is about (they are
completely relative, without a point of reference, like street or building
do give), so the current proposal is better in that concern.

Cheers,
Martin
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging