Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

On Tue, Nov 19, 2019 at 08:16:43AM +0900, John Willis via Tagging wrote:
> On Nov 19, 2019, at 6:53 AM, Richard  wrote:
> > 
> > Other than that, "dyke_area" or "area:dyke" in analogy to 
> > https://wiki.openstreetmap.org/wiki/Key:area:highway ?
> 
> I think dykes/levees are made of inner and outer embankments, and pairing 
> them might be the only way to do it properly. 
> 
> Whatever is decided for embankments (I will work on some examples today) I 
> think a levee/dyke will have to be a relation of *some* sort (built on top of 
> the existing man_made=dyke tag) - either a relation of this way plus: 
> - 4 “levee lines (inner top+bottom)
> - 2 embankments+ 2 embankment_area polygons
> - 4 embankment lines. 
> 
> Mapping them as a total area (lower inner to lower outer) with a single 
> polygon with the man_made=dyke as the “top” down the middle is unacceptable 
> to me. The “top” is often a mappable area (with large levees worthy of this 
> detail). If it big enough to need this detail, it has a pretty large and 
> varying top area as well (as examples have shown). 

I didn't mean to map it *only* as a total area - instead I would suggest a 
man_made=dyke_area
(or area:dyke, dyke_building..) overlapping all elements of the levee 
(embankemnts top/bottom, 
man_made_dyke and other) - thus in addition to micromapping those elements
The man_made=dyke_area would serve to group all the elements together, thus 
avoiding the need
for a relation in most cases.
Very similar to the way man_made=bridge works today: replace the complicated 
Bridge/tunnel 
relation with a simple area.

Richard

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

Although they are constructed the same (pile of dirt), they are named and 
mapped differently. The man_made=levee tag exists, and I just want to extend 
it. 

Perhaps the man_made=embankment
Can have a embankment=* to tag different types of berms and other man-made 
slopes, but in this case, the levee is already mapped by the =dyke tag. 

Maybe I missed something (I’ll re-read it), but I am not sure they can be 
shared. 

Thanks for the thought. 

Javbw

> On Nov 20, 2019, at 2:22 PM, Graeme Fitzpatrick  wrote:
> 
> Just wondering if the suggestion I gave Volker this morning about walls 
> around a shooting range may also work for you?


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Graeme Fitzpatrick]

John

Just wondering if the suggestion I gave Volker this morning about walls
around a shooting range may also work for you?

" I was wondering about barrier=wall, even though it's possibly not a
constructed wall as such?

When I was just looking at barriers, I spotted
https://wiki.openstreetmap.org/wiki/Talk:Key:barrier#Bund_barriers_used_in_spate_irrigation,
used  22 times, but undocumented.

While this, & wiki https://en.wikipedia.org/wiki/Bunding mainly refer to
walls to retain water, they do also mention
https://en.wikipedia.org/wiki/Bunding#Anti-noise_bunds

Bunds are also commonly used around explosive or ammunition storage sites &
one definition is: " “bund” means an embankment of earth or a wall
constructed of brick, stone, concrete or other approved material to form
the perimeter or part of the perimeter of a compound;""

Maybe barrier=bund, drawn as an area, rather than a way, & with the roads
etc "inside" the area, possibly as layer=1?

Could that work?

Thanks

Graeme


On Wed, 20 Nov 2019 at 15:12, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

