[Tagging] Drafting proposal: use oneway=reversible or create tag?

[David Marchal]

Hello, there.
I'm drafting a proposal concerning some waterways whose flow regularly changes 
direction, which happens near some sinkholes named estavelles, which drain or 
feed water according to the aquifer level. I would consequently propose a way 
to map it, but it should be consistent with current tags, so I wondered: should 
I propose using
oneway=reversible, as it already exists and can be used on other ways than 
roads, according to the wiki, but would in this case be used to indicate that 
something is _not_ oneway, oranother tag, such as twoway=yes, which could be 
clearer in this context of a way you would expect to be oneway, but at the risk 
of duplicating the use of oneway=no?
Hoping you can help,
Regards.
  ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[moltonel 3x Combo]

On 07/09/2015, David Marchal  wrote:
> I'm drafting a proposal concerning some waterways whose flow regularly
> changes direction, which happens near some sinkholes named estavelles, which
> drain or feed water according to the aquifer level. I would consequently
> propose a way to map it, but it should be consistent with current tags, so I
> wondered: should I propose using
> oneway=reversible, as it already exists and can be used on other ways than
> roads, according to the wiki, but would in this case be used to indicate
> that something is _not_ oneway, oranother tag, such as twoway=yes, which
> could be clearer in this context of a way you would expect to be oneway, but
> at the risk of duplicating the use of oneway=no?

Don't use oneway=*: it relates to the direction that vehicles (in this
case boats) are allowed to take, not to the waterflow.

I don't know of an existing tag. I've searched for 'flow' and
'up/downstream' in taginfo, but the only thing I found came from
imports and had very bad values from an OSM POV. Unless somebody has a
better Idea, I suggest creating a tag.
waterway:flow=forwards/backwards come to my mind, but that's an
endlessly bikeshedable topic.

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

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[Martin Koppenhoefer]

2015-09-07 17:57 GMT+02:00 moltonel 3x Combo :

> I don't know of an existing tag. I've searched for 'flow' and
> 'up/downstream' in taginfo, but the only thing I found came from
> imports and had very bad values from an OSM POV. Unless somebody has a
> better Idea, I suggest creating a tag.
> waterway:flow=forwards/backwards come to my mind, but that's an
> endlessly bikeshedable topic.
>


there are some very few occurences of previously mentioned "flow_direction"
http://taginfo.osm.org/keys/flow_direction#overview
we could also use incline=up/down (is in use, but rarely in conjunction
with waterways)

More often I found the undocumented "oneway:flow"
http://taginfo.osm.org/keys/oneway%3Aflow
(there is a oneway restriction in flow direction?) values are yes/no.

There are also 634 times "FlowDir" (atypical key name, likely from an
import)

Personally from the values in use that I found I'd go with "flow_direction"
(values in use are "forward" and "both"), because its not an abbreviation
and quite verbose in what it is describing. "oneway:flow" doesn't make much
sense to me.

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

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[Volker Schmidt]

It seems that oneway:flow=yes|no is extensively used in Florida and
oneway:flow=yes appears on most of the length of the Missisippi.
I suppose it's used in the same sense as you want to use your proposed tag

On 7 September 2015 at 17:29, David Marchal  wrote:

> Hello, there.
>
> I'm drafting a proposal concerning some waterways whose flow regularly
> changes direction, which happens near some sinkholes named estavelles,
> which drain or feed water according to the aquifer level. I would
> consequently propose a way to map it, but it should be consistent with
> current tags, so I wondered: should I propose using
>
>
>1. oneway=reversible, as it already exists and can be used on other
>ways than roads, according to the wiki, but would in this case be used to
>indicate that something is _not_ oneway, or
>2. another tag, such as twoway=yes, which could be clearer in this
>context of a way you would expect to be oneway, but at the risk of
>duplicating the use of oneway=no?
>
>
> Hoping you can help,
>
> Regards.
>
>
> ___
> 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] Drafting proposal: use oneway=reversible or create tag?

[Volker Schmidt]

I am need of a tag for this for many waterways near the sea here, as there
waterflow is controlled by gates or is tidal or is both. I like
flow_direction.

However it's a tricky business. Take the river Thames, which can be tidal
up to London, depending on tides (and wind). But I would be reluctant to
tag the river's water flow from London downwards as flow_direction=both

Also, one needs more values:
flow_direction=forward|backward|tide_dependent|operator_controlled|...
default value: forward

I also would like to tag one-way sluice gates ("porte vinciane") that work
as back-flow-protection valves in waterways, typically to prevent the
influx of saline water at high tide. I have used sluice_gate and lock_gate
for this, but am unhappy about both.

On 7 September 2015 at 18:16, Martin Koppenhoefer 
wrote:

>
> 2015-09-07 17:57 GMT+02:00 moltonel 3x Combo :
>
>> I don't know of an existing tag. I've searched for 'flow' and
>> 'up/downstream' in taginfo, but the only thing I found came from
>> imports and had very bad values from an OSM POV. Unless somebody has a
>> better Idea, I suggest creating a tag.
>> waterway:flow=forwards/backwards come to my mind, but that's an
>> endlessly bikeshedable topic.
>>
>
>
> there are some very few occurences of previously mentioned
> "flow_direction" http://taginfo.osm.org/keys/flow_direction#overview
> we could also use incline=up/down (is in use, but rarely in conjunction
> with waterways)
>
> More often I found the undocumented "oneway:flow"
> http://taginfo.osm.org/keys/oneway%3Aflow
> (there is a oneway restriction in flow direction?) values are yes/no.
>
> There are also 634 times "FlowDir" (atypical key name, likely from an
> import)
>
> Personally from the values in use that I found I'd go with
> "flow_direction" (values in use are "forward" and "both"), because its not
> an abbreviation and quite verbose in what it is describing. "oneway:flow"
> doesn't make much sense to me.
>
> 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] Proposed mechanical edit: surface=soil to surface=dirt (history (authors of changesets))

[Ruben Maes]

Wednesday 02 September 2015 13:51:09, André Pirard:
> What policy, what purpose, that's unclear?
> Is OSM.org using that API to display the history on the screen illegal?
> Is Osmose using it to attribute errors to some user illegal?
> Yep, I suppose that making oneself a complete list of OSM users is 
> inappropriate.

No, the osm.org site doesn't use the API. Rather, it queries the database 
directly.

I think it's not about "illegal" in the sense of prohibited out of privacy 
concerns or the like, but about the fact that we don't have unlimited capacity 
and that mappers mapping should not be hindered by people that want to query 
the API for unrelated uses.

-- 
The field "from" of an email is about as reliable as the address written on the 
back of an envelope. That's why this message is OpenPGP signed.

signature.asc
Description: This is a digitally signed message part.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[moltonel]

On 7 September 2015 17:38:45 GMT+01:00, Volker Schmidt  
wrote:
>tidal
>up to London, depending on tides (and wind). But I would be reluctant
>to
>tag the river's water flow from London downwards as flow_direction=both

Yes, rivers can be tidal without their flow reversing. The water level can rise 
during the rising tide but still flow toward the sea. tidal=yes is a fairly 
common tag.

>Also, one needs more values:
>flow_direction=forward|backward|tide_dependent|operator_controlled|...
>default value: forward

LGTM

I'd advise against any up/down value because the question normaly only arrises 
when the relief is fairly flat.
-- 
Vincent Dp

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

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[Warin]

On 8/09/2015 2:16 AM, Martin Koppenhoefer wrote:


2015-09-07 17:57 GMT+02:00 moltonel 3x Combo >:


I don't know of an existing tag. I've searched for 'flow' and
'up/downstream' in taginfo, but the only thing I found came from
imports and had very bad values from an OSM POV. Unless somebody has a
better Idea, I suggest creating a tag.
waterway:flow=forwards/backwards come to my mind, but that's an
endlessly bikeshedable topic.



there are some very few occurences of previously mentioned 
"flow_direction" http://taginfo.osm.org/keys/flow_direction#overview
we could also use incline=up/down (is in use, but rarely in 
conjunction with waterways)


key incline
The use of incline tag is presently for a fixed difference in height 
over some distance.
For tidal flows the incline is not fixed (varies with time, moon 
position etc), so I would not use this tag.

It goes against OSM present practice.


More often I found the undocumented "oneway:flow" 
http://taginfo.osm.org/keys/oneway%3Aflow

(there is a oneway restriction in flow direction?) values are yes/no.

The word "oneway" to me imply the direction is one way ONLY.


There are also 634 times "FlowDir" (atypical key name, likely from an 
import)


Personally from the values in use that I found I'd go with 
"flow_direction" (values in use are "forward" and "both"), because its 
not an abbreviation and quite verbose in what it is describing. 
"oneway:flow" doesn't make much sense to me.





Flow direction is the best of these (so far). It is descriptive of what 
is to be tagged.
It may also be used for other things (carrying anything) .. the tag 
should not be restricted to just water ... while that is the common 
application .. why restrict it?
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Drafting proposal: use oneway=reversible or create tag?

[johnw]

> On Sep 8, 2015, at 9:46 AM, Warin <61sundow...@gmail.com> wrote:
> 
> Flow direction is the best of these (so far). It is descriptive of what is to 
> be tagged. 

What do they use for pipelines? I imagine there is some tag based on the way 
direction that can indicate flow. 

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

[Tagging] barrier enforcing maxwidth

[johnw]

I was driving in Chiba and Saitama yesterday and encountered a couple new types 
of barriers. I realized later one is traffic_calming=chicane. 


The other one is all over rural Japan as traffic_calming=choker on rural roads 
that could bypass traffic near the rivers, - but this one is not for traffic 
calming, it is for enforcement of maxwidth of the bridge, similar to 
barrier=hight_restrictor. 
. They put very strong steel poles or guardrails along the sides and center of 
the road at the maxwidth + 20 cm of a standard car.  car can pass (barely, my 
mirrors were 5 cm away from each pole), but a large dump truck cannot pass. 
Both are in areas where commercial dump trucks or other large vehicles are 
nearby, but this one is used to enforce access to the narrow bridge near a very 
very busy area to keep a massive traffic jam from occurring from a stuck dump 
truck. 

https://goo.gl/maps/8KUw7   The maxwidth is signed 
and guardrails are doing the job. This is width limited for the very narrow 
bridge in the background. 

https://goo.gl/maps/3NT9X   The other direction. 
Poles are used. 

Is this a reason for creating barrier=width_restrictor ? 


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

Re: [Tagging] barrier enforcing maxwidth

[Andrew Errington]

I don't think a new tag is warranted.  maxwidth=* is fairly unequivocal.
If map users or routers want to interpret it as "max width, but probably
not really, there's probably a bit of extra space, I mean, who's going to
be that petty" then that's not your problem.

Since most roads do not have a maxwidth=* restriction it is safe to assume
that the road is suitable for any vehicle*, but if you add a maxwidth tag
somewhere it is immediately clear it was done purposefully.



On 8 September 2015 at 12:38, johnw  wrote:

> I was driving in Chiba and Saitama yesterday and encountered a couple new
> types of barriers. I realized later one is traffic_calming=chicane.
>
>
> The other one is all over rural Japan as traffic_calming=choker on rural
> roads that could bypass traffic near the rivers, - but this one is not for
> traffic calming, it is for enforcement of maxwidth of the bridge, similar
> to barrier=hight_restrictor.
> . They put very strong steel poles or guardrails along the sides and
> center of the road at the maxwidth + 20 cm of a standard car.  car can pass
> (barely, my mirrors were 5 cm away from each pole), but a large dump truck
> cannot pass. Both are in areas where commercial dump trucks or other large
> vehicles are nearby, but this one is used to enforce access to the narrow
> bridge near a very very busy area to keep a massive traffic jam from
> occurring from a stuck dump truck.
>
> https://goo.gl/maps/8KUw7  The maxwidth is signed and guardrails are
> doing the job. This is width limited for the very narrow bridge in the
> background.
>
> https://goo.gl/maps/3NT9X  The other direction. Poles are used.
>
> Is this a reason for creating barrier=width_restrictor ?
>
>
> 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] barrier enforcing maxwidth

[John Willis]

Im talking about how to tag the barrier. That thing was **tight** and very 
unusual to find in a major urban area. 

The amount of scars on the poles was amazing. 

The hight restriction barrier (a common thing) is tagged along with maxheight - 
this barrier seemed to be the same - if you are over max you will hit and 
severely damage your vehecle on the barrier - not the bridge or overpass or 
whatever. 

Javbw

> On Sep 8, 2015, at 1:52 PM, Andrew Errington  wrote:
> 
> I don't think a new tag is warranted.  maxwidth=* is fairly unequivocal.  If 
> map users or routers want to interpret it as "max width, but probably not 
> really, there's probably a bit of extra space, I mean, who's going to be that 
> petty" then that's not your problem.
> 
> Since most roads do not have a maxwidth=* restriction it is safe to assume 
> that the road is suitable for any vehicle*, but if you add a maxwidth tag 
> somewhere it is immediately clear it was done purposefully.
> 
> 
> 
>> On 8 September 2015 at 12:38, johnw  wrote:
>> I was driving in Chiba and Saitama yesterday and encountered a couple new 
>> types of barriers. I realized later one is traffic_calming=chicane. 
>> 
>> 
>> The other one is all over rural Japan as traffic_calming=choker on rural 
>> roads that could bypass traffic near the rivers, - but this one is not for 
>> traffic calming, it is for enforcement of maxwidth of the bridge, similar to 
>> barrier=hight_restrictor. 
>> . They put very strong steel poles or guardrails along the sides and center 
>> of the road at the maxwidth + 20 cm of a standard car.  car can pass 
>> (barely, my mirrors were 5 cm away from each pole), but a large dump truck 
>> cannot pass. Both are in areas where commercial dump trucks or other large 
>> vehicles are nearby, but this one is used to enforce access to the narrow 
>> bridge near a very very busy area to keep a massive traffic jam from 
>> occurring from a stuck dump truck. 
>> 
>> https://goo.gl/maps/8KUw7  The maxwidth is signed and guardrails are doing 
>> the job. This is width limited for the very narrow bridge in the background. 
>> 
>> https://goo.gl/maps/3NT9X  The other direction. Poles are used. 
>> 
>> Is this a reason for creating barrier=width_restrictor ? 
>> 
>> 
>> 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
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] barrier enforcing maxwidth

[Andrew Errington]

So tag a short section of the road before and after the bridge with a
maxwidth tag.  It could differ from the maxwidth of the bridge, but routing
software should determine the minimum maxwidth for any section of a route
(and avoid or penaliseit accordingly).

On 8 September 2015 at 14:59, John Willis  wrote:

> Im talking about how to tag the barrier. That thing was **tight** and very
> unusual to find in a major urban area.
>
> The amount of scars on the poles was amazing.
>
> The hight restriction barrier (a common thing) is tagged along with
> maxheight - this barrier seemed to be the same - if you are over max you
> will hit and severely damage your vehecle on the barrier - not the bridge
> or overpass or whatever.
>
> Javbw
>
> On Sep 8, 2015, at 1:52 PM, Andrew Errington  wrote:
>
> I don't think a new tag is warranted.  maxwidth=* is fairly unequivocal.
> If map users or routers want to interpret it as "max width, but probably
> not really, there's probably a bit of extra space, I mean, who's going to
> be that petty" then that's not your problem.
>
> Since most roads do not have a maxwidth=* restriction it is safe to assume
> that the road is suitable for any vehicle*, but if you add a maxwidth tag
> somewhere it is immediately clear it was done purposefully.
>
>
>
> On 8 September 2015 at 12:38, johnw  wrote:
>
>> I was driving in Chiba and Saitama yesterday and encountered a couple new
>> types of barriers. I realized later one is traffic_calming=chicane.
>>
>>
>> The other one is all over rural Japan as traffic_calming=choker on rural
>> roads that could bypass traffic near the rivers, - but this one is not for
>> traffic calming, it is for enforcement of maxwidth of the bridge, similar
>> to barrier=hight_restrictor.
>> . They put very strong steel poles or guardrails along the sides and
>> center of the road at the maxwidth + 20 cm of a standard car.  car can pass
>> (barely, my mirrors were 5 cm away from each pole), but a large dump truck
>> cannot pass. Both are in areas where commercial dump trucks or other large
>> vehicles are nearby, but this one is used to enforce access to the narrow
>> bridge near a very very busy area to keep a massive traffic jam from
>> occurring from a stuck dump truck.
>>
>> https://goo.gl/maps/8KUw7  The maxwidth is signed and guardrails are
>> doing the job. This is width limited for the very narrow bridge in the
>> background.
>>
>> https://goo.gl/maps/3NT9X  The other direction. Poles are used.
>>
>> Is this a reason for creating barrier=width_restrictor ?
>>
>>
>> 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
>
>
> ___
> 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] barrier enforcing maxwidth

[Mateusz Konieczny]

On Tue, 08 Sep 2015 12:38:53 +0900
johnw  wrote:

> Is this a reason for creating barrier=width_restrictor ? 

Yes, construction itself also may be mapped (in addition to maxwidth).
Though it would be a good idea to document it on wiki (maybe put through
proposal to ensure that it is not duplicating something already
documented).

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

Re: [Tagging] barrier enforcing maxwidth

[Volker Schmidt]

I use "maxwidth" to map the max width road signs, which represent a legal
access restriction, not necessaryly a physical acess restriction.

I use "width" to tag the physical width of a road.

If there is an object on the road that physicslly limits the width of the
vehicles you can use the tag barrier=block like this
barrier=block
material=concrete
maxwidth=2
vehicle=yes
foot=yes

Replace concrete with metal and you have a tag for your metal-pole width
restrictor

Volker
Padova, Italy
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging