Re: [Tagging] sub key for cycle ways

2014-11-29 Thread Paul Johnson
On Tue, Nov 4, 2014 at 11:44 AM, Hubert sg.fo...@gmx.de wrote:

 Mo 03.11.2014 20:18 fly lowfligh...@googlemail.com:

  Either just let your proposal exist and start using it or simply use the
 lanes:-tagging like
 
  biycle:lanes=yes|yes|designated

 Can I do that, even if the proposal was rejected?
 It would leave the problem that no one (Routers, Renderes) would use it and
 it will probably often be changed either to cw=lane or to cw=shared_lane,
 depending on the mappers preferences.


I would do this, supplementing what I consider the legacy cycleway=* key...
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


Re: [Tagging] sub key for cycle ways

2014-11-04 Thread Martin Vonwald
Hi!

2014-11-03 18:47 GMT+01:00 Hubert sg.fo...@gmx.de:

 But the question is, whether we should abandon cycleway=* tagging on the
 main road in favor for, let us say, cycleway:lanes=, or do we allow lane
 tagging in addition to the well established cycleway=* scheme.

As I wrote the :lanes proposal I'm obviously in favour of using it whenever
it is useful. And useful for me means: whenever there is not a simpler
tagging variant. If there is a simple road, two lanes, one in each
direction and on both side there's a cycle lane, then there is definitively
no need at all for any :lanes tagging. On the other hand, if we are looking
at junctions with multiple (turning) lanes and multiple cycle lanes, then
we should use the :lanes tagging in addition(!) to the good old cycleway
tagging.

In general I would like to see the :lanes tagging used to provide more
details and not to replace established tagging.

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


Re: [Tagging] sub key for cycle ways

2014-11-03 Thread Hubert
Indeed, Point 2 is also a very widely given situation in Germany. Also in cases 
where there are dedicated left turn cycle lanes. (Between the left turn lane 
and the through lane for cars.). But the question is, whether we should abandon 
cycleway=* tagging on the main road in favor for, let us say, cycleway:lanes=, 
or do we allow lane tagging in addition to the well established cycleway=* 
scheme.

To get back to the original discussion, how would you like to see the 
“soft_lane” being incorporated into either of the two tagging schemes?

 

I look forward to your thoughts,

Hubert

 

From: Mateusz Konieczny [mailto:matkoni...@gmail.com] 
Sent: Samstag, 1. November 2014 22:34
To: Tag discussion, strategy and related tools
Subject: Re: [Tagging] sub key for cycle ways

 

2. the cases where the bike lane is in the middle of the road is limited - 
bicycle lane in 
the middle is standard before advanced stop line (to be on the left side of 
right-turn) - 

at least in Poland


3. “cycleway=track” would look funny using that scheme - cycleway=track is 
anyway

not compatible with detailed tagging

 

2014-11-01 14:18 GMT+01:00 Hubert sg.fo...@gmx.de:

Sure, but I think it is best to do that in addition and not instead of 
“cycleway=*“ tagging. For one it takes more effort, 2. the cases where the bike 
lane is in the middle of the road is limited. (not counting parking lanes). 3. 
“cycleway=track” would look funny using that scheme. Also adding more data 
about the lane is imo easier with a namespace based tagging scheme of 
“cycleway:*=*.

On Sa, Nov 1, 2014 at 3:30 AM, Paul Johnson  mailto:ba...@ursamundi.org 
ba...@ursamundi.org wrote:

Can we move towards using the lanes tagging used for every other mode already?  
It's much more precise and can deal with situations like where the bike lane is 
not the extreme left/right lane.

On Fri, Oct 31, 2014 at 7:43 PM, Hubert  mailto:sg.fo...@gmx.de 
sg.fo...@gmx.de wrote:

Hallo,

since a new main value for UK:advisary cyclelane, DE:Schutzstreifen, 
A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable 
conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get approved, I’m 
thinking of introducing a sub key for that. (Like many of you already 
suggested.)

As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that purpose.

However just a key for that one occasion doesn’t seem logical, so a set of keys 
defining different types of “on lane”/”on road surface” cycle infrastructure 
should be developed, to keep the tagging consistent or to create a structured 
concept.

In order to do that, I’m thinking of introducing “lane=strict_lane, soft_lane, 
suggestive_lane” for lane like cycle ways where bicycles are ‘encouraged’ to 
stay on one side of the road and “shared_lane=sharrows, pictogram, busway” for 
roads/lanes where bicyclists are not separated from other traffic.

The in my opinion the main problems in that idea are the use of 
“lane=suggestive_lane” and “shared_lane= busway.

“lane=suggestive_lane” because it is in contrast of the current tagging as 
“cycleway=shared_lane” in the Netherlands. At least as far as I can remember. 
I’m also not sure whether “smurf lanes” in the UK are tagged as 
“cycleway=shared_lane”. 

 “shared_lane= busway” since this is currently tagged as “cycleway=share_ 
busway”. I think that in favor of structure, “shared_lane= busway” should be 
allowed. However, I haven’t made up my mind about that yet, or whether 
“cycleway=share_ busway” should be deprecated or just be discouraged.

This would leave “cycleway=track, lane, shared_lane, opposite_track, 
opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane, 
suggestive_lane” and “shared_lane=sharrows, pictogram, busway”.

Not part of the sub key discussion:

As an addition one could say that a “cycleway=track” is also a lane like cycle 
infrastructure, which would make it a “lane=track” sub key. 

Also any “cycleway=opposite(_*)” could be represented by, for example, 

“highway=* + 

oneway=yes + 

oneway:bicycle=no +

cycleway=right/left/both

cycleway:right/left =lane + 

cycleway:right/left:oneway= yes/-1”

(assuming right hand traffic)

What are your thoughts on this tagging scheme? 

I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait 
writing. 

Best regard

Hubert


___
Tagging mailing list
 mailto:Tagging@openstreetmap.org Tagging@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging 
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] sub key for cycle ways

2014-11-03 Thread Mateusz Konieczny
IMHO cycleway=* should stay. cycleway:lanes= would be (is?) significantly
more complex and it may be used in addition, not instead of cycleway=*.

2014-11-03 18:47 GMT+01:00 Hubert sg.fo...@gmx.de:

 Indeed, Point 2 is also a very widely given situation in Germany. Also in
 cases where there are dedicated left turn cycle lanes. (Between the left
 turn lane and the through lane for cars.). But the question is, whether we
 should abandon cycleway=* tagging on the main road in favor for, let us
 say, cycleway:lanes=, or do we allow lane tagging in addition to the well
 established cycleway=* scheme.

 To get back to the original discussion, how would you like to see the
 “soft_lane” being incorporated into either of the two tagging schemes?



 I look forward to your thoughts,

 Hubert



 *From:* Mateusz Konieczny [mailto:matkoni...@gmail.com]
 *Sent:* Samstag, 1. November 2014 22:34
 *To:* Tag discussion, strategy and related tools
 *Subject:* Re: [Tagging] sub key for cycle ways



 2. the cases where the bike lane is in the middle of the road is limited
 - bicycle lane in
 the middle is standard before advanced stop line (to be on the left side
 of right-turn) -

 at least in Poland


 3. “cycleway=track” would look funny using that scheme - cycleway=track
 is anyway

 not compatible with detailed tagging



 2014-11-01 14:18 GMT+01:00 Hubert sg.fo...@gmx.de:

 Sure, but I think it is best to do that in addition and not instead of
 “cycleway=*“ tagging. For one it takes more effort, 2. the cases where the
 bike lane is in the middle of the road is limited. (not counting parking
 lanes). 3. “cycleway=track” would look funny using that scheme. Also adding
 more data about the lane is imo easier with a namespace based tagging
 scheme of “cycleway:*=*.

 On Sa, Nov 1, 2014 at 3:30 AM, Paul Johnson ba...@ursamundi.org wrote:

 Can we move towards using the lanes tagging used for every other mode
 already?  It's much more precise and can deal with situations like where
 the bike lane is not the extreme left/right lane.

 On Fri, Oct 31, 2014 at 7:43 PM, Hubert sg.fo...@gmx.de wrote:

 Hallo,

 since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
 A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande
 cyclable conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get
 approved, I’m thinking of introducing a sub key for that. (Like many of
 you already suggested.)

 As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
 purpose.

 However just a key for that one occasion doesn’t seem logical, so a set
 of keys defining different types of “on lane”/”on road surface” cycle 
 infrastructure
 should be developed, to keep the tagging consistent or to create a
 structured concept.

 In order to do that, I’m thinking of introducing “lane=strict_lane,
 soft_lane, suggestive_lane” for lane like cycle ways where bicycles are
 ‘encouraged’ to stay on one side of the road and “shared_lane=sharrows,
 pictogram, busway” for roads/lanes where bicyclists are not separated
 from other traffic.

 The in my opinion the main problems in that idea are the use of 
 “lane=suggestive_lane”
 and “shared_lane= busway.

 “lane=suggestive_lane” because it is in contrast of the current tagging as 
 “cycleway=shared_lane”
 in the Netherlands. At least as far as I can remember. I’m also not sure
 whether “smurf lanes” in the UK are tagged as “cycleway=shared_lane”.

  “shared_lane= busway” since this is currently tagged as “cycleway=share_ 
 busway”.
 I think that in favor of structure, “shared_lane= busway” should be allowed.
 However, I haven’t made up my mind about that yet, or whether
 “cycleway=share_ busway” should be deprecated or just be discouraged.

 This would leave “cycleway=track, lane, shared_lane, opposite_track,
 opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane, 
 suggestive_lane”
 and “shared_lane=sharrows, pictogram, busway”.

 Not part of the sub key discussion:

 As an addition one could say that a “cycleway=track” is also a lane like
 cycle infrastructure, which would make it a “lane=track” sub key.

 Also any “cycleway=opposite(_*)” could be represented by, for example,

 “highway=* +

 oneway=yes +

 oneway:bicycle=no +

 cycleway=right/left/both

 cycleway:right/left =lane +

 cycleway:right/left:oneway= yes/-1”

 (assuming right hand traffic)

 What are your thoughts on this tagging scheme?

 I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
 writing.

 Best regard

 Hubert


 ___
 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] sub key for cycle ways