>
>
> > On Nov 19, 2019, at 12:49 PM, Joseph Eisenberg <
> joseph.eisenb...@gmail.com> wrote:
> >
> > Is there something else that we are expecting could be done by mapping
> > this in great detail which cannot be done with a simpler
> > representation + a DEM?
>
> I understand that, topographically speaking, we can get information about
> it from another source and see the mound of dirt. In that sense, you are
> correct.
>
> But just as we show red diagonal lines through military bases, we should
> convey the extent of this man-made structure beyond inferring it’s
> existence from the road access limitations and other mapped barriers
> (fences, lack of roads, grass, scrub, etc). the height is just one feature
> of the structure that is massive and dominates the surroundings.
>
> - just as we tag hedges and guardrails and other barriers that are not
> gates and bollards directly on ways,  understanding there is a massive
> man-made barrier nearby is useful. It really limits access. A small levee
> can be stepped over in a few steps. These you have to climb. Both cannot be
> represented by a way (IMO).
>
> - I like tagging the detail of some things. It is useful to me and others
> to visualize the situation. Roads there are weird and complicated -
> explained only by being on the levee. We have roof:part and bridge:support
> and =tree other details for other objects of interest, and these giant
> structures seem worthy of being rendered differently than just the topo
> contours like the the side of a hill. I will be mapping them *anyways* to
> set their landcover, so having a scheme to map them is “free” mapping
> detail.
>
> - everything large should be represented with an area. I have 600m wide
> rivers. I have sluice gates you could drive a bus through. Levees wider
> than apartment complexes. All of them are things people see and navigate
> around as they traverse the levee, and correctly conveying to them “this is
> that levee” helps people orient themselves and properly plan their routes
> when moving in-on-around the levee. Right now, I can map the river, and I
> can map the ground cover, but not the structure - unlike other man-made
> structures (dams, bridges, buildings, parking lots, railway corridors,
> etc). Infrastructure, even giant piles of dirt, should be represented in a
> base map.
>
> - levees are a function. They block water. Their construction is of an
> inter and outer embankment. They move separately and branch and move, so
> representing the levee requires (IMO) mapping the embankments and the top -
> all three are “features” of the levee. Mapping the two embankments in a
> relation gives you the “top” for free.
>
> - Between the raised tollways that sit on 5m high raised road beds across
> my entire region and the hundreds of KM of levees, I have a lot of man-made
> piles of dirt that severely restrict access kris-crossing everything. And
> the levees are often adjacent *many* public amenities - parks, sports
> grounds, cycling roads, and other *heavily used* features.
>
> - they are very very important during a flood. In some areas, they might
> be the only safe spaces. They are covered with emergency spaces and other
> areas safe in a flood. Understanding you are “inside” the levee Vs
> “outside” the levee might be the difference between life and death. If a
> levee breaks, the only safe space might be on top of it. Mapping and
> rendering these structures makes it obvious to everyone where it is without
> inferring it from topo information.
>
> - they are known landmarks.
>
> Javbw.
>
>
>
> ___
> 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] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 19, 2019, at 12:49 PM, Joseph Eisenberg  
> wrote:
> 
> Is there something else that we are expecting could be done by mapping
> this in great detail which cannot be done with a simpler
> representation + a DEM?

I understand that, topographically speaking, we can get information about it 
from another source and see the mound of dirt. In that sense, you are correct. 

But just as we show red diagonal lines through military bases, we should convey 
the extent of this man-made structure beyond inferring it’s existence from the 
road access limitations and other mapped barriers (fences, lack of roads, 
grass, scrub, etc). the height is just one feature of the structure that is 
massive and dominates the surroundings. 

- just as we tag hedges and guardrails and other barriers that are not gates 
and bollards directly on ways,  understanding there is a massive man-made 
barrier nearby is useful. It really limits access. A small levee can be stepped 
over in a few steps. These you have to climb. Both cannot be represented by a 
way (IMO). 

- I like tagging the detail of some things. It is useful to me and others to 
visualize the situation. Roads there are weird and complicated - explained only 
by being on the levee. We have roof:part and bridge:support and =tree other 
details for other objects of interest, and these giant structures seem worthy 
of being rendered differently than just the topo contours like the the side of 
a hill. I will be mapping them *anyways* to set their landcover, so having a 
scheme to map them is “free” mapping detail.  

- everything large should be represented with an area. I have 600m wide rivers. 
I have sluice gates you could drive a bus through. Levees wider than apartment 
complexes. All of them are things people see and navigate around as they 
traverse the levee, and correctly conveying to them “this is that levee” helps 
people orient themselves and properly plan their routes when moving 
in-on-around the levee. Right now, I can map the river, and I can map the 
ground cover, but not the structure - unlike other man-made structures (dams, 
bridges, buildings, parking lots, railway corridors, etc). Infrastructure, even 
giant piles of dirt, should be represented in a base map. 

- levees are a function. They block water. Their construction is of an inter 
and outer embankment. They move separately and branch and move, so representing 
the levee requires (IMO) mapping the embankments and the top - all three are 
“features” of the levee. Mapping the two embankments in a relation gives you 
the “top” for free. 

- Between the raised tollways that sit on 5m high raised road beds across my 
entire region and the hundreds of KM of levees, I have a lot of man-made piles 
of dirt that severely restrict access kris-crossing everything. And the levees 
are often adjacent *many* public amenities - parks, sports grounds, cycling 
roads, and other *heavily used* features. 

- they are very very important during a flood. In some areas, they might be the 
only safe spaces. They are covered with emergency spaces and other areas safe 
in a flood. Understanding you are “inside” the levee Vs “outside” the levee 
might be the difference between life and death. If a levee breaks, the only 
safe space might be on top of it. Mapping and rendering these structures makes 
it obvious to everyone where it is without inferring it from topo information. 

- they are known landmarks.

Javbw. 



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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Joseph Eisenberg]

> peaks are contained in DEMs, why map them in OSM

Mainly so we can add their name=* and elevation based on survey.

But also, DEMs have trouble localizing point and line features, so if
you climb the peak or walk along a ridgeline to check the location
with GPS, it is usually more accurate than most DEMs.

For the same reasons, mapping a dyke or embankment or cutting as a
line is a great idea.

Mapping the area is less important, since usually adding 'width=' is
enough, or mapping 2 embankment lines on each side, though I am not
opposed to other mappers doing this if they really want to.

On 11/19/19, Martin Koppenhoefer  wrote:
> Am Di., 19. Nov. 2019 um 04:49 Uhr schrieb Joseph Eisenberg <
> joseph.eisenb...@gmail.com>:
>
>> Are you sure that the information that you want is not already
>> available from a Digital Elevation Model?
>>
>
>
> I do not agree with this. DEMs (at least what is commonly and freely
> available currently) do not provide the same kind of information, and are
> generally lacking the resolution and in particular, do not contain specific
> detail (e.g. shape), they treat every spot the same, are not focused on
> features (you can recognize the features that are visible and discernible
> on them, but they do not specifically represent them). We could also say:
> the buildings and roads are already on aerial imagery, no need to map them
> ;-). Or peaks are contained in DEMs, why map them in OSM?
>
>
> Large embankments should be clearly visible in the topography, so we
>> do not need to reproduce them as 3D model in the database, any more
>> than we need to map the exact contours of a quarry or mountain.
>>
>
>
> if there are interesting features on a mountain (particularly those
> features with names or other attributes, wikipedia references etc.), we do
> map them, (e.g. peaks, ridges, passes, ...)
>
> Cheers
> Martin
>

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Martin Koppenhoefer]

Am Di., 19. Nov. 2019 um 04:49 Uhr schrieb Joseph Eisenberg <
joseph.eisenb...@gmail.com>:

> Are you sure that the information that you want is not already
> available from a Digital Elevation Model?
>


I do not agree with this. DEMs (at least what is commonly and freely
available currently) do not provide the same kind of information, and are
generally lacking the resolution and in particular, do not contain specific
detail (e.g. shape), they treat every spot the same, are not focused on
features (you can recognize the features that are visible and discernible
on them, but they do not specifically represent them). We could also say:
the buildings and roads are already on aerial imagery, no need to map them
;-). Or peaks are contained in DEMs, why map them in OSM?


Large embankments should be clearly visible in the topography, so we
> do not need to reproduce them as 3D model in the database, any more
> than we need to map the exact contours of a quarry or mountain.
>


if there are interesting features on a mountain (particularly those
features with names or other attributes, wikipedia references etc.), we do
map them, (e.g. peaks, ridges, passes, ...)

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Joseph Eisenberg]

Javbw,

Are you sure that the information that you want is not already
available from a Digital Elevation Model?

See for example how your area looks in Opentopomap.org, on
Opencyclemap, or on the Terrain layer of Google Maps, or a similar
rendering.

Large embankments should be clearly visible in the topography, so we
do not need to reproduce them as 3D model in the database, any more
than we need to map the exact contours of a quarry or mountain.

Like Opentopomap or Opencyclemap, database users that want to show the
topography are expected to combine Openstreetmap data with one of the
many available digital elevation models (DEM) to produce contour
lines, shading and 3D terrain visualizations.

Is there something else that we are expecting could be done by mapping
this in great detail which cannot be done with a simpler
representation + a DEM?

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

On Nov 19, 2019, at 6:53 AM, Richard  wrote:
> 
> Other than that, "dyke_area" or "area:dyke" in analogy to 
> https://wiki.openstreetmap.org/wiki/Key:area:highway ?

I think dykes/levees are made of inner and outer embankments, and pairing them 
might be the only way to do it properly. 

Whatever is decided for embankments (I will work on some examples today) I 
think a levee/dyke will have to be a relation of *some* sort (built on top of 
the existing man_made=dyke tag) - either a relation of this way plus: 
- 4 “levee lines (inner top+bottom)
- 2 embankments+ 2 embankment_area polygons
- 4 embankment lines. 

Mapping them as a total area (lower inner to lower outer) with a single polygon 
with the man_made=dyke as the “top” down the middle is unacceptable to me. The 
“top” is often a mappable area (with large levees worthy of this detail). If it 
big enough to need this detail, it has a pretty large and varying top area as 
well (as examples have shown). 

Also, The ship has sailed on “levee” - the term in OSM is dyke. 

Javbw

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

On Mon, Nov 18, 2019 at 11:15:49AM +0900, Joseph Eisenberg wrote:

> 
> 1) Map the central line as man_made=dyke, or highway + cutting=yes /
> embankment=yes as relevant. This line should not be 100 kilometers
> long, but a reasonable length: probably no more than 10 kilometers,
> and even shorter in a major city.
> 
> This step is enough for most uses. You don't actually have to do steps 2 or 3.
> 
> 2) If you want to, you can map the top line of any man_made=embankment
> lines, if desired.
> 
> 3) Finally (this part is very optional), you could map the area of the
> cutting or embankment or dike as a series of closed ways. Don't make
> them more than a kilometer or 2 long, since it's a pain to edit them
> if they are too huge. It's better to use a few smaller closed ways
> rather than a huge multipolygon to map complex features with holes.

a couple of points:
* people may confuse what the "area of embankment" is, my intuition is this 
  would be the top area of the embankment not the slope of it as you perhaps
  intend it.
* still thinking in most case it would be better to map eg the bottom edge of
  the embankment where there is a clear cut bottom edge as it much easier 
  than mapping a slope area. If you map both the edge of the embankment and
  the slope, the top ways will be "shared", which means either a multipolygon 
  or drawing the ways on top of each other. Slope areas would typically get 
  another area attributes (surface, landuse, vegetation), again to be solved 
  with multipolygons or the hacky way.
* the comparison with riverbanks may miss some points: rivers are named so 
  they are easier to piece together. Two adjacent embankment areas may be 
  a valid attempt to map an edge of an embankment for example.
  River areas are just water and don't have any other landuse or vegetation
  attributes.
* it would be nice to have a concept that extends easily to earth banks, cliffs
  and cuttings.

> (We should not use a new tag like man_made=levee for this, because
> "levee" is American English for "dike", so it would be better to use
> man_made=dyke_area or something similar.)

After googling dyke I am wondering if we should make an exception and use 
American English in this very particular case ? Googling levee gives me much
more useful information than "dyke".

Other than that, "dyke_area" or "area:dyke" in analogy to 
https://wiki.openstreetmap.org/wiki/Key:area:highway ?


Richard


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Joseph Eisenberg]

> for straight embankments, cuttings, slopes, if they are done with an area
> that shares nodes, then I don’t think you need a relation.

Agreed. You can map the area of the cutting or embankment as a new tag
like man_made=embankment_area or similar, and the area would include
the same nodes as the man_made=embankment or =cutting line.

It would also be possible to map the area of an embankment or cutting
this way when the central highway line is tagged as embankment=yes or
cutting=yes: it would be inside of the area and this clearly relates
the area to the highway.

Previously I mentioned using an area for levees/dikes, and there was
some concern that this would be difficult for really long
dikes/levees.

This is the same situation as with river areas: we tag these by
breaking up the area of the river into reasonable-sized chunks, maybe
a kilometer or two long, and the linear waterway=river line is also
broken into 10 kilometer lengths so that it is easier to edit without
conflicts. I would use this same technique to map the area of a very
large dike/levee/embankment/cutting:

1) Map the central line as man_made=dyke, or highway + cutting=yes /
embankment=yes as relevant. This line should not be 100 kilometers
long, but a reasonable length: probably no more than 10 kilometers,
and even shorter in a major city.

This step is enough for most uses. You don't actually have to do steps 2 or 3.

2) If you want to, you can map the top line of any man_made=embankment
lines, if desired.

3) Finally (this part is very optional), you could map the area of the
cutting or embankment or dike as a series of closed ways. Don't make
them more than a kilometer or 2 long, since it's a pain to edit them
if they are too huge. It's better to use a few smaller closed ways
rather than a huge multipolygon to map complex features with holes.

(We should not use a new tag like man_made=levee for this, because
"levee" is American English for "dike", so it would be better to use
man_made=dyke_area or something similar.)

See the examples at Tag:waterway=riverbank for how this would look.

There seems to be some confusion about the need for a relation. But
notice that rivers do not use a relation to combine all of the areas.
There is a type=waterway relation but this is only for the central
waterway=river lines, and it is not not commonly used, because in
practice database users can put the lines back together by just
looking for river ways which have the same name and meet at a shared
node.

Similarly, database users can fairly easily recombine all of the
waterway=riverbank areas which make up a river into one big polygon if
they need to do this for rendering or data analysis for some reason
(but usually it's not needed). This could also be done for any
`man_made=dyke_area` closed ways which are touching, if someone wants
to make a polygon including all of the levees along a certain river in
Tokyo or something like that.

- Joseph Eisenberg

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

for straight embankments, cuttings, slopes, if they are done with an area that 
shares nodes, then I don’t think you need a relation. if they are jsut two 
lines that happen to be near each other, and do not share nodes, you might need 
a relation to associate them. 

also, if a levee is made of two separate embankments, with a =dyke way in the 
center, those might need t obe related. 

Javbw

> On Nov 14, 2019, at 6:40 AM, Richard  wrote:
> 
> 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.

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 16, 2019, at 7:50 PM, Andy Townsend  wrote:
> 
>  A complicated scheme dreamt up here isn't going to get taken up by anyone.  

I took these 3 pictures yesterday while out cycling: 
https://imgur.com/gallery/Wqc5Ems 

The largest of the 8 levees I rode on is 140m wide (edge to edge) where I took 
these pictures, according to an online imagery measuring tool. they are about 3 
stories tall. the north side levee is 100M wide. These are all built on flat 
open ground, the levees 100% man-made. the river is 600m wide here during a 
typhoon. 

others were: 

148&60m (both levees total width, near a river junction)
54&30m (smaller river)
40&50m (smaller river)
65&42-70m (they are widening them, a demolished house foundation seen here in 
maxar imagery  https://www.openstreetmap.org/way/746507486 
).

much farther upriver near my town, where the levee on a tributary begins, they 
are a modest 40 & 30m wide where they sprout out of foothills the river has cut.

~~~

I agree that complicated schemes won’t get used, which is why I want the 
smallest usable method necessary **for people who want to add more detail in 
addition to existing schemes** ,  something that scales similar to how we map 
businesses (pin, building, landuse) depending on how much detail you wish to 
add. 

if you don’t feel the need to map an embankment in such detail, don’t. if it is 
too small, don’t.  I don’t want to create a scheme that replaces the current 
embankment/cutting/ levee, but is on top of current schemes, and allows you to 
map their extent **if you wish to**.

When things are huge, you *have to* have the ability to represent *anything* in 
OSM by border or area. If I was living back in San Diego, the cuttings for the 
freeway are the only cuttings I can think of worth mapping as an area. here in 
Japan, embankments / cuttings/ levees are everywhere. One levee bank is wider 
than most railway corridors - and we have an area for those, despite that the 
train tracks already being mapped. We understand that the area of the corridor 
is useful, to represent landuse and as a defacto barrier.

The same is true for large embankments/levees. 

For very large features *of any type* in OSM, they their area needs to be 
represented *somehow* in OSM. 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

On Fri, Nov 15, 2019 at 12:17:41PM +0900, John Willis via Tagging wrote:
> 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. 
> 

In my mail client I have redefined "reply" to "reply-all" which so far works 
for all lists
regardless of their settings.

Richard

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

On Sat, Nov 16, 2019 at 06:21:13PM +0900, John Willis via Tagging wrote:
> Still looking for feedback on the idea, Specifically: 

my idea..

> - lower base way or area sharing nodes with the top line in embankment / 
> cutting, etc? 

way instead of area. Simpler to do and more flexible.
Also I would favor the "namespaced" variants (natural=cliff:base, 
man_made=embankememnt:base). Makes it clear that those are optional/additional
details and leaves a clear path for further extensions (eg :ramp: ?)

> - relation or no relation needed?

see how far you get without relations.

> - map levee with embankment pairs, or map with two pairs of levee specific 
> tags in a relation with the =dyke way? 

draw man_made=levee covering all elements

Richard

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Andy Townsend]

On 11/16/19 9:21 AM, John Willis via Tagging wrote:


Still looking for feedback on the idea, Specifically:

- lower base way or area sharing nodes with the top line in embankment / 
cutting, etc?

- relation or no relation needed?

- map levee with embankment pairs, or map with two pairs of levee specific tags 
in a relation with the =dyke way?

Javbw


To be honest, I'd be worried about overcomplicating things.  A 
complicated scheme dreamt up here isn't going to get taken up by 
anyone.  Additionally I suspect that quite a lot of people thinking 
about mapping these features are doing so from imagery, and while 
embankments are visible from imagery once you've been to an area and 
seen what they look like, other features may not be.


One thing that might help would be to edit an area on the dev server 
https://master.apis.dev.openstreetmap.org (perhaps several areas, in 
different ways) and invite people to comment on that.


Best Regards,

Andy



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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

Still looking for feedback on the idea, Specifically: 

- lower base way or area sharing nodes with the top line in embankment / 
cutting, etc? 

- relation or no relation needed?

- map levee with embankment pairs, or map with two pairs of levee specific tags 
in a relation with the =dyke way? 

Javbw

> On Nov 13, 2019, at 8:56 AM, John Willis  wrote:
> 
> 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.


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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Graeme Fitzpatrick]

I've seen the same with the Australia list.

Here, "reply" go to the list; while on AU, "reply" only goes to that
person, while "Reply All" goes to them & the list?

Thanks

Graeme


On Fri, 15 Nov 2019 at 13:19, John Willis via Tagging <
tagging@openstreetmap.org> wrote:

> 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  wrote:
>
> Messages are sent with Reply-To: "Tag discussion, strategy and related
> tools" 
> 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 <
> dieterdre...@gmail.com>:
>
>>
>>
>> sent from a phone
>>
>> > On 14. Nov 2019, at 04:08, John Willis via Tagging <
>> tagging@openstreetmap.org> 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
>> 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
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

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  wrote:
> 
> Messages are sent with Reply-To: "Tag discussion, strategy and related tools" 
> mailto:tagging@openstreetmap.org>>
> 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 
> mailto:dieterdre...@gmail.com>>:
> 
> 
> sent from a phone
> 
> > On 14. Nov 2019, at 04:08, John Willis via Tagging 
> > mailto:tagging@openstreetmap.org>> 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
> 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] Additional detail of Levee mapping via embankments

[Peter Elderson]

Messages are sent with Reply-To: "Tag discussion, strategy and related
tools" 
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 <
dieterdre...@gmail.com>:

>
>
> sent from a phone
>
> > On 14. Nov 2019, at 04:08, John Willis via Tagging <
> tagging@openstreetmap.org> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Martin Koppenhoefer]

sent from a phone

> On 14. Nov 2019, at 04:08, John Willis via Tagging 
>  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

(I mis-sent this email)

> On Nov 13, 2019, at 3:44 AM, Richard  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  
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  wrote:
>
>
>> On Nov 13, 2019, at 3:44 AM, Richard  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 
>> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 13, 2019, at 3:44 AM, Richard  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  
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

On Wed, Nov 13, 2019 at 07:04:42AM +1000, Graeme Fitzpatrick wrote:
> On Wed, 13 Nov 2019 at 05:05, Richard  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Graeme Fitzpatrick]

On Wed, 13 Nov 2019 at 05:05, Richard  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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Richard]

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 12, 2019, at 10:26 AM, Joseph Eisenberg  > 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 6:15 PM, Martin Koppenhoefer  
> 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  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). 

https://www.openstreetmap.org/edit#map=17/35.9/139.89482 
 


Do you need a relation on them? 

Any suggestions on improvements? 

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[Volker Schmidt]

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

> Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <
> tagging@openstreetmap.org>:
>
>> 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
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[Martin Koppenhoefer]

Am Mo., 11. Nov. 2019 um 07:27 Uhr schrieb John Willis via Tagging <
tagging@openstreetmap.org>:

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

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 12:52 PM, Joseph Eisenberg  
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] 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  wrote:
>
>
>> On Nov 11, 2019, at 11:16 AM, Joseph Eisenberg
>>  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.26097/139.63921
> 
> 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Additional detail of Levee mapping via embankments

[John Willis via Tagging]

> On Nov 11, 2019, at 11:16 AM, Joseph Eisenberg  
> 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.26097/139.63921 

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

Re: [Tagging] 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  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
>  - 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
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging