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

[Tod Fitch]

> On Mar 22, 2017, at 4:51 PM, yo paseopor  wrote:
> 
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
> 
> I think to include direction inside the tag with a subkey :forward :backward 
> following the scheme for lanes and so one are the best option instead of 
> using a specific key as direction because we save one key, and we follow a 
> well-known scheme.
> Other thing is the side of the road the traffic sign is , as it changes the 
> form and the style of it (motorway panel vs. little traffic sign on the right 
> side of a road)
> 

“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.

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

> On Mar 22, 2017, at 4:57 PM, Martin Koppenhoefer  
> wrote:
> 
> generally it is unsafe to rely on a "direction" like forward or backward as 
> tag on a node. Nodes do not have directions, and there is no relation from a 
> node to a single way, the relation is from a way to a node and many ways can 
> reference the same node, that's not an error. 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?

Good point. Although one might suggest that it is a theoretical situation as 
the definition of the stop tag [1] indicates that if on the node connecting 
multiple then it is a all way stop. 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. :)

[1] https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#All-way_stop
[2] 
https://wiki.openstreetmap.org/wiki/Tag:highway%3Dstop#Tagging_minor_road_stops




smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Spillways

[John Willis]

Ah yea, emergency=yes is bad.

3 questions: 

- mapping levees/dykes with additional area extent tags (like river+ riverbank) 

- mapping spillways in a similar fashion. 

- mapping levee control gates (buried in the levee) 

~~



Javbw
> On Mar 22, 2017, at 9:42 PM, Greg Troxel  wrote:
> 
> Also, presumably emergency spillways are mapped as areas, rather than
> lines,

What is interesting to me is that dykes (levees) are mapped as ways, though 
they can easily be mapped as areas. The levees around this system, about 10-15m 
tall and 40m wide are easily mappable from imagery and often have multiple ways 
that sit halfway up, on top, and transverse it, often all at once. 

If the minimum acceptable use is the way drawn on top of the levee, then there 
should be a tag similar to "riverbank" to map the extent of the levee to the 
sides. 

Maybe people are familiar with smaller dykes/levees, but I have never seen an 
entire 300km river system entirely encased in 10m levees before. And they are 
thinking of making the ones near the Tokyo Metro Area 20m. Mapping the area 
that such man-made structures extend from center seems like a no-brainer. 

I think the same would be true for a spillway - where the "top" of the spillway 
is, similar to the dyke tag, is probably the most important info, then it's 
area. 

Finally, wrapping up this tagging, of this levee system, there are hundreds of 
automatic/manual water control gates less than 1 meter wide to let streams and 
drains into the levee. There are about 100 larger 2-4m gates for larger streams 
and small rivers. 

Most of these small sized ones are buried in the dyke/levee, and the 
control structure built out from the side of the levee, sometimes with a little 
building on top to protect the mechanism for lowering/raising the gate, is a 
common occurrence. How would I tag such a feature? They are easily seen on 
aerial imagery.

https://goo.gl/maps/YKf3cMabUXn
The white structure is built to stabilize the control structure sticking up. 
The gate is buried in the levee and the exit can be seen near the water. The 
structure above is easily seen (some kind of building or man_made tag), and the 
valve/gate structure below  is easily mapped as a node on the waterway. There 
are hundreds and hundreds of these gates. 

Javbw 


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

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

[Martin Koppenhoefer]

generally it is unsafe to rely on a "direction" like forward or backward as
tag on a node. Nodes do not have directions, and there is no relation from
a node to a single way, the relation is from a way to a node and many ways
can reference the same node, that's not an error. 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?

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

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

[yo paseopor]

>
> Anyone else with an opinion ? Two of us might be the very beginning of a
> consensus but we need a little more before even putting a proposal
> page up on the wiki...
>

I think to include direction inside the tag with a subkey :forward
:backward following the scheme for lanes and so one are the best option
instead of using a specific key as direction because we save one key, and
we follow a well-known scheme.
Other thing is the side of the road the traffic sign is , as it changes the
form and the style of it (motorway panel vs. little traffic sign on the
right side of a road)

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

Re: [Tagging] Adding directionality to stop signs

[yo paseopor]

On Wed, Mar 22, 2017 at 11:31 AM, Paul Johnson  wrote:

>
> Turn restrictions are extremely common and managed using relations, so we
> know relations don't have to be hard.  It's possible for the editors to
> adapt to make this easy.  There's no real reason enforcement and similar
> from/to/device/force type relations can't be made easy at the editor level.
>

I ask why we need a relation to put a traffic sign if it is in a way (not
at intersection), and with the information of the correspondence of the
direction of the way it is with a relation . Is duplicate work?

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

Re: [Tagging] how to care about different seasonal road close?

[Warin]

On 23-Mar-17 08:52 AM, Kevin Kenny wrote:
On Wed, Mar 22, 2017 at 5:35 PM, Micah Cochran > wrote:


You might use the "seasonal" key, which seems like it might
already be used to indicate if a highway is open or closed
seasonally.  I can't find a proposal for that use.

This could be seasonal=spring;summer;autumn

There are 54,768 instances of seasonal=yes, which seems fairly
useless unless you are referring to natural phenomenon (streams).


Uhm, it's less than general, but sometimes obvious in context. In my 
part of the world, a seasonal road is one where they don't trouble to 
plow the snow. Sometimes up in the peaks, that means the road will be 
impassable from mid-October to mid-May in a severe year. However, most 
of the seasonal roads are posted "open April 15-October 31" but in 
practice they will open as soon as they can get crews in to clean up 
the inevitable spring rock slides and stay open until there's too much 
snow for a police car.


I have no idea how to encode all that in tagging. It depends on the 
weather and the judgment of the highway department.


Frequently things are tagged open 9 to 5 .. but  some open a little 
earlier and close a little later depending on staff and customers.
So I would use the 'open April 15-October 31' as the tag to use as this 
would give a certain route,
a non local may not be a good judge of snow conditions for closing date 
nor the opening activity.
You could add a note to the actual conditions .. but I don't think it 
will render in any usefull way, better to stick to the 'open April 
15-October 31'.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] how to care about different seasonal road close?

[Kevin Kenny]

On Wed, Mar 22, 2017 at 5:35 PM, Micah Cochran  wrote:

> You might use the "seasonal" key, which seems like it might already be
> used to indicate if a highway is open or closed seasonally.  I can't find a
> proposal for that use.
>
> This could be seasonal=spring;summer;autumn
>
> There are 54,768 instances of seasonal=yes, which seems fairly useless
> unless you are referring to natural phenomenon (streams).
>

Uhm, it's less than general, but sometimes obvious in context. In my part
of the world, a seasonal road is one where they don't trouble to plow the
snow. Sometimes up in the peaks, that means the road will be impassable
from mid-October to mid-May in a severe year. However, most of the seasonal
roads are posted "open April 15-October 31" but in practice they will open
as soon as they can get crews in to clean up the inevitable spring rock
slides and stay open until there's too much snow for a police car.

I have no idea how to encode all that in tagging. It depends on the weather
and the judgment of the highway department.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] how to care about different seasonal road close?

[Micah Cochran]

You might use the "seasonal" key, which seems like it might already be used
to indicate if a highway is open or closed seasonally.  I can't find a
proposal for that use.

This could be seasonal=spring;summer;autumn

There are 54,768 instances of seasonal=yes, which seems fairly useless
unless you are referring to natural phenomenon (streams).

However, I wouldn't count on routing software to recognize this key.  It
would be nice if the software would warned you that this route might be
closed for the season.

I would use that tagging scheme at your own risk.

Regards,
Micah
-- 

*Micah Cochran*

GIS Coordinator  -  City of Athens  -  Engineering Services & Community
Development Dept.  -  Dept. of Public Works Building  -  1600 ELM ST W,
Athens, AL   - geo:34.820608,-86.991474 -  p.
256-233-2224  -  f. 256-233-8791 - www.athensalabama.us

On Thu, Mar 16, 2017 at 9:02 AM, Hakuch  wrote:

> The road after this point (northwards) is closed in the winter season.
>
> https://www.openstreetmap.org/note/917369#map=17/50.79221/15.32156
>
> But like Petr says, its each year another time. I had the bad luck to
> route through this street with maps.me because it is not tagged for
> 2017, OSRM seems to not care for the year and does not route there. But
> graphhopper and mapzen does. And Maps.me, and because it is really a
> dead end when you went up there by car its a long way backwards..
>
> So, is there a solution how to deal with roads like this, where you know
> that the road will be closed but you dont know the exact time? Because
> like here, people will forget to tag it for each year.
>
> ___
> 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] water=pool

[Mark Bradley]

> Date: Wed, 22 Mar 2017 10:24:39 +0100
> From: Martin Koppenhoefer 
> To: daveswarth...@gmail.com, "Tag discussion, strategy and related
>   tools" 
> Subject: Re: [Tagging] water=pool
> Message-ID: 
> 
> 
> 
> sent from a phone
> 
> > On 22 Mar 2017, at 08:53, Dave Swarthout  wrote:
> >
> > Either waterway=pool (TagInfo: 26 uses), or waterway=stream_pool, would be
> better than water=stream_pool.
> 
> 
> 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.
> 
> 
> cheers,
> Martin


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.

Mark



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

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

[Tod Fitch]

Quoted sections have been edited down to only show parts I am responding to:

> On Mar 22, 2017, at 5:37 AM, Greg Troxel  wrote:
> 
> For highway=traffic_signals, the normal situation is that it's on a
> node, and affects all ways entering the node.  Or it's on a way and
> affects both directions -- in my experience, when there are traffic
> lights not at an intersection, they are always for both directions (even
> though in theory they could be set up for one direction only).

CalTrans has used semi-permanent traffic signals to control traffic flow over 
damaged road sections. A light at each side of the damaged area controls the 
sequentially one-way traffic through the damaged area that has been reduced to 
one lane operation. I’ve seen these in the Santa Cruz mountains, but the 
longest section of road I’ve seen controlled this way was on the main road to 
Yosemite Valley where the side of the mountain came down on the main roadway 
and the work around, in place for several years, was to put some pavement on 
the old single track railway grade on the other side of the river and put two 
bridges in place to get traffic across and back. It maybe still in place while 
but I’ve not been through there in several years. I know they took a long time 
to decide what to do about the still unstable mountain above the covered 
section of highway.

So there are places with traffic signals away any intersections that control 
traffic going into a one lane section. I guess a smart router could guess that 
the transition of a road from two lanes to one lane would count as an 
intersection but that seems an error prone algorithm. Having a direction tag of 
some sort available does make tagging this situation possible.

> As a human, if I see a highway=stop on a way about 3-10m from an
> intersection, it's obvious that it applies to travel on the way towards
> the intersection, but not leaving the intersection.  However, I think
> OsmAnd sometimes falses on these.

OsmAnd always seems to “false on” these. To the point where I ignore the stop 
warning it gives.

> I would suggest a definition that associates the stop sign with the
> nearest intersection if it's less than 25m away, and there are no
> intersections in the other direction within 3x that closest intersection
> distance.  And then to use relations to label which intersection, if the
> above doesn't work.

Sounds like a reasonable thing to add some distances to the wiki where it 
describes that algorithm but without specific distance numbers.

> . . .   I view this whole exercise as designing tagging rules
> that are good for human editors and acceptable (semantically non-kludgy
> and reasonably easily implementable) for data consumers.

+1 on that.




smime.p7s
Description: S/MIME cryptographic signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Starbucks or Starbucks Coffee

[Dave Swarthout]

On Tue, Mar 21, 2017 at 5:18 AM, Martin Koppenhoefer  wrote:
I would tag them as internet cafes, you can't get serious coffee there.
;-)

I agree 100%. The big thing Starbucks has going for it, speaking as a
coffee snob, is that their product is uniformly mediocre world wide.

On Wed, Mar 22, 2017 at 6:47 PM, Lorenzo "Beba" Beltrami <
lorenzo.b...@gmail.com> wrote:

> 2017-03-22 10:21 GMT+01:00 Paul Johnson :
>
>> ...and that's how Martin was found murdered under the Alaska Way Viaduct.
>>
>
> I'm really sorry for the OT, but this moment is perfect for this:
> http://brilliantmaps.com/italian-food/
>
> Lorenzo
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Spillways

[Greg Troxel]

Martin Koppenhoefer  writes:

> sent from a phone
>
>> On 22 Mar 2017, at 09:15, Jean-Marc Liotier  wrote:
>> 
>> I answered too fast... Later in the thread John offers
>> waterway=spillway + emergency=yes + surface=* which seem even better
>> because it uses the generic emergency=yes instead of creating a new
>> spillway=emergency
>
>
> but emergency=yes is a legal access tag. Are there spillways that are
> used as roads? With spillway=emergency it is made explicit that this
> is a spillway category, not an access tag

Agreed. I was going to say that reusing emergency=yes was going to cause
trouble.

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 - the point
is to avoid erosion if it is ever used, to protect the dam from collapse
which might happen if the primary spillway overflowed.




signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

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

[Greg Troxel]

-- 
Dave Swarthout  writes:

> This is embarrassing but relevant to this conversation. I've been mapping
> intensely for several years but adding stop signs was something I rarely
> did.

I only started adding stop signs within the last year.  Probably I
started because OsmAnd will give a warning, and that's good, as long as
there is no one else in the car :-)

> In hindsight, it's perfectly obvious when one considers routing engines
> that any highway=stop node must affect traffic in both directions unless
> made explicit in some fashion, or else ignored as OSMand seems to do. So
> far, I've only added 45 highway=stop nodes in Alaska and 18 in Thailand.
> I'll be revisiting them to add the appropriate direction tags in the not
> too distant future.

I don't think it's obvious...

For highway=traffic_signals, the normal situation is that it's on a
node, and affects all ways entering the node.  Or it's on a way and
affects both directions -- in my experience, when there are traffic
lights not at an intersection, they are always for both directions (even
though in theory they could be set up for one direction only).

Stop signs, on the other hand, are for the most part sort of properties
of intereections, except that the normal cases are that some ways have
them and some don't, or that all ways have them.  (Around me, some is
much more common than all, but all isn't odd.)

As a human, if I see a highway=stop on a way about 3-10m from an
intersection, it's obvious that it applies to travel on the way towards
the intersection, but not leaving the intersection.  However, I think
OsmAnd sometimes falses on these.

I had the impression that there was supposed to be a relation with the
intersection node, which seems somewhat awkward.

I would suggest a definition that associates the stop sign with the
nearest intersection if it's less than 25m away, and there are no
intersections in the other direction within 3x that closest intersection
distance.  And then to use relations to label which intersection, if the
above doesn't work.

> As to an opinion about how to implement their tagging, I would tend to go
> with the ones that resemble the directionality tags already in use for
> lanes, i.e., lanes:forward=* and lanes:backward=* except that it's awfully
> verbose. I automate much of my tagging with custom presets in JOSM so
> adding complicated, long tags to them isn't difficult but asking casual
> mappers to enter these very long tags like
> "traffic_signals:direction=forward" is going to be problematical IMO.
> Consequently, I would lean towards keeping it simple and
> using direction:forward/backward to indicate directionality, at least for
> nodes.

That sounds ok to me too, but it seems that it should be mostly
unnecessary.   I view this whole exercise as designing tagging rules
that are good for human editors and acceptable (semantically non-kludgy
and reasonably easily implementable) for data consumers.



signature.asc
Description: PGP signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Starbucks or Starbucks Coffee

[Lorenzo "Beba" Beltrami]

2017-03-22 10:21 GMT+01:00 Paul Johnson :

> ...and that's how Martin was found murdered under the Alaska Way Viaduct.
>

I'm really sorry for the OT, but this moment is perfect for this:
http://brilliantmaps.com/italian-food/

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

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

[Paul Johnson]

On Mon, Mar 20, 2017 at 12:46 PM, LeTopographeFou  wrote:

> In real life a traffic light is more often associated to another device
> such as a camera, a pedestrian light... than stop signs which stands
> generally on their own. So direction=* might be enought for stops and
> give_ways most of the time for most of the mappers and editors.


Stop signs also get used at signalized intersections in the US with
annoying frequency.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding directionality to stop signs

[Paul Johnson]

On Tue, Mar 21, 2017 at 6:57 AM, Simone Saviolo 
wrote:

> BTW the Stop sign is even more frequent in Italy than in the US, but it
>> influences much less the travel time, because drivers simply don't stop
>> most of the time, contrary to the practice in the US, or Germany, or the UK.
>>
>
> Don't confuse the give way sign with the stop sign. Stop requires the
> driver to stop, even in Italy. Sure, many people don't, but that doesn't
> mean they should :)
>

Coincidentally, solving the directionality problem of stop signs also
solves the problem for yield and potentially "_ turn permitted without
stopping" movements.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding directionality to stop signs

[Paul Johnson]

Missed replying to this earlier...

On Mon, Mar 20, 2017 at 11:36 AM, Volker Schmidt  wrote:

> I would consider having to create (and manage) relations for this tedious,
> and error prone in case of editing.


Turn restrictions are extremely common and managed using relations, so we
know relations don't have to be hard.  It's possible for the editors to
adapt to make this easy.  There's no real reason enforcement and similar
from/to/device/force type relations can't be made easy at the editor level.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Adding directionality to stop signs

[Paul Johnson]

On Mon, Mar 20, 2017 at 11:36 AM, Volker Schmidt  wrote:

> Given the effect of the stopping process on the overall travel time
> (mainly for cars), we need a way that can be used by routing algorithms.
>

It's even worse with bicycles, since actual human effort has to happen to
accelerate from a stop.   And even more annoying, far more frequent in some
parts of the country.  Seattle used to be a worst offender, sometimes
having 20+ stop signs per mile on what's meant to be the main bike route
through the area

.


> I am inserting them in quantity, but only in the simple way of a node on
> the way. "My" stop signs apply to the nearest junction.
>

I do this as well, though this seems less than ideal for complicated
situations like the Elm Street underpass under the Creek Turnpike
, without getting into the fact
that putting a stop sign for bicycles at an intersection every other
direction and even pedestrians in the same direction get a traffic signal
is *intensely* stupid ground truth to start with).


> This should in principle allow a routing algorithm to determine the
> directionality of the sign. I would consider having to create (and manage)
> relations for this tedious, and error prone in case of editing.
>

Short Street  immediately ruins
this assumption.  The southbound stop sign protecting Canyon Road is almost
in Beaverdam Alley.


> BTW the Stop sign is even more frequent in Italy than in the US, but it
> influences much less the travel time, because drivers simply don't stop
> most of the time, contrary to the practice in the US, or Germany, or the UK.
>

It's getting to be that way in the US, especially for bicycle facilities.
Even USDOT has acknowledged this, and as recently as the 2009 MUTCD,
warrants stop signs only when a yield sign would not be a safe alternative.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] water=pool

[Martin Koppenhoefer]

sent from a phone

> On 22 Mar 2017, at 08:53, Dave Swarthout  wrote:
> 
> Either waterway=pool (TagInfo: 26 uses), or waterway=stream_pool, would be 
> better than water=stream_pool.


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.


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

Re: [Tagging] Spillways

[Martin Koppenhoefer]

sent from a phone

> On 22 Mar 2017, at 09:15, Jean-Marc Liotier  wrote:
> 
> I answered too fast... Later in the thread John offers
> waterway=spillway + emergency=yes + surface=* which seem even better
> because it uses the generic emergency=yes instead of creating a new
> spillway=emergency


but emergency=yes is a legal access tag. Are there spillways that are used as 
roads? With spillway=emergency it is made explicit that this is a spillway 
category, not an access tag


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

Re: [Tagging] Spillways

[Jean-Marc Liotier]

On Wed, 22 Mar 2017 09:12:02 +0100
Jean-Marc Liotier  wrote:

> On Wed, 22 Mar 2017 12:56:49 +0700
> Dave Swarthout  wrote:
> >
> > You could also add emergency=yes to the above or create a new tag,
> > emergency=spillway  
> 
> waterway=spillway
> spillway=emergency
> 
> https://taginfo.openstreetmap.org/tags/waterway=spillway#overview

I answered too fast... Later in the thread John offers
waterway=spillway + emergency=yes + surface=* which seem even better
because it uses the generic emergency=yes instead of creating a new
spillway=emergency

spillway=* would only become preferable if a taxonomy of spillways
exists (such as main, secondary, emergency etc.)

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

Re: [Tagging] Spillways

[Jean-Marc Liotier]

On Wed, 22 Mar 2017 12:56:49 +0700
Dave Swarthout  wrote:
>
> You could also add emergency=yes to the above or create a new tag,
> emergency=spillway

waterway=spillway
spillway=emergency

https://taginfo.openstreetmap.org/tags/waterway=spillway#overview

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

Re: [Tagging] water=pool

[Dave Swarthout]

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.

Dave



On Wed, Mar 22, 2017 at 2:32 PM, John Willis  wrote:

>
> On Mar 13, 2017, at 5:22 PM, Martin Koppenhoefer 
> wrote:
>
> I'd rather use water=stream_pool without the lake deviation, but then it
> still is in conflict with water=river. Are these actual features anyway, or
> are they simply the wider parts of the river?
>
>
> +1 for stream_pool.
>
> The features they are talking about are usually where a normally shallow
> stream feeds into topography (man made or natural)  that creates a much
> deeper/wide/slower moving section of the tiny stream than “normal",
> allowing someone to reasonably submerge their body, or jump into. this is
> an “attraction” of the stream, usually used by people hiking or playing in
> the water. Some of them may be locally famous.
>
> Ah!
>
> I would put these under leisure. they are only useful for some kind of
> leisure activity.
>
> If I was interested in tagging the features of a certain spot for campers
> or backpackers to set up a tent, (like micromapping a part of a park), then
> mapping these might be useful, as you might choose one location over
> another based on having this pool available.
>
> having water=pool sounds like a recipe for incorrectly tagged swimming
> pools.
>
> Javbw
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
>


-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] water=pool

[John Willis]

> On Mar 13, 2017, at 5:22 PM, Martin Koppenhoefer  
> wrote:
> 
> I'd rather use water=stream_pool without the lake deviation, but then it 
> still is in conflict with water=river. Are these actual features anyway, or 
> are they simply the wider parts of the river?

+1 for stream_pool.  

The features they are talking about are usually where a normally shallow stream 
feeds into topography (man made or natural)  that creates a much 
deeper/wide/slower moving section of the tiny stream than “normal", allowing 
someone to reasonably submerge their body, or jump into. this is an 
“attraction” of the stream, usually used by people hiking or playing in the 
water. Some of them may be locally famous. 

Ah! 

I would put these under leisure. they are only useful for some kind of leisure 
activity.

If I was interested in tagging the features of a certain spot for campers or 
backpackers to set up a tent, (like micromapping a part of a park), then 
mapping these might be useful, as you might choose one location over another 
based on having this pool available. 

having water=pool sounds like a recipe for incorrectly tagged swimming pools. 

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

Re: [Tagging] Spillways

[John Willis]

> On Mar 22, 2017, at 3:15 PM, Bill Ricker  wrote:
> 
> ​or use surface tags to distinguish the paved from unpaved​ as we do with 
> roads ?


This section is paved, but it is the function of the wall of dirt with asphalt 
on top I’m trying to map. 

someone actually took a picture out there in the winter.  
https://goo.gl/maps/QfrZfUiVze22  

The old way (beyond the gate) disappears, as the top of the old levee was 
removed, lowering it by 3-5m. https://goo.gl/maps/bTdcVV6H9pn 
 . This is covered by asphalt (to protect 
against erosion), and it is an embankment (holding back water during flooding), 
but it’s function is a spillway. the river to the right is the path to the sea. 
The entire inner reservoir (way off to the left) has concrete walls. Wether is 
is concrete, asphalt, or earth, it could be a dam, a spillway (with/without 
control gates), or an emergency spillway, if the normal one is in danger of 
being overtopped. in this case, the emergency spillways protect the gates to 
the south and the homes to the west. if you pan the photo 180 degrees (look 
behind “you”), you can see the gates it is protecting. 


The dam and a weir have the same job - to hold back water. a weir usually holds 
back water to feed into a pipe or some other use for the water, as a dam does, 
but is designed to be overtopped. it is often submerged, being overtopped, 
while doing it’s main function of routing water into a pipe or making a lake or 
similar.
a spillway's sole job is to get rid of excess water, for the safety or planning 
the use of the dam’s capacity. it is a feature of the dam (or other water 
control system), not the main feature itself. in this case, the spillway is a 
part of the levee system.

waterway=spillway + emergency=yes, + surface=* as the spillway is for 
emergencies seems appropriate. 

Thanks for the feedback. 

Javbw

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

Re: [Tagging] Spillways

[Bill Ricker]

On Wed, Mar 22, 2017 at 1:56 AM, 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.
>
> You could also add emergency=yes to the above or create a new tag,
> emergency=spillway
>

​or use surface tags to distinguish the paved from unpaved​ as we do with
roads ?



-- 
Bill Ricker
bill.n1...@gmail.com
https://www.linkedin.com/in/n1vux
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging