[Talk-us] Request for community mediation

Zeke Farwell ezekielf at gmail.com
Tue Oct 19 01:33:41 BST 2010

I pretty well agree with Greg.

Stating that cyclists should avoid a certain route is rather subjective and
therefore not verifiable.  Non verifiable data generally doesn't belong in
OSM.  On the other hand no renderer or other data user I've heard of is
being negatively affected by the presence of bicycle=avoid so perhaps it
doesn't matter.

If it is truly illegal to ride a bike on the specified way unless it is
necessary to get to your destination, then bicycle=destination is the
appropriate tag.  However, like Greg, I've never heard of this situation.
 Doesn't mean it doesn't exist though.


On Sun, Oct 17, 2010 at 12:15 AM, Greg Troxel <gdt at ir.bbn.com> wrote:

> I'm somewhat hesitant to wade into this, but:
>  There is debate with the transportation/cycling community about
>  whether bike lanes are a good thing or a bad thing.  Around me there
>  are some cycle lanes which are entirely within the door kill zone.  I
>  would never ride in them, and their presence makes cars think cyclists
>  should be in them - rather than "as far to the right as is safe", as
>  the law requires.  So to me such a lane makes a road unusable for
>  cycling.  (I guess my view is clear on this issue...)
>  We have this notion that making up new tags is fine.  I think that's
>  not really true - we are after all cooperating on a joint work that is
>  intended to be broadly useful - which means a shared ontology even if
>  people don't want to admit that.  So I think the more limited notion
>  that making up new tags for new situations is fine -- if one thinks
>  most others will think they are reasonable or will lead to a consensus
>  scheme, and the use of new tags is intended as a step to consensus.
>  For instance, I've added amenity=ice_cream but am happy to have that
>  be amenity=cafe cuisine=ice_cream and even to have my tags bot-edited
>  if the community decides that's what it should be called.  After all,
>  it's about representing data and allowing search and display - the
>  actual tag rules are not that important in most cases.
>  The use of "bicycle=destination" clearly means that it is only lawful
>  to bicycle on that road if it is necessary to get to one's
>  destination.  I have never heard of that being the case legally - in
>  my state bicycles may use any road except limited-access/express
>  highways posted for no bicycles.  Adding bicycle=destination to a road
>  without some evidence that there is a law that prohibits random
>  cycling is hard to reconcile with my notion of data stewardship, and
>  it seems reasonable to revert.  It also seems like tagging for the
>  router.
>  Adding bicycle=avoid seems fairly clearly not based on an expectation
>  of and desire for consensus.  It would be constructive to find scales
>  for road suitability from major cycling organizations, and to tag
>  according to their criteria, much like sac_scale.  Or to propose some
>  tags that are closer to being objective, like the width of the area
>  one can typically cycle in, and the degree of traffic.  If it's based
>  on knowledge from being a cyclist in the community and reflects that
>  even hard-core road cyclist think a road is scary, then that seems
>  fine.  But that's fairly few roads (perhaps Memorial Drive in
>  Cambridge/Boston).  And as Nathan says, if it's "no cycleway =>
>  avoid", that steps into the political debate where many others say
>  "cycleway with parking alongside it => risk of death, don't do it".  I
>  think we have a NPOV obligation much like wikipedia.  So it would be
>  fair to have cycleway=lane and cycleway_door_zone={true|false| or
>  something like that to express whether one is at risk of being doored
>  in the bike lane.
> _______________________________________________
> Talk-us mailing list
> Talk-us at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-us
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20101018/d44d2082/attachment.html>

More information about the Talk-us mailing list