[OSM-talk] Cycle lanes

Ben Laenen benlaenen at gmail.com
Mon Mar 24 15:12:26 GMT 2008


On Monday 24 March 2008, Dave Stubbs wrote:
> >  --++++-- cycleway
> >  --++++-- road
> >  --++++-- road
> >  --++++-- cycleway
>
> I count 8 ways?
> Unless you are splitting all the ways at absolutely every
> intersection which is probably a little excessive.

Not if you need to have route relations going over them (bus routes, 
cycle routes, walking routes etc). Then you often need access to each 
separate piece. A person tends to think differently when you start 
doing cycle routes on roads, that's how I stopped doing it, since I 
couldn't see the point in spending hours of extra work in putting in 
cycle tracks next to all roads and splitting up every intersection when 
simple cycleway=* tags give exactly the same information (and given the 
fact that yahoo imagery often couldn't give enough details about the 
exact location anyway, not to mention the poor people who can only work 
from GPS tracks who need to track the same road over and over again for 
car/bicycle/pedestrian). It turned out that tagging a route with 
highway=cycleway just took me three times more work, and made me do 
numerous more mistakes.

Sure, you can now just call me lazy for not doing that work, but note 
that part about giving exactly the same information.

> Obviously creating a way for every single cycle lane is going to just
> cause a mess, so where they do just follow the road, on the road,
> it's probably best to keep them as just a simple tag.
> However, where they are clearly separate, it's probably best to tag
> them as you would a dual-carriageway, and for the same reasons. With
> a separate cycleway you generally can't just hop-on/hop-off without
> being a menace to other traffic and there's sometimes even a physical
> barrier; the way can also diverge from the main road way, taking
> short-cuts round roundabouts or similar.

And shortcuts still get their own highways since that's a point where 
they diverge from the main road. But for 99% of the cases where the 
cycleway just follows the road that's overkill. Nobody is going to have 
doubts about where the cycleway is exactly: next to the road.

> >  But there are more reasons why I don't like these as separate
> > highways:
> >
> >  * We're also not tagging sidewalks as separate "highway=footway"
> > right (well, I guess there is not tag for sidewalks yet but it'll
> > come -- but I can't imagine someone tagging them all like separate
> > ways anyway, just think about the intersection mentioned above and
> > add four "highway=footway"s to them). Cycleways are usually between
> > the sidewalk and the road, so it becomes quite odd that a sidewalk
> > is just a tag, but a cycleway is its own highway.
>
> That's just an argument for modeling the pavement properly. Most
> pavements are just tacked onto the road as an extra "lane", but with
> a kerb (to discourage the cars from using it :-) ), so I wouldn't
> usually bother adding these as separate ways, but where the pavement
> diverges or is clearly separate, it should probably be modelled as
> such.

But where is the point between being separated from the road and not? As 
a cyclist I can usually get off my bike and walk on the pavement next 
to it at any point. I can also cross the road at any point. A line of 
trees doesn't stop that. Some grass doesn't stop that, a line of parked 
cars doesn't either. Of course, at the exact location of a tree or 
perhaps a flower bed I can't hop from cycle lane to whatever, but I 
can't see a pavement being tagged like lots of small highways next to 
the road at every tree:

 /|
 \|
  |
 /|
 \|

Anyway, the exact distinction between cycle lane and cycle track seems 
quite odd to me: in legislation there's no difference between them 
anyway, both give exactly the same rights/obligations as a road user 
(at least here in Belgium).

So I guess everyone agrees that a cycleway which is painted right next 
to the part of the road where cars drive is a cycle lane. But at what 
point does it become a track? 

Does a line of 10cm high and 50cm long concrete blocks make it a cycle 
track? A 5m wide area painted diagonal stripes where no-one can drive 
between cycleway and "motorcarway"? A kerb? Parking spaces? A 50cm wide 
patch of grass? A line of trees? A 5m wide patch of grass? A flower 
bed?

So where's the difference? I tend to see all of them as cycleway=track, 
except the painted diagonal stripes one. Yet I'd only consider making 
separate highway=cycleway ways when the distance becomes something like 
10 meters.

> >  * It's just a lot harder to make them their own highways. it's
> > much easier to make mistakes.
>
> It's possible to argue that one both ways: it's easier to see what's
> going on and where cycle tracks start and stop, and where exactly
> they are.

At the zoom levels where you can easily see the separate cycle tracks 
(zoom level 18 or so) you could as well just have the renderer 
interpret the cycleway=* tags to lanes next to the road with arrows on 
them for example.

> >  * Rendering engines could handle it much easier if it were just a
> >  cycleway=* tag added to the road.
>
> From practical experience I disagree.

Well, from practical experience (I'm also experimenting with Mapnik 
rendering) I can say that unless we get the "draw parallel roads next 
to each other instead of overlap" feature in renderers, you get either 
invisible cycleways (tiles at home), or otherwise lines going through the 
middle of roads because the roads get drawn thicker (the cycle map).

> >  * You can usually arbitrarily go from the cycleway to the main
> > road (to cross it for example). Routing applications could make use
> > of that, if it's just a cycleway=* tag. Maybe you have to watch out
> > for parked cars for example, but I've seen cycle lanes where there
> > are parked cars between you and the road as well, yet the cycle
> > lane is a lane and not a track. (and before someone mentiones it:
> > yes, relations like the dual_carriage relation could solve that,
> > but let us first get relation support in editors a bit better
> > before trying to put more and more into relations)
>
> Potlatch is getting relation support sometime soon.... just awaiting
> deployment :-)

Yes, looking forward to it, (but was it just route relation support, or 
all kinds of relations?)

Greetings
Ben




More information about the talk mailing list