2014-11-03 Thread fly
Am 02.11.2014 um 09:14 schrieb Mateusz Konieczny:
  I'd argue that tracks are probably a distinct roadway anyway, given
 that they're bollard or curb separated and lane changes to the adjacent
 roadway is illegal.
 
 Yes, for me cycleway=track is equivalent of fixme=mark highway=cycleway
 near this road.

Well there is no problem with lanes:-Tagging + parking:lane +
cycleway=track + sidewalk=*

cu fly

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


Re: [Tagging] sub key for cycle ways

2014-11-03 Thread fly
Am 03.11.2014 um 18:56 schrieb Mateusz Konieczny:
 IMHO cycleway=* should stay.

+1
 cycleway:lanes= would be (is?)
 significantly more complex and it may be used in addition, not instead
 of cycleway=*.

so far, it is bicycle:lanes and no real lane-Tagging for the sidepath
(cycleway=track + sidewalk=(/footway=)).


I am not in favour of subtagging as you will change the meaning of
cycleway=lane as so far these are only real lanes.

Either just let your proposal exist and start using it or simply use the
lanes:-tagging like


biycle:lanes=yes|yes|designated
change:lanes=no|only_right|
highway=residential
oneway=yes
lanes=3
source:width=estimated
turn:lanes=left|through;right|
width:lanes=2|2|1

cu fly


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


Re: [Tagging] sub key for cycle ways

2014-11-02 Thread Mateusz Konieczny
 I'd argue that tracks are probably a distinct roadway anyway, given that
they're bollard or curb separated and lane changes to the adjacent roadway
is illegal.

Yes, for me cycleway=track is equivalent of fixme=mark highway=cycleway
near this road.

2014-11-02 2:17 GMT+01:00 Paul Johnson ba...@ursamundi.org:

 On Sat, Nov 1, 2014 at 4:34 PM, Mateusz Konieczny matkoni...@gmail.com
 wrote:

 2. the cases where the bike lane is in the middle of the road is
 limited - bicycle lane in
 the middle is standard before advanced stop line (to be on the left side
 of right-turn) -
 at least in Poland


 Not unheard of to common in the US, depending on region, for the same
 reasons.  You don't want through traffic right of a continuous turnlane or
 turn pocket.


 3. “cycleway=track” would look funny using that scheme -
 cycleway=track is anyway
 not compatible with detailed tagging


  I'd argue that tracks are probably a distinct roadway anyway, given that
 they're bollard or curb separated and lane changes to the adjacent roadway
 is illegal.

 ___
 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] sub key for cycle ways

2014-11-01 Thread Hubert
Sure, but I think it is best to do that in addition and not instead of
“cycleway=*“ tagging. For one it takes more effort, 2. the cases where the
bike lane is in the middle of the road is limited. (not counting parking
lanes). 3. “cycleway=track” would look funny using that scheme. Also adding
more data about the lane is imo easier with a namespace based tagging scheme
of “cycleway:*=*.

On Sa, Nov 1, 2014 at 3:30 AM, Paul Johnson ba...@ursamundi.org wrote:

Can we move towards using the lanes tagging used for every other mode
already?  It's much more precise and can deal with situations like where the
bike lane is not the extreme left/right lane.

On Fri, Oct 31, 2014 at 7:43 PM, Hubert sg.fo...@gmx.de wrote:
Hallo,
since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable
conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get approved, I’m
thinking of introducing a sub key for that. (Like many of you already
suggested.)
As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
purpose.
However just a key for that one occasion doesn’t seem logical, so a set of
keys defining different types of “on lane”/”on road surface” cycle
infrastructure should be developed, to keep the tagging consistent or to
create a structured concept.
In order to do that, I’m thinking of introducing “lane=strict_lane,
soft_lane, suggestive_lane” for lane like cycle ways where bicycles are
‘encouraged’ to stay on one side of the road and “shared_lane=sharrows,
pictogram, busway” for roads/lanes where bicyclists are not separated from
other traffic.
The in my opinion the main problems in that idea are the use of
“lane=suggestive_lane” and “shared_lane= busway.
“lane=suggestive_lane” because it is in contrast of the current tagging as
“cycleway=shared_lane” in the Netherlands. At least as far as I can
remember. I’m also not sure whether “smurf lanes” in the UK are tagged as
“cycleway=shared_lane”. 
 “shared_lane= busway” since this is currently tagged as “cycleway=share_
busway”. I think that in favor of structure, “shared_lane= busway” should be
allowed. However, I haven’t made up my mind about that yet, or whether
“cycleway=share_ busway” should be deprecated or just be discouraged.
This would leave “cycleway=track, lane, shared_lane, opposite_track,
opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane,
suggestive_lane” and “shared_lane=sharrows, pictogram, busway”.
Not part of the sub key discussion:
As an addition one could say that a “cycleway=track” is also a lane like
cycle infrastructure, which would make it a “lane=track” sub key. 
Also any “cycleway=opposite(_*)” could be represented by, for example, 
“highway=* + 
oneway=yes + 
oneway:bicycle=no +
cycleway=right/left/both
cycleway:right/left =lane + 
cycleway:right/left:oneway= yes/-1”
(assuming right hand traffic)
What are your thoughts on this tagging scheme? 
I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
writing. 
Best regard
Hubert

___
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] sub key for cycle ways

2014-11-01 Thread Mateusz Konieczny
2. the cases where the bike lane is in the middle of the road is limited
- bicycle lane in
the middle is standard before advanced stop line (to be on the left side of
right-turn) -
at least in Poland

3. “cycleway=track” would look funny using that scheme - cycleway=track
is anyway
not compatible with detailed tagging

2014-11-01 14:18 GMT+01:00 Hubert sg.fo...@gmx.de:

  Sure, but I think it is best to do that in addition and not instead of “
 cycleway=*“ tagging. For one it takes more effort, 2. the cases where the
 bike lane is in the middle of the road is limited. (not counting parking
 lanes). 3. “cycleway=track” would look funny using that scheme. Also
 adding more data about the lane is imo easier with a namespace based
 tagging scheme of “cycleway:*=*.

 On Sa, Nov 1, 2014 at 3:30 AM, Paul Johnson *ba...@ursamundi.org*
 ba...@ursamundi.org wrote:

 Can we move towards using the lanes tagging used for every other mode
 already?  It's much more precise and can deal with situations like where
 the bike lane is not the extreme left/right lane.

 On Fri, Oct 31, 2014 at 7:43 PM, Hubert *sg.fo...@gmx.de*
 sg.fo...@gmx.de wrote:

 Hallo,

 since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
 A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande
 cyclable conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get
 approved, I’m thinking of introducing a sub key for that. (Like many of
 you already suggested.)

 As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
 purpose.

 However just a key for that one occasion doesn’t seem logical, so a set
 of keys defining different types of “on lane”/”on road surface” cycle 
 infrastructure
 should be developed, to keep the tagging consistent or to create a
 structured concept.

 In order to do that, I’m thinking of introducing “lane=strict_lane,
 soft_lane, suggestive_lane” for lane like cycle ways where bicycles are
 ‘encouraged’ to stay on one side of the road and “shared_lane=sharrows,
 pictogram, busway” for roads/lanes where bicyclists are not separated
 from other traffic.

 The in my opinion the main problems in that idea are the use of 
 “lane=suggestive_lane”
 and “shared_lane= busway.

 “lane=suggestive_lane” because it is in contrast of the current tagging as 
 “cycleway=shared_lane”
 in the Netherlands. At least as far as I can remember. I’m also not sure
 whether “smurf lanes” in the UK are tagged as “cycleway=shared_lane”.

  “shared_lane= busway” since this is currently tagged as “cycleway=share_ 
 busway”.
 I think that in favor of structure, “shared_lane= busway” should be allowed.
 However, I haven’t made up my mind about that yet, or whether
 “cycleway=share_ busway” should be deprecated or just be discouraged.

 This would leave “cycleway=track, lane, shared_lane, opposite_track,
 opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane, 
 suggestive_lane”
 and “shared_lane=sharrows, pictogram, busway”.

 Not part of the sub key discussion:

 As an addition one could say that a “cycleway=track” is also a lane like
 cycle infrastructure, which would make it a “lane=track” sub key.

 Also any “cycleway=opposite(_*)” could be represented by, for example,

 “highway=* +

 oneway=yes +

 oneway:bicycle=no +

 cycleway=right/left/both

 cycleway:right/left =lane +

 cycleway:right/left:oneway= yes/-1”

 (assuming right hand traffic)

 What are your thoughts on this tagging scheme?

 I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
 writing.

 Best regard

 Hubert


 ___
 Tagging mailing list
 *Tagging@openstreetmap.org* Tagging@openstreetmap.org
 *https://lists.openstreetmap.org/listinfo/tagging*
 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] sub key for cycle ways

2014-11-01 Thread Paul Johnson
On Sat, Nov 1, 2014 at 4:34 PM, Mateusz Konieczny matkoni...@gmail.com
wrote:

 2. the cases where the bike lane is in the middle of the road is
 limited - bicycle lane in
 the middle is standard before advanced stop line (to be on the left side
 of right-turn) -
 at least in Poland


Not unheard of to common in the US, depending on region, for the same
reasons.  You don't want through traffic right of a continuous turnlane or
turn pocket.


 3. “cycleway=track” would look funny using that scheme - cycleway=track
 is anyway
 not compatible with detailed tagging


 I'd argue that tracks are probably a distinct roadway anyway, given that
they're bollard or curb separated and lane changes to the adjacent roadway
is illegal.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


[Tagging] sub key for cycle ways

2014-10-31 Thread Hubert
Hallo,
since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande cyclable
conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get approved, I’m
thinking of introducing a sub key for that. (Like many of you already
suggested.)
As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
purpose.
However just a key for that one occasion doesn’t seem logical, so a set of
keys defining different types of “on lane”/”on road surface” cycle
infrastructure should be developed, to keep the tagging consistent or to
create a structured concept.
In order to do that, I’m thinking of introducing “lane=strict_lane,
soft_lane, suggestive_lane” for lane like cycle ways where bicycles are
‘encouraged’ to stay on one side of the road and “shared_lane=sharrows,
pictogram, busway” for roads/lanes where bicyclists are not separated from
other traffic.
The in my opinion the main problems in that idea are the use of
“lane=suggestive_lane” and “shared_lane= busway.
“lane=suggestive_lane” because it is in contrast of the current tagging as
“cycleway=shared_lane” in the Netherlands. At least as far as I can
remember. I’m also not sure whether “smurf lanes” in the UK are tagged as
“cycleway=shared_lane”. 
 “shared_lane= busway” since this is currently tagged as “cycleway=share_
busway”. I think that in favor of structure, “shared_lane= busway” should be
allowed. However, I haven’t made up my mind about that yet, or whether
“cycleway=share_ busway” should be deprecated or just be discouraged.
This would leave “cycleway=track, lane, shared_lane, opposite_track,
opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane,
suggestive_lane” and “shared_lane=sharrows, pictogram, busway”.

Not part of the sub key discussion:
As an addition one could say that a “cycleway=track” is also a lane like
cycle infrastructure, which would make it a “lane=track” sub key. 
Also any “cycleway=opposite(_*)” could be represented by, for example, 
“highway=* + 
oneway=yes + 
oneway:bicycle=no +
cycleway=right/left/both
cycleway:right/left =lane + 
cycleway:right/left:oneway= yes/-1”
(assuming right hand traffic)

What are your thoughts on this tagging scheme? 
I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
writing. 

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


Re: [Tagging] sub key for cycle ways

2014-10-31 Thread Paul Johnson
Can we move towards using the lanes tagging used for every other mode
already?  It's much more precise and can deal with situations like where
the bike lane is not the extreme left/right lane.

On Fri, Oct 31, 2014 at 7:43 PM, Hubert sg.fo...@gmx.de wrote:

  Hallo,

 since a new main value for UK:advisary cyclelane, DE:Schutzstreifen,
 A:Mehrzweckstreifen, NL:fietsstrook met onderbroken streep, F:bande
 cyclable conseillée et réservée, CZ:cyklistický jízdní pruh didn’t get
 approved, I’m thinking of introducing a sub key for that. (Like many of
 you already suggested.)

 As a start I’m thinking of “cycleway=lane + lane=soft_lane” for that
 purpose.

 However just a key for that one occasion doesn’t seem logical, so a set
 of keys defining different types of “on lane”/”on road surface” cycle
 infrastructure should be developed, to keep the tagging consistent or to 
 create
 a structured concept.

 In order to do that, I’m thinking of introducing “lane=strict_lane,
 soft_lane, suggestive_lane” for lane like cycle ways where bicycles are ‘
 encouraged’ to stay on one side of the road and “shared_lane=sharrows,
 pictogram, busway” for roads/lanes where bicyclists are not separated
 from other traffic.

 The in my opinion the main problems in that idea are the use of “lane=
 suggestive_lane” and “shared_lane= busway.

 “lane=suggestive_lane” because it is in contrast of the current tagging as
 “cycleway=shared_lane” in the Netherlands. At least as far as I can
 remember. I’m also not sure whether “smurf lanes” in the UK are tagged as
 “cycleway=shared_lane”.

  “shared_lane= busway” since this is currently tagged as “cycleway=share_
 busway”. I think that in favor of structure, “shared_lane= busway” should
 be allowed. However, I haven’t made up my mind about that yet, or whether
 “cycleway=share_ busway” should be deprecated or just be discouraged.

 This would leave “cycleway=track, lane, shared_lane, opposite_track,
 opposite_lane, opposite” as the main values, “lane=strict_lane, soft_lane,
 suggestive_lane” and “shared_lane=sharrows, pictogram, busway”.

 Not part of the sub key discussion:

 As an addition one could say that a “cycleway=track” is also a lane like
 cycle infrastructure, which would make it a “lane=track” sub key.

 Also any “cycleway=opposite(_*)” could be represented by, for example,

 “highway=* +

 oneway=yes +

 oneway:bicycle=no +

 cycleway=right/left/both

 cycleway:right/left =lane +

 cycleway:right/left:oneway= yes/-1”

 (assuming right hand traffic)

 What are your thoughts on this tagging scheme?

 I’m sorry, if this is a bit confusing. It’s late but I just couldn’t wait
 writing.

 Best regard

 Hubert

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


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