Re: [Tagging] Spillways

[John Willis]

The thing I am tagging is not a dam. It is a series of flood basins, one of 
which is a "reservoir". They are made by levees that surround the rivers, but 
in a very complicated way. They eventually return all the water back to the 
river, shortly after it is captured. 

I explain that below, if you are interested, 

But the TL;DR is that it is a weird combination of levees, weirs, spillways, 
gates (which are possibly considered a dam), channels, valves, and other things 
that are not properly fleshed out in OSM, and they should have tags 
created/expanded for them. 



On Mar 24, 2017, at 7:34 AM, Richard  wrote:

>> earthen embankment (levee) around the entire river system - it is part of 
>> that. 
> 
> this is still a dam for me?

This thing I am tagging is really weird. 

Japan is full of massive gravity dams that catch storm water and snow melt to 
from giant lakes. Canyons has flow blocking "dams" with weirs in the center to 
stop flash floods. 

This thing is like something I have never seen. It is like 10x 6 km of man made 
structures nested together. 

It is a "retardation basin" for a smaller river feeding into a larger river. 

The system is not for water storage, it is temporary surge overflow for the 
river. 

Here is the river where it meets the flood plain, after the typhoon surge in 
the middle of the night. Note, this is completely contained in levees from this 
point where it leaves this mountain to where it empties into the pacific ~ 
160km later, as it crosses above Tokyo. 

https://m.flickr.com/#/photos/javbw/11091304694/sizes/o/

The brown river on the left is about 5x normal flow at this point, down 3m in 
height from the surge the night before, which would exceed 10x. 

It is heading down to this thing I am tagging, off in the haze. The ghostly 
river in the upper right will take the water from it afterward.

This "retardation system" forces that surge  water into a series of basins 
connected by channels that automatically empty themselves. Due to the basin's 
entrance being much larger than it's exit, a typhoon surge on this smaller 
river is caught and dissipated, while normally (350 days a year?) the river is 
5-7m lower than the entrance to the system, and is unused. 

The system is made of levees, with small control gates at the bottom. These 
small gates would be the "dam" - the levees wrap around this thing, like a golf 
ball inside a snake. 

Above this retardation system, the levees narrow the river basin from 200m wide 
to less than 50m. On either side, the narrowing section has 10m embankments 
with 500m long weirs that empty into both a small and a very large open basin 
that used to be swamps. 

The large open basin has an additional levee system around a series of 3 
successively larger "reservoirs" inside it. This inter basin is tagged as a 
reservoir, and has a little rarer year round, fed by a couple tiny streams year 
round through small culverts (with control valves big and small) in the levee 
embankment. 

 Gated channels direct water from the large outer basin to the inner basins 
that look like a heart. There is an 1km additional spillway in the inter basin 
to let water rapidly in or out  the inner basin as well. Below this spillway is 
a road in the outer basin, dry and drivable most of the year. 

Having the outer basin catch a surge from a typhoon on this tributary gives the 
system downstream a chance to deal with the surge from the main river first. 

The bottom of the inner basin has flow control gates to empty it back into the 
outer basin. This very tiny (50m?) section would be the dam. 

The water then flows into the end of the outer basin, through another set of 
control gates, back into the river all the water came from to begin with. There 
is another 1km long spillway that connects the outer basin to the river. This 
is the one I marked with an area.  

Being able to tag levees, control flow valves for drains and streams that empty 
into the inner basin, the gates for the "dam" the spillways and weirs by area, 
are all currently deficient in OSM. 

Wrapping the inner and outer basins completely in a circular shaped dam inside 
another circular dam is avoiding properly fleshing out the tagging of large, 
detailed, and complex man-made water control systems. 

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

Re: [Tagging] Spillways

[Warin]

On 24-Mar-17 03:51 AM, Tobias Wrede wrote:

Hello,

actually, I have used
   warterway=spillway
   intermittent=yes
in the past, reasoning that this particular spillway 
(http://www.openstreetmap.org/way/451309286) is rarely put to use, 
while others might be more permanently flooded (regularly during high 
tides for example)


Tobias

Am 23.03.2017 um 12:58 schrieb John Sturdy:
I suppose  waterway=weir plus intermittent=yes would describe it, but 
I don't think that's as good as a specific spillway tag.


On Thu, Mar 23, 2017 at 6:52 AM, Andrew Harvey 
> wrote:


On 22 March 2017 at 16:56, Dave Swarthout
> wrote:
> Weir does not seem appropriate for this type of thing. There is
a tag,
> waterway=spillway, that seems like a good fit - 81 uses so far.

I've seen these tagged as waterway=drain which is close but agree
that
waterway=spillway is better. Would be great to have this
documented on
the wiki.




There is at least one 'spillway' that is a pipe in the lake ... shaped 
like a funnel for flow ... but it is not your traditional 'spillway' in 
that it does not go over the wall but under.
In that case 'drain' is a more appropriate word... but the function is 
still a spillway.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[yo paseopor]

On Thu, Mar 23, 2017 at 1:41 AM, Tod Fitch  wrote:

>
> “stop:forward=yes” & “stop:backward=yes” seem like they are putting a
> value in the key as the stuff to the right of the equals may never be
> anything other than “yes”. On the “lanes:forward” and “lanes:backward” keys
> at least the values carry variable values.
>

Sorry, but you are wrong if you are talking of "my idea" . I don't view any
future to a unique key for every traffic sign (would be interesting for
every group as a concatenation of pairs as: traffic_sign=warning
warning=bump), I see varied values. So as you can see with the example of
the proposal [1] , the result will not be stop:x = yes instead of

highway=stop >> kind of traffic sign in a unified scheme
traffic_sign:forward=ES:R2 >> Spanish code of the traffic sign (wil be good
for rendering the exact image)
side=right > side of the road it is.


>
> There is already a “traffic_signals:direction=forward | backward” usage.
> “stop:direction= forward | backward” and “give_way=forward | backward”
> would fit that schema too.
>

I think a scheme with the various values is more complete than create a key
for every traffic sign because then every traffic sign will fit in every
country with the same key, as you can see in Taginfo [2].

>  Will it become forbidden to split ways on nodes with stop sign or traffic
> signal tags, because it breaks the information tagged on those nodes?
>
> To split a way specific in that node would not be the best option but the
only problem will be if you connect other way to that node, if you split a
way but you have the same direction in the two segments of a way I don't
think there will be any problem with that.Also you can split the way next
pixel of the pixel of the traffic sign.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/
Extended_traffic_signs_tagging#Traffic_signs_presets
[2] https://taginfo.openstreetmap.org/projects/traffic_signs#tags
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[yo paseopor]

On Thu, Mar 23, 2017 at 9:03 PM, Martin Koppenhoefer  wrote:

>
>
> sent from a phone
>
> > On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> >
> > - highway=stop+direction=forward node on the incoming way... Only
> >  covers the simple case but covers it simply
>

I prefer the subkey :forward / :backward because then we save one pair of
key=value we can use to put the future unification of the meaning of
traffic signs groups.

while this might work often with stop signs it'll hardly work with maxspeed
> signs, because the changing maxspeed requires to split the highway, so that
> there would be 2 highways ending in the same node and forward would not be
> clear of which way.
>
For consistence , whit two ways with the same directions, which problem do
you have if the splitted way marks the direction...to the same direction so
is coherent between nodes and the two ways?

>
> When I map traffic signs it's mostly city limit,
> maxspeed/maxweight/maxheight and I do it generally for fellow mappers
> (including myself) because the effect of the sign I will map on the highway
> (typically linear, not just a point). Mapping on the side of the road has
> worked out perfectly for this scope.
>

Using the :forward/backward scheme and with Kendzi3D I get the situation
very similar to reality as you can see in these pics, [1] and [2]. I can
map any traffic sign you have in any traffic law which have a code. People
like Mapillary do some classification we can "copy" or use/propose similar
in a future unification of the keys with meaning for traffic signs , fa
away than only city limit,
maxspeed/maxweight/maxheight/stop,give_way,traffic signal.

Salut i senyals de trànsit (Health and traffic signs)
yopaseopor

[1] http://imgur.com/7FCO9ec
[2] http://imgur.com/WDUAWSa
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Spillways

[Richard]

On Wed, Mar 22, 2017 at 10:44:17AM +0900, John Willis wrote:
> How do you tag an emergency spillway? 
> 
> I am tagging a giant flood control reservoir in my region. The “lake” is 
> surrounded by giant man-made embankments on all sides, surrounded by an 
> additional  set of embankments, with gates to let the water out. There is no 
> dam per se, because there is ~200 km of this man-made 10-20m tall earthen 
> embankment (levee) around the entire river system - it is part of that. 

this is still a dam for me?

Richard

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

Re: [Tagging] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Martin Koppenhoefer]

sent from a phone

> On 23 Mar 2017, at 17:23, Jean-Marc Liotier  wrote:
> 
> - highway=stop+direction=forward node on the incoming way... Only
>  covers the simple case but covers it simply


while this might work often with stop signs it'll hardly work with maxspeed 
signs, because the changing maxspeed requires to split the highway, so that 
there would be 2 highways ending in the same node and forward would not be 
clear of which way.

When I map traffic signs it's mostly city limit, maxspeed/maxweight/maxheight 
and I do it generally for fellow mappers (including myself) because the effect 
of the sign I will map on the highway (typically linear, not just a point). 
Mapping on the side of the road has worked out perfectly for this scope.

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

Re: [Tagging] Spillways

[Tobias Wrede]

Hello,

actually, I have used
   warterway=spillway
   intermittent=yes
in the past, reasoning that this particular spillway 
(http://www.openstreetmap.org/way/451309286) is rarely put to use, while 
others might be more permanently flooded (regularly during high tides 
for example)


Tobias

Am 23.03.2017 um 12:58 schrieb John Sturdy:
I suppose  waterway=weir plus intermittent=yes would describe it, but 
I don't think that's as good as a specific spillway tag.


On Thu, Mar 23, 2017 at 6:52 AM, Andrew Harvey 
> wrote:


On 22 March 2017 at 16:56, Dave Swarthout > wrote:
> Weir does not seem appropriate for this type of thing. There is
a tag,
> waterway=spillway, that seems like a good fit - 81 uses so far.

I've seen these tagged as waterway=drain which is close but agree that
waterway=spillway is better. Would be great to have this documented on
the wiki.

___
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] Traffic sign's relevant direction: direction=* vs. relation [Was: traffic_signals:direction=* vs. direction=*]

[Jean-Marc Liotier]

On Thu, 23 Mar 2017 16:31:47 +0100
Martin Koppenhoefer  wrote:

> 2017-03-23 15:47 GMT+01:00 Jean-Marc Liotier :
> 
>> I'm not operating a routing system so maybe someone who is
>>   might offer his opinion on that point
> 
> in another thread a few days ago there was a comment by Daniel
> Hofmann who works at mapbox on OSRM:
> https://lists.openstreetmap.org/pipermail/tagging/2017-March/031727.html

Wow, thanks - how did I miss this thread... Well, the good news is
that the question of traffic sign direction modeling is in the air !

So, OSRM doesn't grok relations and doesn't process direction=*
either, nor any of its cousin tags - and the whole thread does not
mention anything else that does, with the exception of Kenzi3D which
does  direction=* ... Very well then: since there is very little
consumption to impact with the choice of a modeling method, I would say
that we are rather free to propose an Openstreetmapically correct way
and data consumers shall follow.

After reading the thread, it seems that our ideas here are not
unlike what has been discussed there.

So I stand by my current position, supporting either or both:

- relation (type: to be defined) including the highway=stop node and
  the incoming way with a from:forward or from:backward role...
  Universal but some consumers such as OSRM balk at processing relations

- highway=stop+direction=forward node on the incoming way... Only
  covers the simple case but covers it simply

I believe that boiling down the issue to just those two (and maybe live
with them both for an indeterminate duration) would significantly
improve over the current state.

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

2017-03-23 15:47 GMT+01:00 Jean-Marc Liotier :

> I'm not operating a routing system so maybe someone who is
>   might offer his opinion on that point
>


in another thread a few days ago there was a comment by Daniel Hofmann who
works at mapbox on OSRM:
https://lists.openstreetmap.org/pipermail/tagging/2017-March/031727.html

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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Jean-Marc Liotier]

So, summing up the ideas expressed so far, in the example case of a stop
sign on a two-ways way (not an all-ways stop), we have:

1- highway=stop+direction=forward node on the way to an intersection
- Advantages: simple, uses the well-known direction=* tag, easy for
  routers to interpret
- Disadvantages: to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it
  applies, only good for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case
- My opinion: looks good to me for covering the simple case, which
  means that it requires another way to coexist for covering the
  complex case. Is the simple case common enough for this duplication
  to be a net benefit ?

2- highway=stop+stop:direction=forward node on the way to an
  intersection
- Advantages: simple, uses the stop:direction=* tag which is coherent
  with traffic_signals:direction=*
- Disadvantages: new tag, to be unambiguous, must be tagged on a
  non-intersection node adjacent to the intersection to which it applies
- My opinion: just like n°1 but with an exotic tag for no benefit...
  Discard this proposal !

2- highway=stop node on the way to an intersection, with the nearest
  intersection being the one to which the sign applies
- Advantages: simplest method
- Disadvantages: slight processing burden for the router which must find
  the closest intersection to guess which one it applies to
- My opinion: might be too ambiguous for the routing processor, but I'm
  not operating a routing system so maybe someone who is might offer
  his opinion on that point

3- highway=stop on the right of the way when looking towards the
  intersection to which the sign applies
- Advantages: very simple, records actual location of the stop sign
- Disadvantages: heavy processing burden for the router which must find
  the closest way to guess which one it applies to
- My opinion: way too much burden on the routing processor... But
  again, I'm not operating a routing system so maybe someone who is
  might offer his opinion on that point

4- highway=stop near the way, with a two-node way attached as a
  "direction arrow"
- Advantages: well, it sort of would work
- Disadvantages: way too much burden on the routing processor, heretical
  to the Openstreetmap way
- My opinion: heretical !

5- relation (type: to be defined) including highway=stop and
from:forward (the incoming way arriving at the stop - must be connected
to the stop)
- Advantages: only a couple more additional tagging steps compared to
  the other methods (creating the relation+a couple members).
  Compatible with the highway=stop being either on the way or near the
  way at the actual location of the sign
- Disadvantages: a couple more additional tagging steps compared to
  the other methods... And it is a relation (which is not
  beginner-friendly)
- My opinion: must be retained because it is the only one which
  unambiguously covers all cases. The only question is: is it valuable
  to have another simpler relationless method to cover the common
  simple case ?

My opinion summary: n°5 is a keeper... Do we need n°1 too ?

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

Re: [Tagging] Spillways

[John Willis]

Javbw
> On Mar 22, 2017, at 9:42 PM, Greg Troxel  wrote:
> 
> Also, presumably emergency spillways are mapped as areas, rather than
> lines, but they probably should have both, to have the water network and
> show the area.  The one I am familiar with is really large

OSM has a lot of objects originally represented by ways that eventually became 
possible to represent with areas - river+riverbank is a good example. 

I would like to: 

- document waterway=spillway. 

- create a spillway=(main/ secondary emergency) or similar sub-tag. 

- create a tag for mapping the extent of spillways.  (Waterway=spillway_area ?)

- create an area tag to go with dyke. (Man_made=dyke_area ? 

- Figure out how to map water control gates, the tiny hand-cranked vertical 
ones or the big sliding curved ones. 

Any feedback on these 5 points? 

Javbw. 


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

Re: [Tagging] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

2017-03-23 10:30 GMT+01:00 Jean-Marc Liotier :

> As the "complex intersections" section of the highway=traffic_signals
> page describes a gradation of model complexity
> (https://wiki.openstreetmap.org/wiki/Tag:highway%
> 3Dtraffic_signals#Complex_intersections),
> maybe coexistence is also possible between simple tagging of a
> highway=stop+direction=forward node on the way to an intersection and a
> complex relation-based model for more complex cases: having a simple
> model that covers most cases has such significant benefit that I would
> say it more than offsets the cost of having more than one way to do it.
>


If we choose to trade off  stability / disambiguity / reliability for a
little less complexity (no relation), the better solution is positioning
the node for the sign not on the highway but in the driving direction close
to it to the side (could be sold as "actual sign position" save some
exceptions). This way you have the direction implicitly stored and don't
depend on other ways, but there is the risk of someone dragging the node
with the sign or the highway so far away that another (unrelated) highway
comes closer.

Both variants require postprocessing anyway (either you have to look for a
closeby highway or for the direction of the way(s) your node is part of).

Yet another option would be to use tiny way stubs for the signs, these
would have a direction (and could even imply a default sign direction if
defined like that).

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

Re: [Tagging] Spillways

[John Sturdy]

I suppose  waterway=weir plus intermittent=yes  would describe it, but I
don't think that's as good as a specific spillway tag.

On Thu, Mar 23, 2017 at 6:52 AM, Andrew Harvey 
wrote:

> On 22 March 2017 at 16:56, Dave Swarthout  wrote:
> > Weir does not seem appropriate for this type of thing. There is a tag,
> > waterway=spillway, that seems like a good fit - 81 uses so far.
>
> I've seen these tagged as waterway=drain which is close but agree that
> waterway=spillway is better. Would be great to have this documented on
> the wiki.
>
> ___
> 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] traffic_signals:direction=* vs. direction=*

[Martin Koppenhoefer]

sent from a phone

> On 23 Mar 2017, at 01:41, Tod Fitch  wrote:
> 
> And if not on an intersection node then it should be placed at the stop line. 
> [2] I don’t think we are likely to have a stop line in the middle of an 
> intersection. :)


think of a cycleway or a driveway for example. Maybe also non-highways.

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

Re: [Tagging] water=pool

[Andrew Harvey]

On 22 March 2017 at 18:53, Dave Swarthout  wrote:
> You might use waterway as the main tag to prevent confusion with the
> top-level tag of water=*
>
> Either waterway=pool (TagInfo: 26 uses), or waterway=stream_pool, would be
> better than water=stream_pool. I still think it better to avoid using the
> word stream in the value because then a pool on a river would have these two
> tags, which might look strange to some people:
> waterway=river
> waterway=stream_pool
>
> This tagging seems more "logical" IMO:
> waterway=river
> waterway=pool
>
> The existing waterway=pool objects seem to be either small ponds where one
> can bathe or some sort of natural=basin.

On 22 March 2017 at 20:24, Martin Koppenhoefer  wrote:
> I would prefer water over waterway as a key, because this is about 
> areas/polygons, for which we typically use natural=water and subtags. This 
> would also allow to keep waterway=riverbank for the whole stream-/river-area 
> (which is so far the only significant exception where waterway is used for 
> areas and not as a linear graph model).
> I would be ok with leisure as well, although this is mostly used for 
> artificial features so far, and there might raise some confusion with 
> "ordinary" swimming pools.

I agree, these are a "body of water" along the waterway. In the ones
I've mapped so far you have the waterway feature usually as a linear
way and then these water=stream_pool areas over that stream way.

If you've mapped the waterway as an area, why not have these as
separate water=stream_pool areas?

On 23 March 2017 at 05:22, Mark Bradley  wrote:
> To categorize these pools as a subcategory of leisure seems shortsighted to 
> me, because that may not be the only use for them, just as not all swimming 
> pools are for leisure.  I would prefer they be tagged as a value of water or 
> waterway, instead of inferring they are only for leisure.

Agreed.

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

Re: [Tagging] Spillways

[Andrew Harvey]

On 22 March 2017 at 16:56, Dave Swarthout  wrote:
> Weir does not seem appropriate for this type of thing. There is a tag,
> waterway=spillway, that seems like a good fit - 81 uses so far.

I've seen these tagged as waterway=drain which is close but agree that
waterway=spillway is better. Would be great to have this documented on
the wiki.

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