Additional detail of Levee mapping via embankments

classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Additional detail of Levee mapping via embankments

Tagging mailing list
As related to my other posts, I am mapping large water containment features.

When I began mapping, I often mapped embankments & retaining walls used for roads and infrastructure, and during that time, the embankment tag evolved to support two embankment lines that would denote the top and bottom of the extent of the embankments. This was perfect for me, as there are many tollways that sit on a large man-made embankments as they cut trough the countryside. Most tollways in Japan are elevated on fill to make crossings (via tunnels) much easier, as they cross so many existing small roads. mapping the extent of the embankments clearly shows the footprint of the tollways through the countryside - much greater than any trunk road. 

https://www.openstreetmap.org/#map=17/36.33635/139.40197 - Kita-Kanto expressway near Ota-Kiryu IC & Watarase River


As I mapped the embankments, I started mapping the levee embankments as well, as they are not uniform in shape, with natural and man-made features making their shape highly irregular on both the top and bottom, the two sets of embankments easily outlining these huge features (usually between 6-12m tall and 20-60m wide). They usually have a 2-10m wide “top” on the levee. They similarly have a huge footprint compared to other features. 

Recently, I realized there is a man_made=dyke tag that is supposed to map the “top” of the levee, but there is no documented way to map the *extent* of these large flood control features, which feels incorrect.

https://www.openstreetmap.org/#map=17/36.23909/139.68483 - the extent of these levees is much greater than the cycling roads on top. 

I am going to continue to map the extent of these large man-made levee embankments as 2 pairs of embankment lines, and I'll now go back and map the levee top with a man_made=dyke line, denoting the “levee route”. I’m guessing there are 500km of these large levees in the greater Tokyo area alone, with more than a thousand km of somewhat smaller ones. 

The levees follow the river through open plains, but their route often is constrained occasionally by natural features, where the outer-side of the levee is a natural rise for a short distance, but the inner-side is still a continuous man-made embankment. being able to separate the almost always continuous levee from the extent of it’s two embankments (which merge, separate, appear, and disappear) is very useful. 

https://www.openstreetmap.org/#map=17/36.23164/139.31544 - levees meet and end as one river joins another. Their size varies greatly, denoted by the embankment lines. 

I feel this should be accepted mapping for extremely large levees, such as the ones I am dealing with, where the =dyke way cannot properly express the extent of the levee’s breadth and complexity, and the “Top” of the levee is not always the center of the structure. 

Is it useful to turn this into a relation? with levee embankment members being inner-bottom, inner-top, outer-bottom, outer-top and the man_made=dyke member  being the “route" of the levee? Maybe it isn’t important to relate them. I don’t know.

Thoughts? 

Javbw 


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Joseph Eisenberg
> They usually have a 2-10m wide “top” on the levee

The tag man_made=embankment should always be placed at the top of the
embankment, so your two lines will only be 2 to 10 meters apart. This
tag is not meant to show the size of the embankment or levee, but the
location of the top of the steep slope. In this usage it is similar to
natural=cliff and barrier=retaining_wall

"it should be tagged on a way drawn with the lower side on right side
of way direction" - Tag:man_made=embankment

If you map the levee as man_made=dyke you can add width=* to each
segment to show how wide it is; this is much faster for mapping, and a
well-designed renderer should be able to show these nicely.

If anyone really wants to map the whole area of the levee, I would
suggest a new tag like area:man_made=dyke - but I think this is not a
good use of mapper time.

If the levee ("dyke") is very large, it should be visible clearly in a
DEM (digital elevation model), like natural hills, slopes and cliffs.
We do not map elevation contours or data in OSM, because a
high-resolution DEM works very well of this, but a vector database
does not.

- Joseph Eisenberg

On 11/11/19, John Willis via Tagging <[hidden email]> wrote:

> As related to my other posts, I am mapping large water containment
> features.
>
> When I began mapping, I often mapped embankments & retaining walls used for
> roads and infrastructure, and during that time, the embankment tag evolved
> to support two embankment lines that would denote the top and bottom of the
> extent of the embankments. This was perfect for me, as there are many
> tollways that sit on a large man-made embankments as they cut trough the
> countryside. Most tollways in Japan are elevated on fill to make crossings
> (via tunnels) much easier, as they cross so many existing small roads.
> mapping the extent of the embankments clearly shows the footprint of the
> tollways through the countryside - much greater than any trunk road.
>
> https://www.openstreetmap.org/#map=17/36.33635/139.40197
> <https://www.openstreetmap.org/#map=17/36.33635/139.40197> - Kita-Kanto
> expressway near Ota-Kiryu IC & Watarase River
>
>
> As I mapped the embankments, I started mapping the levee embankments as
> well, as they are not uniform in shape, with natural and man-made features
> making their shape highly irregular on both the top and bottom, the two sets
> of embankments easily outlining these huge features (usually between 6-12m
> tall and 20-60m wide). They usually have a 2-10m wide “top” on the levee.
> They similarly have a huge footprint compared to other features.
>
> Recently, I realized there is a man_made=dyke tag that is supposed to map
> the “top” of the levee, but there is no documented way to map the *extent*
> of these large flood control features, which feels incorrect.
>
> https://www.openstreetmap.org/#map=17/36.23909/139.68483
> <https://www.openstreetmap.org/#map=17/36.23909/139.68483> - the extent of
> these levees is much greater than the cycling roads on top.
>
> I am going to continue to map the extent of these large man-made levee
> embankments as 2 pairs of embankment lines, and I'll now go back and map the
> levee top with a man_made=dyke line, denoting the “levee route”. I’m
> guessing there are 500km of these large levees in the greater Tokyo area
> alone, with more than a thousand km of somewhat smaller ones.
>
> The levees follow the river through open plains, but their route often is
> constrained occasionally by natural features, where the outer-side of the
> levee is a natural rise for a short distance, but the inner-side is still a
> continuous man-made embankment. being able to separate the almost always
> continuous levee from the extent of it’s two embankments (which merge,
> separate, appear, and disappear) is very useful.
>
> https://www.openstreetmap.org/#map=17/36.23164/139.31544
> <https://www.openstreetmap.org/#map=17/36.23164/139.31544> - levees meet and
> end as one river joins another. Their size varies greatly, denoted by the
> embankment lines.
>
> I feel this should be accepted mapping for extremely large levees, such as
> the ones I am dealing with, where the =dyke way cannot properly express the
> extent of the levee’s breadth and complexity, and the “Top” of the levee is
> not always the center of the structure.
>
> Is it useful to turn this into a relation? with levee embankment members
> being inner-bottom, inner-top, outer-bottom, outer-top and the man_made=dyke
> member  being the “route" of the levee? Maybe it isn’t important to relate
> them. I don’t know.
>
> Thoughts?
>
> Javbw
>
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list


On Nov 11, 2019, at 11:16 AM, Joseph Eisenberg <[hidden email]> wrote:

"it should be tagged on a way drawn with the lower side on right side
of way direction" - Tag:man_made=embankment

for some reason, I remember reading documentation about using a pair of embankment lines to denote the extent of the embankment, using the direction of their ways as an indicator. I didn’t come up with that on my own. this was during the embankment=yes => man_made=embankment change. 

 - I really love the top-lines of the embankments, as these embankment tops are not uniform in shape - but I will delete them if it is bad tagging. 

- if I delete the “top” lines of the embankments, and use the man_made=dyke as the center of the summit of the levee, would there be some advantage to putting it and the embankments into a relation for possible better rendering of their extent (shading, hashes, etc)?.

- Because the levees vary wildly in shape on the top, sometimes widening for a short area to 50-100m wide, would repurposing the top-line embankment ways as mapped to tagged with some kind-of “riverbank-style” tag, where the man_made=dyke way shows the path, and man_made=dyke on a polygon shows the extent, similar to how natural=river is used now? for smaller levees, this detail is unnecessary, but for such large features used by so many people, the detail would be nice. it is very easy to map their extents, especially since I am doing the mapping via ground survey on a bike 70-100km at a time.

examples of the levee top widening for a short space, usually for levee break emergency repair stations (large caches of breakwater blocks with helicopter/crane hooks, stationed above the flood zone on top of the levee). 


I really want to map the levees in as much detail as I can, as detail often helps with map interpretation (at high zoom levels) while travelling along the levees by car or bike, but few people seem to be interested in them. 


Javbw

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Joseph Eisenberg
> I really love the top-lines of the embankments, as these embankment tops are not uniform in shape - but I will delete them if it is bad tagging.

It's not bad tagging, you should keep these. (make sure that the lower
side is on the right hand of way direction)

> would there be some advantage to putting it [man_made=dyke line] and the embankments into a relation

It isn't necessary OSM relations for things that can be determined by
the database users just by looking at the spacial relationship between
two features. In this case, database users could look for
man_made=dyke ways which are roughly parallel and close to a
man_made=embankment way.

> man_made=dyke way shows the path, and man_made=dyke on a polygon shows the extent ... similar to how natural=river is used

We use two tags for rivers: `waterway=riverbank` (or natural=water +
water=river) for the area and waterway=river for the central line of
the river.

If you want to do this, you need a different tag for the area. My
suggestion was area:man_made=dyke, in analogy to area:highway, but
man_made=dyke_area or =embankment_area would work, or any other new
tag with a clear meaning.

On 11/11/19, John Willis <[hidden email]> wrote:

>
>
>> On Nov 11, 2019, at 11:16 AM, Joseph Eisenberg
>> <[hidden email]> wrote:
>>
>> "it should be tagged on a way drawn with the lower side on right side
>> of way direction" - Tag:man_made=embankment
>
> for some reason, I remember reading documentation about using a pair of
> embankment lines to denote the extent of the embankment, using the direction
> of their ways as an indicator. I didn’t come up with that on my own. this
> was during the embankment=yes => man_made=embankment change.
>
>  - I really love the top-lines of the embankments, as these embankment tops
> are not uniform in shape - but I will delete them if it is bad tagging.
>
> - if I delete the “top” lines of the embankments, and use the man_made=dyke
> as the center of the summit of the levee, would there be some advantage to
> putting it and the embankments into a relation for possible better rendering
> of their extent (shading, hashes, etc)?.
>
> - Because the levees vary wildly in shape on the top, sometimes widening for
> a short area to 50-100m wide, would repurposing the top-line embankment ways
> as mapped to tagged with some kind-of “riverbank-style” tag, where the
> man_made=dyke way shows the path, and man_made=dyke on a polygon shows the
> extent, similar to how natural=river is used now? for smaller levees, this
> detail is unnecessary, but for such large features used by so many people,
> the detail would be nice. it is very easy to map their extents, especially
> since I am doing the mapping via ground survey on a bike 70-100km at a
> time.
>
> examples of the levee top widening for a short space, usually for levee
> break emergency repair stations (large caches of breakwater blocks with
> helicopter/crane hooks, stationed above the flood zone on top of the levee).
>
>
> https://www.openstreetmap.org/#map=18/36.30063/139.51192
> <https://www.openstreetmap.org/#map=18/36.30063/139.51192>
> https://www.openstreetmap.org/#map=18/36.26097/139.63921
> <https://www.openstreetmap.org/#map=18/36.26097/139.63921>
> https://www.openstreetmap.org/#map=17/35.97705/139.89813
> <https://www.openstreetmap.org/#map=17/35.97705/139.89813>
>
> I really want to map the levees in as much detail as I can, as detail often
> helps with map interpretation (at high zoom levels) while travelling along
> the levees by car or bike, but few people seem to be interested in them.
>
>
> Javbw

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list


> On Nov 11, 2019, at 12:52 PM, Joseph Eisenberg <[hidden email]> wrote:
>
> We use two tags for rivers: `waterway=riverbank` (or natural=water +
> water=river) for the area and waterway=river for the central line of
> the river.



Thanks so much for all of the clear and thoughtful replies.

I sometimes mess up tagging schemes or tag names during discussions, and it leads to confusion, but this was a total misunderstanding of embankments.

It seems I was (very) confused, possibly by misreading it several different times. I have mapped 40km of levees wrong, with an improper lower bounds line. I’ll have to fix it.

I now understand that my embankment lines at the top are the (only) proper way to map the edge of the embankment.

I am interested in mapping the extent of the levee/embankments with some kind of outer/lower line, either as a single area or as 2 related ways for a levee.

it is interesting to me that a levee is a way that marks the “centerline", while the embankment maps the top edge of the slope - yet there is no documented way to map the *area* of the levees nor embankments. my “lower” embankment line (which is apparently very bad mapping) makes the extent of the embankments that make up a levee. while they sound simple, our levees are *covered with* parallel and intersecting roads. some levees will have 5 parallel ways on them for different kinds of traffic. similar to man_made=bridge, showing the area used by a bridge is very useful.

to me, both man_made=embankment and man_made=dyke need a way to express the area they take up, because mapping via a width value varies too much to be mappable, especially when they are in very complicated shapes - and very easily mapped via imagery.

to me, these levees are not only a major feature worth mapping, but considerably helpful to understand the mapping in an area. They are very large artificial barriers which greatly restrict access, as well as one of the few safe places during a typhoon.

I will think about how area:man_made=embankment & area:man_made:levee would be useful compliments to the existing tagging without requiring any changes to the existing tags.

There is a big discussion on the tag discussion page ( https://wiki.openstreetmap.org/wiki/Talk:Tag:man_made%3Dembankment ) about mapping embankments by area using the existing man_made=embankment on a closed way (only generating an area when paired with area=yes), but in that case there is no way to tell which side of the area is the “top” of the embankment, which is the intended data the line is meant to represent.


Your comments have been extremely useful/helpful, thanks.

Javbw
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

dieterdreist
Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <[hidden email]>:
It seems I was (very) confused, possibly by misreading it several different times. I have mapped 40km of levees wrong, with an improper lower bounds line. I’ll have to fix it.
I now understand that my embankment lines at the top are the (only) proper way to map the edge of the embankment.
I am interested in mapping the extent of the levee/embankments with some kind of outer/lower line, either as a single area or as 2 related ways for a levee.



I agree we should have a way to map both limits, upper and lower, for all kind of similar features, e.g. embankments, slopes, and similar. A relation seems easier to evaluate and explicit, while a spatial query heuristic will inevitably fail in some cases (lets not forget that we cannot assume that OSM data is complete, having mapped the upper boundary of one embankment and the lower of another, in proximity, and not having mapped the other upper and lower boundaries, would not be considered an "error", just incomplete data).


 
it is interesting to me that a levee is a way that marks the “centerline", while the embankment maps the top edge of the slope - yet there is no documented way to map the *area* of the levees nor embankments. my “lower” embankment line (which is apparently very bad mapping) makes the extent of the embankments that make up a levee. while they sound simple, our levees are *covered with* parallel and intersecting roads.
some levees will have 5 parallel ways on them for different kinds of traffic. similar to man_made=bridge, showing the area used by a bridge is very useful.


maybe in case a road cuts through an embankment, you would have to map several embankments (upper and lower boundaries) to represent it?

Cheers
Martin

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

voschix
I have stood in front of these large levees that prevent big rivers from flooding the surrounding country side many times her in Italy and did not find a suitable tagging for both the top and the bottom border lines of the object.

We have a similar problem with extended stairs for which there is a tagging scheme, which could be transferred to the levee situation. I am  not an expert in either levees nor staircase modelling - I only note the similarity of the problems.

On Mon, 11 Nov 2019 at 10:16, Martin Koppenhoefer <[hidden email]> wrote:
Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <[hidden email]>:
It seems I was (very) confused, possibly by misreading it several different times. I have mapped 40km of levees wrong, with an improper lower bounds line. I’ll have to fix it.
I now understand that my embankment lines at the top are the (only) proper way to map the edge of the embankment.
I am interested in mapping the extent of the levee/embankments with some kind of outer/lower line, either as a single area or as 2 related ways for a levee.



I agree we should have a way to map both limits, upper and lower, for all kind of similar features, e.g. embankments, slopes, and similar. A relation seems easier to evaluate and explicit, while a spatial query heuristic will inevitably fail in some cases (lets not forget that we cannot assume that OSM data is complete, having mapped the upper boundary of one embankment and the lower of another, in proximity, and not having mapped the other upper and lower boundaries, would not be considered an "error", just incomplete data).


 
it is interesting to me that a levee is a way that marks the “centerline", while the embankment maps the top edge of the slope - yet there is no documented way to map the *area* of the levees nor embankments. my “lower” embankment line (which is apparently very bad mapping) makes the extent of the embankments that make up a levee. while they sound simple, our levees are *covered with* parallel and intersecting roads.
some levees will have 5 parallel ways on them for different kinds of traffic. similar to man_made=bridge, showing the area used by a bridge is very useful.


maybe in case a road cuts through an embankment, you would have to map several embankments (upper and lower boundaries) to represent it?

Cheers
Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list
In reply to this post by dieterdreist


On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <[hidden email]> wrote:

I agree we should have a way to map both limits, upper and lower, for all kind of similar features, e.g. embankments, slopes, and similar.


On Nov 11, 2019, at 7:40 PM, Volker Schmidt <[hidden email]> wrote:

I have stood in front of these large levees that prevent big rivers from flooding the surrounding country side many times her in Italy and did not find a suitable tagging for both the top and the bottom border lines of the object.


I think it is pretty easy to make a  “lower bounds” way or area (or both) that compliments the existing man_made=embankment way.  

To me, the problem is levees. After having mapped many KM of levees (incorrectly), it is really really nice having the two pairs of embankments make up the two halves of the levee, because it is easier and more flexible to map the two slopes (which widen and narrow, split & merge, and disappear for short sections), rather than trying to assume that the man_made=dyke centerline way accurately shows the the “top” of the levee. the top varies by width from something easily represented by way to something 50m wide in some places (as linked to earlier). The =dyke way should represent the inner-most extent of the high point of the levee (if it has a weird bulge in the top). 

I made 2 sections of mapping examples on a simple section of levee along the Tone River that has a levee breach repair station on top, so the levee is wider here than normal. (for a short time).  


a man_made=dyke (on the cycle path) with:


- two pairs of embankment lines   ( man_made=embankment + man_made=embankment_lower ) with a regular grass polygon sandwiched between it.


- Two regular embankment lines along the top with an area:man_made=embankment polygon representing the slope (also tagged with grass). 



Do you need a relation on them? 

Any suggestions on improvements? 

Javbw

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list


On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg <[hidden email]> wrote:

If you are mapping an area, as in this case, just use a closed way or multipolygon.

How would a closed way (area polygon) denote “top” and “Bottom”? 

if embankments can be easily expressed as a single simple polygon, how data users infer “top” and "bottom” from that is beyond me. 

That is the issue: I don’t understand how a polygon would represent that, and I think those two different pieces of mapping need to be explicitly tagged. 

Perhaps it is because while I have 3000+ edits, I rarely use relations or other complex mapping data structures, nor understand exactly what data consumers can infer from data vs what they need explicitly tagged to be useful (as I am not a data user) - but I assume that “top” and "Bottom” are difficult to infer, as slope data needs to be explicitly tagged to ways. 

I thought that the way (man_made=embankment [top]) + a polygon to represent the bank (area:man_made=embankment) would, together, represent the top and the area of the embankment, allowing inference of the direction of the slope. Perhaps an additional line for “bottom” would be necessary too. 

Two embankments would represent the slopes of the levee, while the man_made=dyke way would represent the path of the protection structure as a whole, as the embankments (particularly the outer one) are not continuous - but the levee (as a complete structure) is continuous. 


Javbw
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Richard Z.
On Tue, Nov 12, 2019 at 01:53:55PM +0900, John Willis via Tagging wrote:

>
>
> > On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg <[hidden email] <mailto:[hidden email]>> wrote:
> >
> > If you are mapping an area, as in this case, just use a closed way or multipolygon.
>
> How would a closed way (area polygon) denote “top” and “Bottom”?
>
> if embankments can be easily expressed as a single simple polygon, how data users infer “top” and "bottom” from that is beyond me.
>
> That is the issue: I don’t understand how a polygon would represent that, and I think those two different pieces of mapping need to be explicitly tagged.

do not search the problem on your side of the screen:)

We need new tags for the bottom of embankmets, top of cuttings, bottom of cliffs, earth_banks
and maybe a few others if we want to map them.

Imho all those should be tagged ways such as cliff:base, relations could be used optionaly
to relate a particular cliff edge to a particular cliff base which would define the
area of the slope.

Here is what I see:
* man_made=embankment_base or man_made=embankment:base
* man_made=cutting or man_made=cutting:top - top edge of cutting in analogy to
  man_made=embankment (126 pieces in database but straightforward to extend)
* natural=cliff_base or natural=cliff:base
* natural=earth_bank_base or natural=earth_bank:base

I would favor the ":" variants, it might have been nicer if we had a scheme like
cliffe:edge and cliff:base and same for cutting, embankment, earth_bank from the
beginning. The "old" defs like man_made=cutting can be left or man_made=cutting:base
can be defined as an alias.

Richard

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Graeme Fitzpatrick


On Wed, 13 Nov 2019 at 05:05, Richard <[hidden email]> wrote:

We need new tags for the bottom of embankmets, top of cuttings, bottom of cliffs, earth_banks
and maybe a few others if we want to map them.

Imho all those should be tagged ways such as cliff:base, relations could be used optionaly
to relate a particular cliff edge to a particular cliff base which would define the
area of the slope.

Here is what I see:
* man_made=embankment_base or man_made=embankment:base
* man_made=cutting or man_made=cutting:top - top edge of cutting in analogy to
  man_made=embankment (126 pieces in database but straightforward to extend)
* natural=cliff_base or natural=cliff:base
* natural=earth_bank_base or natural=earth_bank:base

Just a thought - how about a new area tag to show the "sides" of these features, something like natural=slope?

You have your line to mark the top edge of the cliff or embankment, then mark the visible area of the wall / side / bank down to it's base as the =slope, which would be much simpler than mucking around with relations (which I, & apparently quite a few others, don't really understand?)

Could also have height to say this bank is 5m tall; normal land cover tags would apply to say it's grass, scrub, bare rock etc; incline to show it's at 45° & so on.

Would also be nice if it rendered, perhaps as either fine diagonals or cross-hatching (of course, the ideal would be if it rendered like map contour lines - on a gentle slope the lines are wide apart, getting narrower together as it get's steeper :-))

& when I've just had a look, natural=slope has actually been used 1466 times, https://taginfo.openstreetmap.org/tags/natural=slope#overview, despite being undocumented - searching the wiki for "slope" takes you to the "incline" page https://wiki.openstreetmap.org/wiki/Key:incline, which appears to for intended for roads?

Possible?

  Thanks

Graeme

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Richard Z.
On Wed, Nov 13, 2019 at 07:04:42AM +1000, Graeme Fitzpatrick wrote:

> On Wed, 13 Nov 2019 at 05:05, Richard <[hidden email]> wrote:
>
> >
> > We need new tags for the bottom of embankmets, top of cuttings, bottom of
> > cliffs, earth_banks
> > and maybe a few others if we want to map them.
> >
> > Imho all those should be tagged ways such as cliff:base, relations could
> > be used optionaly
> > to relate a particular cliff edge to a particular cliff base which would
> > define the
> > area of the slope.
> >
> > Here is what I see:
> > * man_made=embankment_base or man_made=embankment:base
> > * man_made=cutting or man_made=cutting:top - top edge of cutting in
> > analogy to
> >   man_made=embankment (126 pieces in database but straightforward to
> > extend)
> > * natural=cliff_base or natural=cliff:base
> > * natural=earth_bank_base or natural=earth_bank:base
> >
>
> Just a thought - how about a new area tag to show the "sides" of these
> features, something like natural=slope?

natural=slope could be somewhat misleading.. people would map all kind of
other slopes.

Could be natural=cliff:area ?
However because embankemnt:area would be very misleading, it would have to
become  man_made=embankment_slope:area ?

> You have your line to mark the top edge of the cliff or embankment, then
> mark the visible area of the wall / side / bank down to it's base as the
> =slope, which would be much simpler than mucking around with relations
> (which I, & apparently quite a few others, don't really understand?)

should not have even mentioned the relations, not a big fan of them either;)

So it boils down to either
* mapping the slope area
* mapping the upper and/or lower bounds of the slope area

Depending on case the one or other possibility may be better but I am not
sure they can be used together.

My feeling is that simple tagged ways (that is top and bottom edge) are more
flexible and scale better to complex cases than areas.

> Could also have height to say this bank is 5m tall; normal land cover tags
> would apply to say it's grass, scrub, bare rock etc; incline to show it's
> at 45° & so on.

We have all this already? In my experience adding height=XXX to natural=cliff
ins't very useful. The height (or width) varies along the cliff.

>
> Would also be nice if it rendered, perhaps as either fine diagonals or
> cross-hatching (of course, the ideal would be if it rendered like map
> contour lines - on a gentle slope the lines are wide apart, getting
> narrower together as it get's steeper :-))

we have other methodes for countour lines
 
> & when I've just had a look, natural=slope has actually been used 1466
> times, https://taginfo.openstreetmap.org/tags/natural=slope#overview,
> despite being undocumented - searching the wiki for "slope" takes you to
> the "incline" page https://wiki.openstreetmap.org/wiki/Key:incline, which
> appears to for intended for roads?

wondering what those slopes mean?

Richard

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list
In reply to this post by Richard Z.


> On Nov 13, 2019, at 3:44 AM, Richard <[hidden email]> wrote:
>
> We need new tags for the bottom of embankmets, top of cuttings, bottom of cliffs, earth_banks
> and maybe a few others if we want to map them.

that is very true.

I think we can cleanly do this with the ways you mentioned.

We need to chose a scheme for these “base” tags that doesn’t reinvent the wheel, isn’t vague, and can easily be interpreted. my mis-reading of embankment led to some big problems, simply because I assumed the tag could document things it couldn’t.  Your tags look really good to me.

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <[hidden email]> wrote:
>  A relation seems easier to evaluate and explicit, while a spatial query heuristic will inevitably fail in some cases


I think there is a need for a basic relation, if I understand Martin correctly, to simply associate the two lines, (for example, an =embankment and an =embankment_base pair). When mapped, they are not joined. They are merely adjacent. I am not sure of what “type” of relation to choose in iD, but I assume someone will tell us which type to use.

When mapping a simple cutting or embankment, you would have only one “base” line adjacent - so there is little ambiguity, and the relationship can be inferred (IIUC), but in complicated tagging, there could easily be a situation where which base belongs to which line is unclear, and lead to problems.

Simply putting them into a relation says “these members are related” and the renderer can know for certain that these two ways that don’t share nodes are a pair, no inference needed.

This again raises the question of levees - is the levee worthy of it’s own levee relation? do you put all 4 embankment lines into relation with the man_made=dyke line? this seems to be the only solution to:

- properly group the embankments with the levee
- not have to use super=relations (putting the embankment relations into a levee relation)
- providing the most flexibility to weird situations
- allowing for the extent of the top of the levee to be defined (large levees have varying width tops with usable areas, as shown, in which a “way” is insufficient ).

But I am unsure that this is the “only way” and perhaps putting the two embankment relations + dyke line into a levee super-relation would allow mapping of the embankments to be a uniform process (making mapping the details of levees a bit more complicated at the expense of standardized embankment mapping).


Javbw
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Joseph Eisenberg
> I think there is a need for a basic relation, ... to simply associate the two lines ... When mapped, they are not joined

The easiest way to do this is to make an area which represents the
area of the cliff, embankment, dyke (levee) or whatnot.

Have it use the same nodes as the upper and lower ways in the case of
a cliff or one-sided embankment.

For a levee it can just go around the whole levee, in which case it
may not be necessary to map the edges with some other tag. The central
way with man_made=dyke will be associated with the area because it
will be entirely inside of it. (This would also work for cuttings or
railway embankments with two sides, if you want to map them as a
single area).

You can use a relation of type=multipolygon for this, as with any
area, but a closed way works just as well in most cases, and is
probably easier to map and maintain.

This is better than creating a new type of relation, and provides all
the information that a database user might want.

(But again, please consider that places like Tokyo have very high
quality Digital Elevation Models available, now often based on laser
readings which are accurate within decimeters, so if the goal is to
create a 3D map of the surface or contour lines or shading for a map,
this is not really necessary.)

- Joseph Eisenberg

On 11/13/19, John Willis via Tagging <[hidden email]> wrote:

>
>
>> On Nov 13, 2019, at 3:44 AM, Richard <[hidden email]> wrote:
>>
>> We need new tags for the bottom of embankmets, top of cuttings, bottom of
>> cliffs, earth_banks
>> and maybe a few others if we want to map them.
>
> that is very true.
>
> I think we can cleanly do this with the ways you mentioned.
>
> We need to chose a scheme for these “base” tags that doesn’t reinvent the
> wheel, isn’t vague, and can easily be interpreted. my mis-reading of
> embankment led to some big problems, simply because I assumed the tag could
> document things it couldn’t.  Your tags look really good to me.
>
>> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <[hidden email]>
>> wrote:
>>  A relation seems easier to evaluate and explicit, while a spatial query
>> heuristic will inevitably fail in some cases
>
>
> I think there is a need for a basic relation, if I understand Martin
> correctly, to simply associate the two lines, (for example, an =embankment
> and an =embankment_base pair). When mapped, they are not joined. They are
> merely adjacent. I am not sure of what “type” of relation to choose in iD,
> but I assume someone will tell us which type to use.
>
> When mapping a simple cutting or embankment, you would have only one “base”
> line adjacent - so there is little ambiguity, and the relationship can be
> inferred (IIUC), but in complicated tagging, there could easily be a
> situation where which base belongs to which line is unclear, and lead to
> problems.
>
> Simply putting them into a relation says “these members are related” and the
> renderer can know for certain that these two ways that don’t share nodes are
> a pair, no inference needed.
>
> This again raises the question of levees - is the levee worthy of it’s own
> levee relation? do you put all 4 embankment lines into relation with the
> man_made=dyke line? this seems to be the only solution to:
>
> - properly group the embankments with the levee
> - not have to use super=relations (putting the embankment relations into a
> levee relation)
> - providing the most flexibility to weird situations
> - allowing for the extent of the top of the levee to be defined (large
> levees have varying width tops with usable areas, as shown, in which a “way”
> is insufficient ).
>
> But I am unsure that this is the “only way” and perhaps putting the two
> embankment relations + dyke line into a levee super-relation would allow
> mapping of the embankments to be a uniform process (making mapping the
> details of levees a bit more complicated at the expense of standardized
> embankment mapping).
>
>
> Javbw
> _______________________________________________
> Tagging mailing list
> [hidden email]
> https://lists.openstreetmap.org/listinfo/tagging
>

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list
(I mis-sent this email)

On Nov 13, 2019, at 3:44 AM, Richard <[hidden email]> wrote:

We need new tags for the bottom of embankmets, top of cuttings, bottom of cliffs, earth_banks 
and maybe a few others if we want to map them.

that is very true. 

I think we can cleanly do this with the ways you mentioned. 

We need to chose a scheme for these “base” tags that doesn’t reinvent the wheel, isn’t vague, and can easily be interpreted. my mis-reading of embankment led to some big problems, simply because I assumed the tag could document things it couldn’t.  Your tags look really good to me.

On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <[hidden email]> wrote:
A relation seems easier to evaluate and explicit, while a spatial query heuristic will inevitably fail in some cases


I think there is a need for a basic relation, if I understand Martin correctly, to simply associate the two lines, (for example, an =embankment and an =embankment_base pair). When mapped, they are not joined. They are merely adjacent. I am not sure of what “type” of relation to choose in iD, but I assume someone will tell us which type to use.

When mapping a simple cutting or embankment, you would have only one “base” line adjacent - so there is little ambiguity, and the relationship can be inferred (IIUC), but in complicated tagging, there could easily be a situation where which base belongs to which line is unclear, and lead to problems.

Simply putting them into a relation says “these members are related” and the renderer can know for certain that these two ways that don’t share nodes are a pair, no inference needed. 

This again raises the question of levees - is the levee worthy of it’s own levee relation? do you put all 4 embankment lines into relation with the man_made=dyke line? this seems to be the only solution to:

- properly group the embankments with the levee
- not have to use super=relations (putting the embankment relations into a levee relation)
- providing the most flexibility to weird situations
- allowing for the extent of the top of the levee to be defined (large levees have varying width tops with usable areas, as shown, in which a “way” is insufficient ). 

But I am unsure that this is the “only way” and perhaps putting the two embankment relations + dyke line into a levee super-relation would allow mapping of the embankments to be a uniform process (making mapping the details of levees a bit more complicated at the expense of standardized embankment mapping). 


Javbw

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Richard Z.
On Wed, Nov 13, 2019 at 06:54:52PM +0900, John Willis via Tagging wrote:

> > On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer <[hidden email]> wrote:
> > A relation seems easier to evaluate and explicit, while a spatial query heuristic will inevitably fail in some cases
>
>
> I think there is a need for a basic relation, if I understand Martin correctly, to simply associate the two lines, (for example, an =embankment and an =embankment_base pair). When mapped, they are not joined. They are merely adjacent. I am not sure of what “type” of relation to choose in iD, but I assume someone will tell us which type to use.
>
> When mapping a simple cutting or embankment, you would have only one “base” line adjacent - so there is little ambiguity, and the relationship can be inferred (IIUC), but in complicated tagging, there could easily be a situation where which base belongs to which line is unclear, and lead to problems.
>
> Simply putting them into a relation says “these members are related” and the renderer can know for certain that these two ways that don’t share nodes are a pair, no inference needed.

perhaps as a last step to perfection we might need some relations. Otoh quite pragmatically
- what is the use of associating/relating those two lines (base and top)?
Do we map them to make it clear if you run there you fall down a cliff or earth bank or run
into a cliff? No need for relations for that.

Also I am not convinced there is always a one-one relation between a cliff base and cliff
edge?
If we really wanted to render the "slope/cliff area" in some special style we would probably
have to map that as an area, not relation of two or more lines. But I think for small slopes,
the top and base lines if rendered should be good enough and for high slopes/cliffs DEM
derived countour lines would be better.

Btw as we get into more details we might want to map ramps as well.
 
> This again raises the question of levees - is the levee worthy of it’s own levee relation? do you put all 4 embankment lines into relation with the man_made=dyke line? this seems to be the only solution to:
>
> - properly group the embankments with the levee
> - not have to use super=relations (putting the embankment relations into a levee relation)
> - providing the most flexibility to weird situations
> - allowing for the extent of the top of the levee to be defined (large levees have varying width tops with usable areas, as shown, in which a “way” is insufficient ).

We use man_made=bridge (area) to group ways on a bridge.. so I am wondering would
man_made=levee to encompass the whole levee area work in an equivalent way?
I think it is only a quirk of OSM history that dyke and embankment are linear features
and we would do many things differently today - and maybe we should do it now.

Also somewhat related, waterway=dam can be either linear (the crown of the dam) or area.
I think we should have one tag for the crown of the dam and one for the area because it
would be often useful to map both of them.

Richard

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list
In reply to this post by Joseph Eisenberg
Sorry, I am continuing to have trouble properly replying to the tagging group, it keeps defaulting to the individual. 


On Nov 13, 2019, at 4:48 PM, Joseph Eisenberg <[hidden email]> wrote:

For a levee it can just go around the whole levee

If I understand your suggestion correctly, this is impossible. The only place one can “go around” is the finger of a levee that has ended where two rivers merge - but that is a lie too - the inside goes up the small river, and the outer folds and goes back upriver with it as well. There are very few places where inner becomes outer - because the point of the levee is to protect the outer from the inner. There are very few levees that end on the upstream side without going into terrain - still no option for the embankment to loop around. The levee starts in my town (sprouts out of a hill) and continues for 50KM. The river it meets goes for another 100km with full levee protection. They are giant structures. At no point does inner get a chance to become outer. 

Every stream, tributary, and minor river has levees here. Some merge with “no” flow control. Others merge via culverts with underground sluicegates, others merge via gigantic sluice gates the size of an office building. But the gates still give no chance for inner to become outer. the flood basins I use have extensive weirs and 1Km emergency spillways in the levees - still no place for them to u-turn. 

Having it “go around” is not really an option. 

Javbw.

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

dieterdreist


sent from a phone

> On 14. Nov 2019, at 04:08, John Willis via Tagging <[hidden email]> wrote:
>
> Sorry, I am continuing to have trouble properly replying to the tagging group, it keeps defaulting to the individual.


you have to “reply to all”

@list-admin maybe this setting could be changed? Replying to the list should be the default for a mailing list

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Peter Elderson
Messages are sent with Reply-To: "Tag discussion, strategy and related tools" <[hidden email]>
So simple reply should be enough, that's what I do and it works.

Fr gr Peter Elderson


Op do 14 nov. 2019 om 11:46 schreef Martin Koppenhoefer <[hidden email]>:


sent from a phone

> On 14. Nov 2019, at 04:08, John Willis via Tagging <[hidden email]> wrote:
>
> Sorry, I am continuing to have trouble properly replying to the tagging group, it keeps defaulting to the individual.


you have to “reply to all”

@list-admin maybe this setting could be changed? Replying to the list should be the default for a mailing list

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging

_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
Reply | Threaded
Open this post in threaded view
|

Re: Additional detail of Levee mapping via embankments

Tagging mailing list
The “reply-to” email address might be being secretly changed by some mail clients - when I choose “reply” to Peter’s mail, it chooses the tagging group. When I choose reply to Martin’s, it chooses Martin. This is Mail.app on MacOS 10.13.6. I have never really had this issue before. 

I don’t think this is simply a tagging list issue - it might be a combination of factors.

On Nov 14, 2019, at 9:05 PM, Peter Elderson <[hidden email]> wrote:

Messages are sent with Reply-To: "Tag discussion, strategy and related tools" <[hidden email]>
So simple reply should be enough, that's what I do and it works.

Fr gr Peter Elderson


Op do 14 nov. 2019 om 11:46 schreef Martin Koppenhoefer <[hidden email]>:


sent from a phone

> On 14. Nov 2019, at 04:08, John Willis via Tagging <[hidden email]> wrote:
>
> Sorry, I am continuing to have trouble properly replying to the tagging group, it keeps defaulting to the individual.


you have to “reply to all”

@list-admin maybe this setting could be changed? Replying to the list should be the default for a mailing list

Cheers Martin
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging


_______________________________________________
Tagging mailing list
[hidden email]
https://lists.openstreetmap.org/listinfo/tagging
12