On Mon, Mar 24, 2008 at 3:12 PM, Ben Laenen <[EMAIL PROTECTED]> wrote:
> 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.

If it's all that close I'd tend to agree. You're certainly not crazy
:-) But if there's clear separation then the real question is what you
do when someone comes along and "corrects" it. If it really does just
follow the road then you are right about it containing the same
information (topologically at least, but as you say the location of
each is likely to be estimation anyway).

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

Well, here in the UK if you're on a bike on the road the same rules
apply as if you were driving a car. You can't just cycle up onto
pavements or otherwise weave off and on the road (although people do).
So the distinction between a lane and a track is quite clear... a
cycle lane is on the road, and part of the road, so you can join it
and leave it at any point you like, at speed, as long as you're
obeying all the relevant traffic laws. Where the cycleway is separate
from the road there will be entry and exit points where you can switch
without getting off, but anywhere else along it you'd be expected to
stop and dismount to switch, and that's a track. Also, in the UK
tracks are often shared space with pedestrians, and even if they're
not then pedestrians often treat them as if they are.

Personally I'd start to way tracks separately when they have a clear
separation. That's deliberately ambiguous because I think it varies.
But yeah a 10m gap would certainly do it, but even a 1m gap if it's
made of something very solid.

>
>
>  > >  * 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 ([EMAIL PROTECTED]), or otherwise lines going through the
>  middle of roads because the roads get drawn thicker (the cycle map).

Yes, so that's possible to render in some way, where as the
alternative is currently /impossible/ without extra mapnik features.
Let me know if you make any progress on either because the cycle map
would definitely be improved by it.

>
>
>  > >  * 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?)
>

All kinds of relations. The presentation probably works best for
routes or multipolygons, but it's not limited to those at all, the
implementation is generic.

Dave

_______________________________________________
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Reply via email to